| By Patrick Kerpan |
Article Rating: |
|
| August 28, 2008 04:30 AM EDT |
Reads: |
11,151 |
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.
Patrick Kerpan is the president and chief technology officer (CTO) for CohesiveFT, provider of onboarding solutions for virtual and cloud computing infrastructures. CFT's Elastic Server platform is a web-based factory for creating, deploying, and managing custom multi-sourced servers comprised of horizontal, open source and third-party software components. Additionally the VPN-Cubed packaged service gives customers control of networking in the clouds, across clouds, and between their private data center and the clouds. In this role, Kerpan is responsible for directing product and technology strategy.
Kerpan brings more than 20 years of software development experience to the role of CTO and was one of CohesiveFT's founders in 2006. Previously he was the CTO of Borland Software Corp which he joined in 2000 through the acquisition of Bedouin, Inc., a company that he founded. Kerpan was also the vice president and general manager of the Developer Services Platform group at Borland, where he was instrumental in leading the Borland acquisition of StarBase in 2003.
Before founding Bedouin, Inc., Kerpan was a managing director responsible for derivatives technology at multiple global investment banks.
Subscribe to Ruby-On-Rails Email News Alerts
Subscribe via RSS
