Ted Dziuba's post on the pain associated with cloud based virtualization and how we continue to live with the pain even after Amazon service degradation bludgeons Reddit to death every few weeks is a must read for anyone who has hosted anything on cloud based virtual servers.
Ted talks about the general issue of promises being made around cloud based services and virtualization. He explains:
Amazon EC2 has a stated service level agreement of 99.95% uptime, yearly. As of right now, EC2's uptime is 99.23%, well below the SLA. Since computer programmers like to take a pathologically literal interpretation of the law and contracts, they usually don't understand the reality of such matters.
"But, but, EC2 is violating their SLA! That can't happen!"
"It just did."
"But, but...Segmentation Fault (core dumped)"The trouble with SLAs is that shit happens is not yet in the vernacular of modern jurisprudence. You should never try to compare hosts based on SLA, compare them based on how they respond to downtime, because it will happen everywhere you go, without fail. For example, the machine that is serving you this web page is a physical box hosted by SoftLayer at a data center in Seattle. Last week, I had about an hour worth of downtime because of some networking problems in their data center. Whatever, like I said, shit happens. What I'm really looking for is communication. I logged a ticket with support, and in six minutes they updated me about the situation, how widespread it was, and an ETA on the fix. The tech also asked if there was anything else he could do for me. They restored connectivity quickly, but did not keep me in the dark about what was going on.
Try that with Amazon. There's a thread on the AWS forum where some genius decided to host safety critical software on EC2, and can't get his data up. The thread was posted on Friday, it's now Saturday, and with Sunday coming afterward, I'm pretty sure that nobody whose safety depends on EC2 is looking' forward to the weekend. Now, maybe it's a troll, but not even a "we're working on it" reply?
The post has three highlights that every developer should be aware of before they deploy on a cloud based Virtual Machine:
- SLA's are totally meaningless.
- Databases aren't designed for magical logical writes. They are built under the assumption that there is an atomic way to commit data to a physical disk.
- Virtualization has it's uses and the only sensible criteria where you should use cloud based virtualization (in Ted's words) is, "if the machine eats shit, nothing of value will be lost".
Go read the post, even if you're just a blogger who doesn't have a million readers and are running your tiny little blog off an EC2 instance.
You need to read the post because what you know usually doesn't kill you. Having realistic expectations of downtime and data loss, doing sufficient backups, developing the ability to move to a different server and the ability to change your DNS host record at the snap of a finger doesn't hurt one bit.
Finished reading the post?
Good. Now go ahead use EC2 if meets your needs. I do it too.
Here's why:
- Amazon now does offer paid technical support which actually lets you speak to real human beings in seconds.
- EC2 instances (specially the micro instances) are the cheapest options that most small business and bloggers who want remote access to their servers, have.
As long as you're aware of the pain involved and the workarounds we're good. The other thing to remember of course is that you always have the switch in your hands to flip if the pain does get out of hand. Of course cloud based virtualization can hurt you, but knowing how it can hurt you, makes you all the more confident and pragmatic at using it.
Comments are closed.