EMC means Even More Clouds

Last week, Doug Merritt, an executive vice president at SAP, informed Information Week that EMC is planning to offer a computing utility service suitable for running enterprise applications. This “cloud” (a term popularized by Amazon's Elastic Compute Cloud) would offer SAP an ability to deliver on-demand applications to enterprise customers without investing the significant fixed costs of large scale datacenters ala Salesforce.com. The cloud capability is likely to make heavy use of the VMware hypervisor technology owned by EMC (Amazon uses the competing technology called Xen) such that providers like SAP can define their applications as virtual appliances (or a set of virtual appliances, known as a virtual appliance network or VAN) and launch them on-demand into the cloud. ISVs such as KnowledgeTree are already doing this using virtual appliances and Amazon's cloud. Why not SAP with an EMC cloud? What is the likely scenario for enterprise adoption?

As enterprise customers increasingly virtualize their datacenter computing resources, it is going to become more and more common for them to rely on computing clouds outside of their datacenter for certain application workloads. Once you have virtualized the infrastructure and defined the applications you run as virtual appliances (i.e. they are defined independent of the computer that they run upon and are loaded on the virtualized infrastructure pre-configured with the OS), moving the application from datacenter to datacenter (or cloud to cloud) becomes much easier.

Rather than buying all the servers required to deliver the application at peak load, it makes more sense to launch new instances in the cloud during peak demand and pay a variable cost charge until the peak subsides. Similarly, batch oriented analysis that occurs once per day/week/month (perhaps closing the books and logging transactions at the end of a month) is an ideal application scenario for cloud computing with virtual appliances. Why own the servers when you only use them periodically? Is it becoming clearer why SAP and EMC might be collaborating on this type of service? It's pretty clear to me.

But what's missing? Why is this obvious scenario not already mainstream? To begin with, production implementation of virtual infrastructure is only now beginning to take hold. Historically, virtualization was used extensively in test and development or to curb Windows server sprawl (a condition that occurs because Windows cannot effectively host more than one application per OS instance). Now, enterprises are beginning to understand that virtualizing every application makes sense because it separates the evolution and maintenance of the application from the evolution of the hardware infrastructure.

For example, it makes much more sense to create a virtual appliance for an existing single-threaded application and run several instances on a dual socket, quad-core eight way machine than to attempt to re-write the application to take advantage of the quad-core threading model. There is no value in the re-write, and virtualization provides a means to scale the application to take advantage of modern hardware. Another obvious benefit of this separation of application and hardware is server maintenance. You can shutdown one virtual appliance to patch it and then spin it back up without disturbing any of the other virtual appliances running on that server. This approach minimizes application to OS conflicts, and it eliminates application to application conflicts.

If virtualized production infrastructure is a cloud requirement that is slowly becoming a reality, what other obstacles lay on the path to cloud nirvana? Well, the current most popular approach for virtualizing applications is building a working system from legacy components and then “snapshotting” it with your favorite physical to virtual (P2V) tool. This approach will not scale to cloud computing. First, it is unlikely that your cloud provider has a virtualized infrastructure that is identical to your own. Going through a manual, ad-hoc process to build snapshot images for each cloud is going to be slow, expensive, and prone to errors. Also, it is inevitable that cheap, variable cost computing is going to tempt enterprises to define ever increasing numbers of application images. However, the administration and maintenance burden of the legacy OS system layer is going to result in skyrocketing administration costs or a “don't patch it and hope for the best” security scenario. A new approach to system software that couples the application with just enough OS is a requirement to make cloud computing a scalable reality without untenable administration costs or security risks.

Finally, and perhaps most importantly, there needs to be some “context” language by which networks of virtual appliances communicate to the cloud their requirements for system resources, configuration, and service level. How does an application server communicate to the cloud to boot it on the same network segment as the database server it requires? How does a critical application that is CPU intensive communicate a requirement for 2 CPUs and 4 gigabytes of RAM? How do redundant application servers communicate a requirement to run on separate physical servers to preserve a failsafe capability?

An application architecture for cloud computing will take into consideration all of these current deficiencies. The application and all of its associated context information will be defined as virtual appliances and virtual appliance networks independent from the physical infrastructure. The general purpose OS will give way to a just enough OS approach to enable a more simple and scalable maintenance model. And there will emerge cloud release and service brokering systems for launching applications into the clouds at acceptable service level without error prone manual processes and extraordinary administration expenses. These changes are coming. What are you doing to get your enterprise on the path to cloud computing?