I agree with you that applications need to be “cloud aware” and use their instances as simple building blocks to accomplish that feat. Unfortunately, that simply isn’t realistic for most companies. Unless you entered the tech world a mere few years ago, you’re likely coming from a traditional background: spin up a server, configure that server, and make it a part of your stack. That’s usually the path of least resistence and it’s a hard habit to change, especially when customers want to focus on building and testing the viability of their product. In fact, we’re usually out celebrating when we can convince our customers to use tools like puppet for consistent server deployments, as it’s almost always a small investment for a large return. However, when we stand up at the whiteboard and draw out the costs and time required to architect for instance failure, we almost always get pushback. To be honest, I usually agree with their decision. In the modern world of continuous deployment, “MVP out the door ASAP” thinking, and “build build build” strategies, start-ups don’t have that extra time to waste. Things will probably change in time, especially as software (databases especially) are built to handle failure internally… but that day is not today.

Granted, there are great Platform as a Service (PaaS) products that can live on top of services like EC2 and handle the chaotic drama of dying instances. Unfortunately, those platforms cost money, and a lot of companies are hesitant to use them due to vendor lock-in (then again, EC2 itself is vendor lock-in, but I won’t comment on the benefits of OpenStack here — that’s another response entirely). Furthermore, most PaaS offerings are limited in the technologies that can be used, and customers often-times end up spinning up raw EC2 instances anyway as a workaround. Moreover, I often see customers take a step backwards when they start at a service like Heroku and move themselves to chaos clouds like Amazon EC2. They’re going from a solid platform with underlying redundancy and complete abstraction to essentially bare-metal instances that can “die” at any time. Those bare instances make great building blocks, but those developers aren’t going to focus their time on treating them as such.

Amazon was the first major player in the market, and we can all admit that those looking to move to “the cloud” often choose Amazon simply because they’ve heard it’s the “right direction to go” and they are the “biggest player in the field”. Those are the types of customers that fail to architect for Amazon’s services, utilize instances like they would persistent servers, and experience all of the pain you describe in your post. No one can deny that there’s a market for a “happy medium” service.

While we’re a small organization with mostly small customers, I can happily say that we’ve worked with customers with hundreds of EC2 instances who still don’t have the spare developer cycles to focus on architecting for Amazon and handling failure properly. Luckily, many of those start-ups succeed long-term and can re-iterate their product until they get it right and can handle most failures. Until then, they should feel fortunate enough to have a persistent cloud underneath the hood to nurture them as they grow.

Again, I compliment you on your blog post. I like Amazon EC2, but I think it’s important that people understand how it was designed to be used and what kind of thinking is required to utilize it successfully. Let’s not ignore that much-needed “middle ground” that companies like Rackspace offer… they’re doing it on purpose, and they’re doing it quite well.

So far, I’ve been one of those people. At my last job, I led the deployment of an automated configuration management system that was a big step towards being able to run in an AWS-like environment, but we ended up stopping short because, as it happened, we had more important issues to deal with (ie. why our growth rate was pathetic) and so never implemented and tested failover for all the services. My personal “server” is hosted on Linode (a company that competes with Rackspace’s persistent virtual server offering). Getting it ready for AWS just isn’t worthwhile.

what I’ve done is to sneak “grid instance” into conversations about AWS / EC2 since this seems to catch better. I mean, compute unit or whatever should make it clear enough, but so far it’s not taked hold with many people. Just the same it’s not easy for everyone (i.e. me) to rewrite their applications as something cloud-ready that fully supports scaling out through the whole “stack” (I mean, like multiple IPs, multiple service instances and still keeping things transactionally synced)
By now, I see a trend to re-define the classical cloud vm. i.e. on Webhostingtalk.com you’ll find providers saying that “it’s not a true cloud if you can’t resize the memory” (yeah right, like it would matter if you just spin up a new bigger instance and phase out the smaller one) or “cloud hosting” being used to define “if the vm fails it will be launched on another host” – with the original data.
It makes me cringe twice, first because I hate people redefining stuff so it matches their old-fashioned offers and second, because they won’t be liable if someone follows their false advertising on a real cloud infrastructure. We all know the joke about how “you get to keep the pieces” after a failure.
Imagine you were at some cloud-redefining hosting company and switch over to a cloud that is really one, more concerned with spinning up a few 100 more instances of your service than treating each single instance as a VM that has no backup, no SAN storage, …

I wish them a good lawyer to sue the old shop for their false advertising.