Considerations in Building Web Applications for the Amazon Cloud

By George Reese
October 17, 2008

I have been helping several clients lately migrate part or all of their infrastructure over into the Amazon Cloud. The biggest concern I am seeing relates to whether or not their existing web applications will work OK in the cloud.

Of course, if your application works OK outside the cloud, it will work OK inside the cloud. EC2 instances are, after all, mostly like any server they might be running on today assuming you can craft an AMI (machine image) with your choice of OS configuration.

But there are certainly "gotchas", and there are also some things you need to consider if you want your web application to take advantage of what the cloud has to offer.

S3, EC2, SQS, FPS, and SimpleDB

cover imageProgramming Amazon Web Services — With this book, you'll learn how companies can take advantage of Amazon Web Services (AWS) to "rent" computing power, data storage and bandwidth on Amazon's vast network infrastructure.

1. Licensing – Licensing is the number one killer for people wanting to leave the bonds of physical hardware and move into the cloud. The Cloud is where Open Source really shines. If you are all Open Source, you are in great shape in the Cloud. If, on the other hand, you are using some piece of software with licensing tied to the number of CPUs or servers you are using, you might be in trouble.

How many "CPUs" or "cores" you have in the Cloud does not have an easy answer. Furthermore, if you are bringing servers up and down based on demand, you may have to purchase licenses to match your peak capacity needs even if your peak capacity happens for 15 minutes each quarter.

2. Persistence – Application persistence (how you make sure you application survives across time) works much differently in Amazon EC2 than it does on a traditional server. Amazon's Elastic Block Storage (EBS) product has brought persistence closer to the traditional model, but it is still different. In general, you want to minimize the amount of persistent data that needs to be stored in a file system (basically, zero data) and maximize the amount of persistent data stored in a database.

3. Horizontal Scalability – Build for horizontal scalability. In other words, make it so "state information" does not reside in your application server or so that your application server can be clustered. In general, I recommend avoiding clustering at the application server level whenever possible. Application server clustering is much more complex than the alternative, load-balancer scalability.

If you can keep state in a database and simply add new application server instances behind a load balancer, you are in great shape for the cloud.

4. Disaster Recovery – The math favors physical hardware. If a given piece of hardware has a mean time between failure (MBTF) of x, an infrastructure built on that hardware is going to have a greater MBTF than an infrastructure built on virtual servers using that hardware. In other words, an instance in the Cloud is necessarily less reliable than an physical instance. Nevertheless, the Cloud makes it easy to create a high-availability infrastructure on the cheap and get disaster recovery almost free. If you don't do any disaster recovery plans, however, you will have a miserable cloud experience.

You might also be interested in:

News Topics

Recommended for You

Got a Question?