Blog Post

Amazon's cloud crashes


You have probably already heard the news that many customers running Amazon's cloud computing services had an extended outage last week. More specifically, a big chunk of the hosting services offered by Amazon - including S3 and EC2 were down for a day and a half. This left many high-profile start-ups, as well as more established companies, completely out of service.

At HubShout, we've considered using Amazon web services (AWS) for our hosting needs, but have never seen the business case become strong enough. Even so, we re-visit the issue annually as we adjust our business plan and ensure our technology configuration is scalable. As you know, our SEO reseller program has been growing rapidly this year. As such, we have pushed out several large infrastructure projects with the goal of adding capacity and increasing redundancy. These are the very same business objectives that many companies have for moving to Amazon's virtual hosting services.

For those who don't know, here is a quick primer on what Amazon Web Services really are and how they relate to tradition data center hosting. AWS is in many ways a traditional hosting service. At the end of the day, you are paying someone for servers in a redundant, secure and reliable data center. This means all the things it usually does: Fire suppression systems, tight security, 24x7 monitoring and backup power. It also means having many different pathways to the Internet so your physical connectivity and routing is diversified. All of these "features" create reliability for your application. However, Amazon's hosting services differ in some very fundamental ways from traditional data center hosting.

The biggest difference is the on-demand nature of Amazon's service. You can order and configure an entire rack of servers through Amazon's web interface, paying via credit card. You can spin up additional servers in a matter of minutes. You can also do this programmatically through API calls. This is very different from the traditional data center procurement process - which can be quite lengthy. As you think this through, you start to grasp the power of what Amazon has done. For example, you could architect your application so that loads and response times were monitored. As the application slows due to load, it could bring more resources (such as web servers) online automatically to meet the rising demand. Likewise, it could spin itself down to lower capacity during off-peak hours. Very spiffy.

The pricing model is also very different with Amazon's hosting. It is essentially a throw-back to the mainframe pricing standards of the 1980's when people paid for "CPU time." Because the hosting is so virtual, and on-demand, Amazon has revived the old financial models of the mainframe. The idea here is that you pay for only what you use, and you use only what you need. Again, this philosophy is only possible because of the additional layers of virtualization Amazon has created. While you can install and run this type of virtualization yourself in dedicated space, you are still paying for the rackspace (and related support services) when those resources are offline. With Amazon's mainframe pricing model, you are not. In theory, this should lead to lower overall hosting costs.

All-in-all, I think Amazon's approach to data center management is novel and useful. There may be a role for it in HubShout's future - but not until they work out all the bugs and can meet the uptime and reliability promises they tout. Also, I think the pricing has further to fall before the business case looks more attractive to teams who know their way around the less expensive data center cages that exist in many less glamorous locations.