Patruck Kerpan's Blog

How should enterprises or Cloud Providers react to the VMware "August 12th surprise"? To those who may not have heard - the latest versions of VMware's ESX hypervisor started shutting down as the hypervisor clock hit the date of August 12th. This was due to what amounts to a hardcoded shutdown being left in the server from its evaluation days.

Clearly if you are an enterprise dutifully "up to patch" this would have put a big hurt on your operation, IF virtualization was more ubiquitous in the production data center. The fact is enterprise data centers don't have a lot of mission critical virtual machines in production - yet!

I am not kicking VMware - these things happen. But what if that had been a large-scale Cloud Provider? By definition, virtualization is 100% ubiquitous in virtualization-based clouds.

We know it is a heterogeneous world, and customers are in charge, which is why we are busily connecting our Elastic Server platform to some of the newly announced clouds. We want our users have a choice of deployment locations. And we want cloud users to have access to dynamically assembled virtual servers, instead of using quickly-stale templates. Given the early stage of this industry, each of these clouds is currently "monocultural." They use a specific version of a specific hypervisor - and require a virtual machine in that format (plus "fiddly bits", a frequently used technical term in our office). For example, Amazon EC2 takes an open source Xen image + Amazon fiddly bits. We are working with other clouds that take VMware + Fiddly Bits and Virtual Iron + Fiddly Bits.

Some clouds like Google App Engine and Heroku are "language module" clouds where the deployment vehicle is a package of code for Python/Django or Ruby on Rails and may have less of an issue in this instance. But, the clouds that take x86 containers as their deployment package don't really have to be monoculture clouds in the longer run. We could let customers decide if they want to provide virtual machines formatted for Parallels, or open source Xen, or Citrix Xen, or VMware, etc.. The cloud vendor would need a layer of traditional datacenter automation software to handle booting up physical hardware with the appropriate hypervisors to meet virtual machine demand. If customers are collectively driving single hypervisor behavior - offer discounts for other VM types to create a portfolio of hypervisors and VM types in the cloud.

Creating VM templates for customers to use in one VM format is painful enough. Supporting more hypervisors for more templates is even worse. Because of this and our belief that "like it or not, there will always be more of everything" - we built the Elastic Server platform to support all forms of hypervisors, OS's, middleware, and management environments; making it a great way for clouds and cloud users to be able to "re-manufacture" their virtual computers quickly for deployment to different formats and different clouds.

The reality is - just like with operating systems - no enterprise will have just one hypervisor type. As soon as you migrate everything to Hypervisor X, your company will buy a company that uses Hypervisor Y, or you will be bought by a company using Hypervisor Z. Should clouds, in the long run, do any less?

In the short run - this begs the need for x-cloud virtual machine assembly, x-cloud deployment tools, and x-cloud base level management tools, as well as x-cloud security frameworks so you can diversify your computing portfolio by running your virtual server clusters across multiple clouds.