4sysops – One year Amazon EC2 – Part 2: Reliability and lack of elasticity

In my last post, I complained about the relatively high costs of Amazon EC2. I am sure you are curious to learn how I could then be so lavish to run 4sysops in the cloud. But first let me share a few words with you about the other usual suspect when it comes to arguing for cloud computing and that is reliability.

Reliability

Before I moved 4sysops to the cloud, it was running on a dedicated server and throughout the three years I had not one hardware related incident. Okay, this is just one server. I have some experience with the server hardware from well-known vendors and those experiences are not really positive. However, I have my doubts that cloud technology can significantly improve uptimes at the moment. This technology is relatively new and complex. There are only a few cloud providers and much has yet to be learned about reliable management of these huge systems.

In this one year with Amazon, there was at least one incident with my virtual server. You might have read in the news that Amazon had some problems with its storage system a few months ago. It appears that 4sysops was affected. I am not 100% certain about this due to the fact that Amazon didn’t contact me, but I think it was no coincidence that the storage where my database volume resided suddenly disappeared.

Lack of elasticity

If not for reliability, then perhaps elasticity: the other main argument for cloud computing is a good reason to adopt this new technology. To know that I could easily launch additional servers (instances) is nice, but even if 4sysops grows so quickly that I need additional resources, Amazon EC2 is not really the best choice. Of course, I can launch a more powerful instance with a few mouse clicks. The main problem is that the instance I reserved for three years can’t be used for other instance types.

So let’s say that I just need more RAM, which is the most likely case. Then I can’t just move my reserved instance to one of the instance types with more memory. If I do launch a high memory instance, I need to buy another reserved instance for this virtual machine type.

If I have a memory shortage problem with a dedicated server at a service provider, I can, in most cases, book a more powerful server, and get out of my old contract without much hassle. Thus, in a way, traditional server hosts offer more “elasticity” than Amazon EC2.

Of course, if you have a memory problem with an on-premises server, you can simply buy more RAM and you are done. In contrast, adding memory to an EC2 instance is not possible. All you can do is start a new instance, which means in my case, that I must move all the software and settings from the old server to the new one.

Hence, I even need to live with less elasticity here compared with on-premises computing. This is due to the fact that I had to move from a 32-bit instance to a 64-bit instance because Amazon does not offer 32-bit instance types with more than 1.7GB. I am currently using a 32-bit machine because the 64-bit instances are so expensive that even I (a cloud fanboy) could no longer justify the costs.

I admit that this sound all quite negative and you probably wonder I bother at all about EC2. This will be the topic of my next post.