In the first part of this series we discussed the definition of cloud computing and its various flavors. The second part of the three part series focuses on the offerings from three major players: Microsoft, Amazon, and Google.
AWS is a collection of services offered by Amazon to implement Amazon’s vision of IaaS and to some extent PaaS. Some of the main services of AWS include: EC2 (Elastic Compute Cloud), S3 (Simple Storage Service), & SQS (Simple Queue Service). Amazon differentiates itself from the other two players by providing PaaS and IaaS in an integrated package. You can simply start an instance of a Windows machine or a Linux machine and select either a big machine with lots of memory and CPU or a small one.
Once you have an instance you can interact with it via remote services and install any software you want and configure it. If you had a Java application that used Tomcat and MySQL running on an old server under someone’s desk, you could simply start a desired size machine instance, install Tomcat/MySQL, and start running your application from EC2 without changing any code. However, this flexibility comes at a price. If the needs of your application went past the single largest instance EC2 can provide then you would need to re-architect your application to distribute processing across multiple large instances.
Of course the benefit of this approach is that it allows you to move your application into the cloud without rewriting code as long as your needs don’t outstrip a single instance. There are also no limitations in terms of programming language or software that you use. Your application can be based on J2EE, .Net, Python, Ruby, or anything else that runs on Windows or Linux OS.
Microsoft calls Azure a cloud operating system (PaaS) and as such it abstracts away the regular OS that we are familiar with. You write your application to specifically work with Azure using its storage, queuing, and other services and then simply publish it to run on the Azure’s compute fabric. The good thing is that you use all the tools that you are already familiar with to write an application (e.g. Visual Studio 2008).
After the application is written it can be tested locally and only published to the Azure cloud when satisfied. Once the application is running in Azure you cannot attach a debugger to it and must rely on good old log messages for debugging and gathering state information. Azure supports .Net as the de facto framework and supports assemblies compiled from any CLR-compliant language as long as they comply with Azure’s framework. The obvious drawback of this approach is that an existing application cannot be simply moved to cloud without rewriting its key components and perhaps without a complete redesign. However, the advantages are also obvious and significant; once you have written your application to run on Azure it gives you instant ability to scale by simply reconfiguring the number of instances your application runs on. This can be very powerful if your application’s usage is unpredictable or has a seasonal variation. Another issue with this approach is that it ties your application to the platform and you cannot simply take your application and run it in another cloud.
Google App Engine is a PaaS platform and is a combination of an instance service, a data service, and a queue service. It also hides the OS and hardware from the user/application like Azure. But it limits the application to be written in Python in order to be hosted on Google’s cloud. You have to write the application using the SDK provided by Google and once again you can configure it to run multiple instances and automatically benefit from seamless scalability and redundancy. However, you not only have to rewrite your existing applications you also have to commit to a specific language and platform which may not match the requirements or the skill set of your organization.