Back in early December someone in #habari who knows that I’ve got an EC2 server asked me what I thought of them. When I told him I preferred my Rackspace Cloud Servers for a variety of reasons he asked me to enumerate them. The conversation that ensued covered a lot of ground and really made for a great blog post.
Since it’s been almost two months since then and I haven’t managed to finish that blog post and I’d really like to reference several of the points in other material, I decided to break them up into individual posts in a series.
With the exception of this first point, which is highly important and my number one reason for even starting on this topic, everything is totally unorganized and in no particular order. Certain aspects matter more than others in different application designs and configurations, so just pick the ones that matter to your design and feel free to skip over the rest — it won’t hurt my feelings, promise.
It’s Ephemeral!
First and foremost, and this can’t be said nearly enough for all those people jumping on EC2 because it’s flexible, EC2 instances are ephemeral. That means they can and do disappear at random. If there is a hardware failure in the physical node that hosts your instance it will simply disappear, along with any data that isn’t on an EBS device; you’re supposed to account for these types of things in your application design.
That means either some kind of heartbeat / load balanced setup1 where a server that disappears is automatically removed from the rotation or some other kind of monitoring, possibly a similar heartbeat system that uses that API to immediately spin up a replacement for the missing instance2.
Chances are the vast majority of individual users who have chosen to jump into the “cloud” with EC2 haven’t done this right and are only settings themselves up for disappointment and heartache. In fact, judging by a lot of the things I’ve read online about different EC2 implementations and migrating to AWS, a lot of larger operations have probably gotten this wrong too.
So right out of the gate Rackspace is simply a better fit for my uses. With Rackspace you get a standard VPS (albeit one that can scale virtually instantly - either vertically or horizontally). That means the instance exists and should continue to exist. If the hardware in a single host node failed they roll all the clients on that node over to new hardware and bring them back up.
I still need to account for this in my design so that a single node failure doesn’t break my application for half my userbase, but it’s a much simpler process simply because you can think of your instances in terms much more like those of physical servers; these are just physical servers that can instantly provision and scale.
- Think Elasitc Load Balancing, something additional to pay for. ↩
- Which further implies that you’ve got new-instance-creation fully automated, which you really should for anything more than the most basic configuration. ↩