Moving To The Cloud Is Not Cut And Paste

One of the issues I have been thinking about is the requirementsnecessary to move an application to a cloud service and, to someextent, move it with little impact to end users. Amazon's VM Import serviceis getting a lot of buzz lately, but the service itself is about asinteresting as converting a Microsoft Word Document to PDF. Sure, it'suseful, but it's only half the story. Virtual machine (VM) conversioncertainly isn't a game changer for hybrid clouds. Just because you have a VM in your data center doesn't mean you can simply push it to Amazon's EC2 and call it a cloud.

Christofer Hoff, the director of cloud and virtualization solutions for Cisco's Security Technology Business Unit, said it best in a 2009 personal blog entry: "Incomplete Thought: Virtual Machines Are the Problem, Not the Solution": "VMs have allowed us to take the first steps toward defining, compartmentalizing, and isolating some pretty nasty problems anchored on the sins of our fathers, but they don't do a damned thing to fix them. VMs have certainly allowed us to (literally) 'think outside the box' about how we characterize 'workloads' and have enabled us to begin talking about how we make them somewhat mobile, portable ... There's a bloated, parasitic resource-gobbling cancer inside every VM. For the most part, it's the real reason we even have mass market virtualization today."

If you move a VM to a cloud service, all the problems and limitations move with it. You can only scale vertically before you reach the performance limits by adding more CPU, RAM or IO. Microsoft Exchange 2003 and earlier is a good example where you can add users only for so long before you need to add another server. Breaking up big applications into smaller tiers that can be augmented by adding more of some resource at each tier is one way to increase performance. Exchange 2007 started to break that monolithic model, and certainly Exchange 2010 goes much further. Microsoft's migration from Exchange 2003 to Exchange 2010 (not including the ForeFront Security features) meant a re-architecting of the entire application.

Architecting applications for the cloud is not a matter of just moving process to separate physical boxes or virtual boxes; the inter-process communication needs to be figured out. For example, the underlying network assumptions have to be addressed. Will all the services be on the same network? Will they communicate using unicast, broadcast or multicast? Are the services named in a way that doesn't rely on fixed addresses--i.e., using DNS or something similar? Can the services act independently of each other? Is there a way to notify other relying services, in tiers above and below, that a new instance is available? Is there a way to bleed off connections so that you can gracefully remove the service without cutting off users? I am just beginning to scratch the surface, I haven't touched on storage or discussed making the service available to stakeholders, but you can see why moving a VM to a cloud service is not a hybrid cloud service. There are many, many moving parts that need to be addressed.

Building applications in tiers is not new. N-tier Web applications that have a front end to connect to users, an application tier to perform application processing and a database tier for data storage and retrieval have been built for years, but adding tiers doesn't magically make scaling problems go away, because each tier can be monolithic and inflexible. The move to Web services and the service-oriented architecture (SOA) that was all the rage a few years back was probably the first big step in breaking the tiers into atomic units that could scale horizontally by adding more services into a tier. Each part of a SOA application was responsible for a specific process, much like functions and objects in modern programming languages are responsible for specific processing needs. RESTful services are one way to pull off inter-process communication.SOA is a good step and may be enough for most organizations applications. But to leverage the cloud effectively means taking application development one step further, and building applications for a cloud deployment, the topic of Amazon's "Architecting for the Cloud: Best Practices." Whether you are planning on using Amazon or not, you should read this before embarking on a cloud application strategy.

Jinesh Varia writes, "The cloud is designed to provide conceptually infinite scalability. However, you cannot leverage all that scalability in infrastructure if your architecture is not scalable. Both have to work together. You will have to identify the monolithic components and bottlenecks in your architecture, identify the areas where you cannot leverage the on-demand provisioning capabilities in your architecture and work to refactor your application in order to leverage the scalable infrastructure and take advantage of the cloud." The rest of the paper touches on key application architecture topics that your development and IT team (servers, storage, networking and management) need to evaluate and address. Like any new IT process, the first project will be the most difficult, since you are learning new things and applying new strategies. Subsequent projects will be easier.

The key takeaway is that the way in which your applications are built today will have to change. Moving a VM from your data center to a cloud service is not a hybrid cloud. It's simply relocating processing from here to there. Adapting existing applications that split processing between your resources and a cloud service is a hybrid cloud. For example, a government agency needed to share geographic data with commercial entities, but, due to DHS restrictions, they had to restrict access to parts of the data set. To complicate things, the application usage had a very spiked demand curve, with periods of high utilization and periods of low utilization.

They could have simply altered their existing application with access controls and provisioned enough hardware and bandwidth to handle the high demand periods, but, like any other provisioning scenario, that would have been costly from an operations standpoint. Since they were going to re-architect their existing application anyway to implement access controls, they decided to push the processing out to a cloud service that would give them the flexible scaling they needed in a cost effective manner. They created a cloud application that their customers could access and integrate with, and they modified their existing application to provide a service that returned only the necessary scrubbed portions of data.

Their hybrid cloud application turned out to be much more effective, since they didn't have to implement access controls in the existing application and they off-loaded demand processing to a service that could scale dynamically. Simply moving a VM to a cloud service wouldn't have cut it. Cloud computing and hybrid cloud computing may be hyped in 2010, but there is real value behind the hype, and we are just starting to see use cases. Cloud alone isn't going to solve your problems, but, like any tool, it can solve many seemingly difficult ones.