Best Practice: Cloud Computing

Red sky at morning, sailor take warning.

Here’s a forecast: clouds are rolling in. Architecting for cloud computing will, very soon, become a conscious best practice.

There are lots of handy objections to Cloud Computing: Regulatory compliance, geographic containment requirements, taxes, liability, vendor lock-ins and lack of standards. Many are brushing off cloud technologies as a result, and maybe rightly so… for about another minute, anyway.

Last year, I was involved in a client’s effort to re-provision an application from an in-house infrastructure to a SaaS vendor. All told, the effort was risky and enormous. The administration of it took a year. It took a team of talented engineers from several different companies over six months to implement the transfer. When it was done, everyone breathed a sigh of relief.

The amazing part was that it wasn’t about changing applications. It was just changing who hosted the application. Simply put, no one had the fore-sight to architect for a transition of this nature, and so the ROI was heavily diluted.

Market fluctuations, re-focused specialization, business units changing hands, economic right-sizing, disaster recovery; there are many reasons agile infrastructures can be useful. Cloud computing technology is evolving quickly and has the very real potential to offer agility at a dramatically lower cost, if you’re prepared to leverage it. You don’t have to go in to the cloud to see what you might gain from it. The important part is preparing for it so you can use it when it makes sense for you. And, you could even go green at the same time.

I won’t try to predict what your organization has to gain by architecting around cloud technology. It’s more about what your organization is at risk of losing if you don’t.

Cloud Computing Trends: Thinking Ahead (Part 2)

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.

Amazon (AWS)

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 (Azure)

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)

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.