AWS Case Study: uSwitch.com

uSwitch.com was acquired by Forward in early 2010. I am one of the technical leads working to modernize and improve the software and infrastructure that runs the site and the business.

How have you incorporated Amazon Web Services as part of your architecture? What services are you using and how?
uSwitch.com is currently a combination of many .NET applications and services, which are run on our own hardware. We are gradually replacing this structure with a mixture of more modern technologies (including Ruby and Clojure; MongoDB and MySQL). These are all deployed using a range of Amazon Web Services (AWS) technology: Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Load Balancing (Amazon ELB), Amazon Simple Storage Service (Amazon S3), Amazon Relational Database Service (Amazon RDS), and Amazon CloudFront.

We use Amazon EC2 successfully in other parts of the business and were keen to take advantage of its geographical redundancy, ease of deployment, and ability to scale computing power as demand requires. Our existing infrastructure is relatively under-capacity but spikes heavily when uSwitch receives PR coverage when energy companies increase their prices, etc.

The figure below gives an overview of the two parts of the system. Some visitors arrive directly to applications running on AWS. The majority of www.uswitch.com integration is proxied by IIS to the front Amazon ELB instance. We would like to move more of this routing into the BigIP load balancers but have not done so yet.

The newer infrastructure is predominantly deployed on c1.medium instances (although the MongoDB instances are m1.large). We also have a few applications that use node.js (which are primarily for tracking and internal monitoring tools). A particularly popular application is a node.js application that receives pings from the site when people switch their energy supply. For this application, a front-end was built that takes the geo location information and maps it onto Google Earth; we then had a display showing the map jumping around as people switched (and how much money they saved).

What programming languages and/or tools did you use to build this solution?
We use a lot of programming languages and tools: the websites are almost all Ruby-based and use either the Sinatra or Rails application frameworks. We have two additional applications that are used for tracking. These applications are extensions of existing technology that had been developed elsewhere in the business, based on node.js.

Energy comparison is the primary target of uSwitch (representing around 80% of all visitors to the Website). This application was our initial focus for the migration to Amazon EC2, away from C# and .NET. The pricing and comparison part of this application is written using Clojure, a lisp that runs on the JVM. All energy plan information is stored on our three instance MongoDB cluster. We also use the same cluster for holding session information that some of the applications use.

Why did you decide to use AWS?
We’d already used AWS successfully to handle very large volumes of traffic. We were interested in using AWS for this project for a couple of reasons:

1. We were believers in embracing the ephemeral nature of Amazon EC2: building applications to handle (and tolerate) failure was a good thing.
2. We believed the majority of the existing hardware was heavily under-utilized and would burst for a couple of months a year. We felt we’d be able to better handle load at peak times while also saving money in the long-term.
3. Being able to provision different machine types quickly was a particularly good thing for developers—when we have an idea, we want to be able to test and build it quickly. The Amazon EC2 model makes it much easier (and more cost effective) to experiment than using our own hardware.
4. Being able to deploy instances in redundant locations was important: uSwitch had previously placed a strong emphasis on 100% uptime through expensive infrastructure and hardware. At Forward, we’d had great success using technologies like Hadoop and building systems to tolerate (and expect) failure. Deploying into redundant locations made this more achievable.

How has AWS helped your business?
AWS offers a fantastic environment for development teams. Developers have been far happier taking ownership of automating deployments with tools like Puppet than the previous (and more formal) IT ops/hardware. We’ve been able to experiment more and take more risks, safely. In the long term, we believe AWS also provides a superior way of adapting to demand and focusing on profitable utilization of resources.

Can you share any metrics on your usage of AWS to date?
We have around 20 Amazon EC2 instances that run 16 different applications. We will be migrating around 10% of our total traffic onto the new infrastructure for Energy, and then gradually increasing this to ensure there are not any technical hiccups or adverse conversion rate changes. Once fully migrated, we will be handling around 300,000 daily page views (although this increases substantially on peak days).

Have you learned any valuable lessons during this development process that you’d like to pass on to other developers?
We have generally embraced the fault-tolerant mindset that we feel needs to be adopted for a deployment onto an infrastructure like Amazon EC2. For a few of the smaller, non-energy related applications that we’ve deployed, we have used single zone Amazon RDS. Since then, we’ve been strict about ensuring that all applications gracefully degrade when connecting systems respond slowly or not at all.

Do you have any future plans to incorporate other AWS solutions?
Our use of Amazon EC2 has been increasing steadily as the business grows. More teams are building new products and are using Amazon EC2.

To learn more, visit http://www.uswitch.com/ .

Added May 31, 2011