The cloud vs. dedicated servers
screamingatmyscreen.com
screamingatmyscreen.com
For my side-projects, personal websites and general purpose "whatever" I'm using an in-expensive colo provider(Colo@). For $50 I get 10mbit/s @ 95% (basically, burstable to 100mbps for up to 5% of a month). That's about 3 TB of data transfer which alone would cost hundreds of dollars at EC2. Of course, it is also way more data than most people would use.
The server I bought used on eBay for $365. Its a dual Xeon L5420 (8 hw cores) and has 24 GB of RAM. I run seven or 8 VMs under KVM on it presently. These images are pretty portable and a couple of them I backup regularly to S3; I could recover to an EC2 instance if I lost the box.
I monitor this with an EC2 micro instance and have not had any network outages in 6 months there. If I wanted to run a production site there I would need at least a second machine for redundancy; that would be another $30-40 a month. I'd probably also replicate real-time to a small EC2 instance so that would cost a little (though the incoming B/W to EC2 is free) - I don't do that now as I don't have real "production" data.
Not everyone should do this but if you like servers you should consider it. Another advantage here is that I own the server. If I get in a billing dispute or other issue with my provider they can take me off the network but they cannot hold my server hostage. Also they cannot login to the box - any attempt at social hacking is pretty well doomed.
On the other hand, on the two occaisions I've needed remote hands and the one time I needed a KVM they responded in less than fifteen minutes. It is mind-blowing the level of support you can get with the right provider.
I think it would be better to put it this way - if you care about $100/month, you should consider co-locating. Otherwise, you need other reasons.
You should move up the hosting chain as your needs demand it, and not before. Yes, you'll pay more for cloud-hosted solutions, but if one of the racked servers has a power supply failure or a motherboard failure or bad RAM or a failed drive, that's their problem to deal with, not yours -- and at the moment, most of the cloud providers seem to be very good at dealing with it.
All of those things are a distraction, and worse still, if you don't have multiple layers of redundancy -- which will add to your costs -- then they can result in down time for your service, which is bad.
I, personally, would not move to a dedicated server until the costs for required resources became so egregious in the cloud that I could no longer afford not to use a dedicated server.
Secondly there is actually little difference between the amount of time spent managing a VPS versus a dedicated or colo. Hardware failures aren't going to be your biggest concern. It's going to be services going down, database misbehaving, OS misconfigurations, general scaling issues, network dropping out etc e.g. witness all of the AWS/Linode outages almost all of which are due to DC power/networking.
And the fact is that my Mac Mini has an equivalent Unixbench/disk test as the Linode instances + AWS m1.xlarge. So it gives you an idea of how much better performance and value you will get from a dedicated or colo.
You should be as transparent as you expect other entities to be.
One of your key points is what turns some people towards more managed services: "skills to support it". I'd add time to that factor as well.
If I had the support staff, I would co-locate in a second. Heck, one of our previous locations was next-door to a Level 3 co-location facility. It was pretty nice to be able to walk 10 feet and access your hardware.
Nitpick: Vagrant is not a deployment system. It's an awesome tool, but it falls back to puppet/chef for the actual configuration.
For $100 I could get a Xeon E3-1245 with 32GB ECC Ram, 2x 3TB HDs from Hetzner. One year later? Better system, same price. Upgrade costs? One to two days of work migrating.
I believe co-location has its place but not if we are talking about "only" $100 and pretty simple needs. There is always a time factor that outweighs its gains.
"Hostage situations" and incompetent personal is something, I believe, that is hard to compare. Everyone near your system, no matter what or where, can cause problems.
What if they refuse to hand out your server till all payment problems are solved? Maybe this depends on the country but getting the server if they refuse to hand it out will likely consume more time than just paying whatever they want. Also if you planned for this situation with some EC2 instances just switching the domain over and settling the dispute should be doable.
What kind of application are we trying to deploy? What is your budget? What is the traffic level? Is performance a top priority? How many sysadmins do you have at your disposal, and how many are you willing to add? What kind of sensitive data are we storing/transmitting?
The answers to these questions drive the selection process, and end up altering the importance of each pro and con the author mentioned. Depending on your application, some pros and cons are eliminated, and new ones added.
Please please PLEASE, for the love of all things good, don't use an article like this as the sole basis for selecting providers. Think about what you need, ask questions, and craft your search to your purpose. Don't go pick method X because other people say it's great (for their purpose).
The pros and cons can change, some of them, like availability of features, support,... don't. But you are right that there is no "one solutions fits for everyone" plan.
But they do change. What features are important depends on your application. The amount of support you need, and by who, changes as well.
What I'd love to see is a series of articles that helps walk people through the platform selection process from the perspective of a few sample applications/organizations. I feel that would be really constructive.
I currently spend $100/month on 4 Linodes (3 x 512MB, 1 x 1GB). I love Linode -- efficient support, and their London datacentre has been utterly rock-solid for me for several years -- but I'm beginning to think that, for me, it's the worst of both worlds.
On the one hand, I could move all 4 servers to a dedicated Hetzner box (EX6 or EX6S) running Xen, for a small setup fee and similar monthly cost, and get 4 or 8GB ECC memory on each one. This has a slightly higher sysadmin burden (5 servers to administer instead of 4, slightly higher risk of disk failure), but not that much. And the move is relatively painless, because I can directly transfer the disk images with dd over SSH.
On the other, I could move the services to Heroku, probably pay a bit more, and essentially stop doing any sysadmin. This is superficially attractive... but moving a load of old things to Heroku isn't straightforward, and that probably rules this option out.
The downside to Hetzner is their support is fairly brutal when it's outside their normal parameters: obvious hardware fails are replaced reasonably quickly (eg within an hour) - anything non-obvious and you'll batter your head against their support, or you'll have to pay extra to change hardware if you can't prove that it's their problem.
I had an EX4S and after a month I terminated it because it kept failing on a minimal Ubuntu install and they refused to do anything without proof or money, but have been very happy with a cheap 8GB dual core Athlon server I got through the Server Bidding process.
The time you spend doing sysadmin things could be spent writing code or otherwise growing the business.
Also, as you grow you aren't going to need to hire a bunch of sysadmins just to build, manage, and deploy more infrastructure. Saving even one $60,000 a year employee buys you what, $5,000 a month in infrastructure? That's quite a bit on Heroku + various addons.
How do you deal with hardware failure when you have a dedicated box at Hetzner? Specifically if/when something fails are there spares etc?
There is no one-size-fits-all or simple, formulaic solution to choosing cloud vs. bare metal. It's hugely dependent upon the organization and the application.
Just to play devil's advocate, it's not unknown for large VPS providers to have major issues. This is something you need to consider regardless of whether you're using dedicated or VPS.
I'm not talking though about a separate issue which is proper backup procedures. I mean if you have a server racked at Hetzner (or elsewhere) what is your "plan b" when there is a hardware failure.
In the case of a server that I just racked somewhere I will purchase a supply of the most logical parts to fail (fan, hard drive, board, power supply etc.) so that the parts are available and can be replaced quickly. I know that some providers take care of this for you so if the hardware fails (your hardware) you are back up and running quickly.
In the case of a VPS, by contrast, it can generally be assumed (nice if a way to verify this but I'm guessing there isn't) that they take have taken care of and planned for hardware issues and spares and have a strategy. Of course if they haven't you have a big problem. At least with your own hardware you can plan accordingly and insure a better outcome.
There are other issues as well. If the colo place is close to you do you keep the spare parts yourself or do you leave the spare parts with them? The answer depends on many factors (such as is there security where the parts are and who has access to them. If that is not the case better to keep the spares and drive over yourself with them even in the middle of the night).
I nearly majored in economics, and I've worked in a datacenter, so I know it's simply more efficient to depend on hosted services. Yet I still want to set up the whole stack. For me, it's a question of letting go and trusting the services that others host and others use. And it's foregoing the pride of "doing it all myself".
There simply isn't enough time to build everything from scratch -- if you build your own servers, you're sourcing HDDs and motherboards and power supplies and other components. If you make motherboards, you're sourcing copper and other raw materials. No single human is so tall as to pull copper ore from the ground, pull silicon from sand, and move vertical enough to self-produce a tablet or PC. Currently this takes several thousand humans.
a) co-location for the main DB servers (allows you to be very specific about hardware choices: RAID cards and SSDs not just preferred manufacturer but also the exact model) and backup machines (needed higher density HDDs than could be supplied by hosting providers choice of dedicated servers)
b) some unmanaged dedicated servers for the core servers that don't rely upon specific hardware requirements (HTTP servers, memcached, varnish). Also easier to slowly ramp up the number of these month on month.
c) virtual boxes spun up when required to handle spikes in the load and then canned when it goes quieter again
Even better if your hosting provider provides all 3 and can arrange a private VPN between the sets of hosts so you don't get billed for your 'internal' bandwidth.
There's no reason you shouldn't be able to have dedicated hardware performance, instant deployability, on-demand usage-based billing, at costs close to, or better than, co-locating it yourself. As I'm working to prove with Uptano (https://uptano.com)
I really think server hosting is going to look very different in a few years. We've not come very far in the past 5 years.
That said your offering strikes a nice balance in terms of price/performance. What I'm missing is bigger profiles (64G Ram please?) and information what CPUs and hardware you are using (blades?). "Compute units" are a terrible metric, give me a model number so I can look it up on cpubenchmark.net.
Regarding Rackspace, I've had good experience with them when working at mid-size and larger companies. Unfortunately I've had the opposite experience when functioning as a freelancer, working with startups, or as an entrepreneur myself. Rackspace didn't even respond to sales inquiries. Initially I figured this was a strangely repeated fluke, but other small companies and entrepreneurs I've spoken to have reported the exact same thing, where they send an inquiry to Rackspace or ask to speak with a sales engineer, and they get no response. Nothing, zip, nada. I find that very strange, and am speculating RS no longer wants to deal with the growing pains and frequent support requests of startups, but it certainly makes the decision to stick with Linode or EC2 much easier.
I don't have much experience with dedicated anymore, but have repeatedly heard good things about ServInt and SingleHop. Have also heard good things about Firehost for a managed cloud provider. I would love to hear others opinion and experience on any of the aforementioned companies though.
I would recommend http://www.webhostingtalk.com as you will find out much better options for your specific needs.
I use their Dallas and Newark data centers currently. I have had zero downtime this year, which puts Linode at the head of the pack in terms of reliability.
So if you don't understand why people keep recommending Linode, it's because:
1. The prices are fair;
2. The service is as reliable as anything else out there, and in some cases, far more reliable;
3. The performance is good;
4. The support is blow-you-out-of-the-water fantastic;
5. The software (their management console) is pretty good;
6. There are very very few complaints overall, other than their handling of the Bitcoin incident.
I agree that they should have handled that incident differently, and that they still haven't taken proper care of it. However, you're being otherwise dishonest in your portrayal of Linode.
Generally speaking our biggest challenges with AWS have been storage (making TBs of web content securely available to various autoscaling clusters) and network i/o (especially across VPC/public internet boundaries).
We've actually found that AWS' pricing beats the costs of hosting internally, especially once you look beyond raw server cost and factor in power/cooling/manual labor/datacenter space/etc. And there are lots of different options for monitoring your usage to avoid surprises (we're looking into programmatic usage reports and New Relic for that, though we've been there a couple years now so we have a good idea what our bills are going to run each month).
As far as CDN, we get way better pricing from Level3 and Akamai than we could from CloudFront or Rackspace, but our traffic patterns are more 95th-percentile-friendly than most.
He also mentions that there is no way to see what your next bill will be in AWS. They offer an 'Account Activity' link, that shows you current charges in the current month. That can be helpful when testing things.
I hope people that are new to setting up infrastructure and supporting it do no use comparisons like this to make the decision for them. There are far too many variables not discussed in this article for this to be very valuable to anyone.
Good to know, thank you. I was not sure about this feature and after asking one of the sales engineers on the AWS event they told me that this is just not possible, especially if you want some details.
What you pay for in the cloud is convenience and not performance.
With that being said, I'm a loyal Rackspace customer and love their cloud offering.
Add a month's worth of colocation fees, capital depreciation and associated labor costs. If it's less than your monthly cloud hosting bill, then it's time to self-host.
And if you run your own firm and haven't figured out how to calculate capital depreciation yet, it's time to learn. :)
Where does this misconception come from? That is the exact opposite of reality. With the "cloud" route, you are limited to absurdly inadequate servers, which is a large part of what drove the "nosql" fad, you need to shard if you are on EC2, because they offered nothing with reasonable IO. Even now they have an SSD option, but it is a single crappy SSD, and barely any RAM. With the dedicated route, you can do a 512GB RAM, 24 SSD array server and not have to worry about sharding until you are in the top50 sites on the web.
That this problem does not exist if you kill it with hardware in the first place is true. But the way from evaluating an idea, to gaining traction, to hiring people and buying hardware is still a long way.