Still, most small and medium-sized companies would do best to go with Rackspace, Linode, or something similar. You'll get better support from them and it's not often that a 10 person company needs a ton of servers for a short period of time. Even then, you could use both: short-lived instances on EC2 and stable, well-supported, long-lived stuff on Rackspace.
That's not my only reason for preferring EC2 for lots of short-lived servers. I left out some anecdotes.
Four months ago, one of my coworkers booted 12 cloud servers in DFW. I later discovered that 3 of them were on the same physical hardware. Two months ago, about 55 of 60 servers actually came up in ORD. Others were inaccesible or hung. Not even hard reboots helped. We had to kill them and start new ones.
I've had a total of 2 EC2 instances die on me. I admit my usage of the two providers is quite different. The stuff on EC2 is shorter-lived. But I'm pretty sure that high turnover on other providers would cause a lot more grief.
From what I've read during my usage of AWS over the last couple of years, this is more the norm than the exception.
I've ran much larger clusters on EC2 over the last several years (50+ servers) and can count on my fingers the times that machines have been rebooted. And when they have, it's due to a lightning strike or a AWS failure that's reasonably explainable.
What you need to be careful about is the fact that EC2 and Rackspace Cloud are currently in two different leagues when it comes to controlling your instances. Amazon has a far better control panel (not to mention the API) for exercising granular control of your instances. Hard drive space is dynamically scalable on Amazon whereas it is not on Rackspace (their solution of mounting Rackspace Cloud Files via FUSE is unacceptable).
The monitoring system for EC2 is also far better, and completely non-existent on Rackspace unless you pay them $99/mo out of pocket on top of your hourly usage charges.
All in all, my Rackspace experience left a very bad taste in my mouth when dealing with their support, and it was a culmination of the small and simple things that left me frustrated (the lack of pv_grub support out of the box, etc., etc.) and kept me on EC2 despite the lack of CPU bursting.
I wouldn't necessarily choose it for all applications though. The AWS architecture is far more flexible in general. Elastic IPs are invaluable when it comes to creating a system that can grow over time (seamlessly switch from a single instance to several fronted by a load balancer in a couple of minutes). Being able to take complete snapshots of your system on an hourly basis could well save your business one day. Being able to make a couple of API calls to attach an extra 1 TB drive to your instance? That's worth losing a little horsepower over.
It all depends on what you're after; with Rackspace you probably get a faster machines, but that's at the expense of being able to build a more robust generic solution for your needs.
1. Not being able to idle a system, or to restore from a system image (some persistent bug on their side w/r/t setting netmasks on external interfaces, of all things);
2. Not being able to buy disk independently of RAM.
We were moved from DFW to ORD and since then, we haven't seen the random weird outages that had me pulling out my hair. It hasn't been bad enough to make me want to move to EC2/some other hosting company, but I do look longingly at, say, spot instances, which would be a perfect tool for some of our problems. I'd love it if FreeBSD worked correctly, but I'd also like a pony, so what the hell.
Granted there could be some extenuating circumstance for your specific setup, but I think typically that scenario is supported out of the box.
That said, there are always bigger fish to fry.
The pricing and build-out structure is linear when looking at RAM & disk space, so this may or may not fit everyone's requirements. There is no EBS-equivalent, and load balancing has just been introduced formally into the control panel recently. The persistency is something I've taken advantage of, compared to EC2's ephemeral nature (unless one employs EBS).
As for cloud servers going down randomly, Rackspace Roulette can be tough, and the only silver lining is it provides a good incentive to build (or at least, to think about) applications which work around failure.
There is one other lesser known gotcha which is max RAM capacity per account; I think the default is something like 50GB and if you require more (for burst perhaps), you have to get this amount pre-approved. Apparently this is to safeguard against (accidental) abuse of the Cloud Servers API, but it's probably also a good mechanism for capacity planning on their side. At any rate, I've seen/heard the turnaround to be about a couple of business days.
One the flip side, there was a very active thread a while back about how Mixpanel moved away from RS: http://news.ycombinator.com/item?id=1884685
EDIT: One more note about RS -- resizing cloud servers. It's a great ability to have, but it can be slow. It tends to take longer the more data you have (not too surprising). A good practice is to wipe unnecessary log files before resizing, as I've been told that each resize action actually causes the cloud server to jump to another physical host. Don't quote me though, I'm just on the Internet :)
Is that supposed to be cheap? I used EC2 for some compute tasks a week ago; it was 23 cents per hour for an x86_64 8-core 2.16Ghz i7 system with 8 gigabytes of RAM -- which sounds way more than 3 times as powerful as the system they mention.
Running on "burst CPU" doesn't sound like a very useful strategy when I need to load a few dozen cores for a few days.
I can also tell you that having not picked EC2, I have, more than once, wished for Feature X offered by Amazon. Maybe Rackspace Cloud offers a comparative list of addons/products, so my point might not be too relevant. But, my point is that price/performance shouldn't be the only determining factor.
EBS has been getting a lot of bad rap recently (most of it deserved), but being able to juggle detachable, snapshot'able 1TB-volumes for $100 a shot has still been a game-changer for many companies.
The result of this difference is that a Rackspace cloud physical host is not going to be as heavily taxed resource-wise (at least on average). Add to that the cpu burst by default versus cpu cap by default and cpu is definitely the one area where differences will be widest.
One thing I will say though, and many may disagree with this, but I have yet to see a benchmarking study that I'd trust. Real world operating performance of a server is just a very complex thing and any attempt to distill it down to single parameter comparison is going to compromise some element of that complexity. I can show you comparison studies that show any of the cloud providers to be better than the others, including AWS, Rackspace, Linode, Joyent, etc. So take these things with a grain of salt.
This is extremely true not just of this but of comparison in general. Turning something complicated into a natural number below 100 and then using > and < is pretty limited.
So if you have four slices on a host and 3 slices only use 10% each of total cpu capacity. Each slice is guaranteed 25% but they aren't using all of their guaranteed cpu. Your slice can then consume the remaining 70% of the cpu on the host. (Minus virtualization overhead)
Unlike bursting, you don't get throttled until other slices need cpu. Your slice can happy keep consuming 70% until the other slices start asking for their share.
I do know that the vm environments are the same. I'm just not sure about some of the other bits.
The new Micro instances on EC2 make it a no-brainer.. really.
RAM is important, sure, but there should be some way to quantify the expected CPU performance as well.
http://server4you.net/root-server/ (haven't tested them yet)
BTW, server4you have a lot of horrible stories.
Hetzner reviews are better, but it's important to understand that this deal hardware is of "desktop quality" and not as reliable as "standard server" one. And it is in Germany.
In US servers are a bit more expensive, but you can get similar configuration for around $100/month (e.g. burstnet)
In contrast, Linode sells bandwidth for $0.10/GB, and that comes with a whole VPS. So if I pay $160/month, I get 16TB of bandwidth on a VPS with 4GiB of RAM and 128GiB of storage (oh, and Linode pools your bandwidth across all nodes). On S3, $160 will buy me a little over 10TB of bandwidth, nevermind storage or anything else.
I understand that these cloud services are the most convenient way to scale, and probably the best way to absorb an unexpected spike in usage. But they seem to charge a roughly 50% premium for every resource, as compared to a reliable VPS provider with great customer service, an API that lets you set up temporary servers, etc.
One of the things you are paying for with S3 is a pretty solid guarantee that your files will A) not get lost and B) always be available.
That's a relative term, though. While complete outages are rare, there are frequent, prolonged periods of abysmal performance (latency in the >300ms range, throughput approaching <50 MBit/s) and the average performance without CloudFront isn't stellar either.
However, for many use-cases the sheer convenience and low cost of entry trump these issues.
In Linode, for $159.95 you get 1.600GB or 1.6TB of bandwidth. Not 16TB.
It seems pretty split as to who likes which provider. Don't let one blog post sway your opinion too much.
- Amazon, Rackspace, Joyent, Google App Engine and Azure and
- How do EC2's East, West, EU & APAC zones compare
Drop me a note if you are interested in additional information, a similar test for your website -- prakash at cedexis.com
It's free and includes benchmarking and pricing data into it's recommendations.
http://www.cloudsigma.com/en/our-cloud/how-we-compare (feature comparison)
https://cloudsleuth.net/web/guest/global-provider-view (select Europe for a comparison of our cloud performance against other providers)