Cloud computing: EC2 and App Engine

The cloud computing will be big; there are no doubts about that. Why deploy your own distributed and scalable infrastructure when someone else can do it for you for minimal cost? Cloud computing based on virtualization means that people can potentially have full control over the deployed machines without worrying about physical hardware maintenance.

There are currently two paradigms surrounding how to provide cloud computing capabilities, one championed by Amazon´s Electric Computing Cloud (EC2) and the other by Google´s still-in-beta App Engine.

EC2 was created around the concept of virtual appliances. Independent Software Vendors (ISVs) create XEN-based appliances that can be deployed to EC2. Virtual machines can be started and stopped on-demand, making this the first commercial service that offers computing resources as a utility where users pay for exactly what they use. EC2 is powerful--virtually any Linux-based application can be ported to this platform.

The appliance model is picking up a lot of steam. Almost all the major Linux vendors are already onboard. Red Hat has its upcoming Appliance Operating System; Novell has its own SUSE Appliance Program; Ubuntu has a special Server Edition JeOS; and not to forget little rPath, which has been pioneering the appliance model since 2006. All of these products will or already do produce virtual appliances to run on EC2. A lot of new applications will be deployed on EC2. We are only seeing the very beginning of this massive trend.

Google´s App Engine´s model works on a level above that of appliances. Instead of offering users the flexibility of running virtually anything they want through creation of custom appliances, App Engine gives users a fixed environment, where they can run Python applications. For convenience of creating web-based applications, the Django web application framework is also provided. The documentation also notes that other ¨programming languages and runtime environment configurations are being considered for future releases.¨

App Engine are making a bet here that most future applications will have fairly homogenous runtime requirements. Gone are the days where most applications need to care about the exact kernel version they run on top of and the precise version of the system libraries. One fixed set of these will do for the vast majority of new applications. The use of scripting languages (Python, Ruby) and ones with intermediate runtimes (Java, C#) are on the rise. Different versions of these interpreters and runtimes can also be installed side-by-side.

Taking this idea a bit further, imagine App Engine as a giant repository of software indexed by vendor name. Python versions could be placed in /app/python, and C# in /app/csharp. These directories would be further subdivided into /app/python/prod/2.5/ and /app/python/dev/4.0/ etc. I sign up as a vendor too and place all my software in /app/xiaowen/. I can customize my the runtime environment for my applications to use a certain version of python by pointing at the path exported by the Python development team in /app/python. The power of this architecture comes from the fact that everybody can share their applications for everybody else to use. No more deployment worries here because there is nothing to deploy. Simply point at a provider´s directory and go (though of course, some local configuration may still need to be done). Imagine one giant computer containing a mesh of interdependent software that the entire world collaborates on!