May 08, 2012, 3:22 PM — Last week I wrote about the fact that IT organizations are now executing an "and" cloud computing strategy, in the sense that their future plans include (most likely) an internal cloud based on VMware and an external cloud (most likely Amazon Web Services).
I pointed out that the traditional model of managing virtual machines--creating a VM template that contains all the software components that the VM contains--is inappropriate in a world in which applications may be deployed internally, externally, across both internal and external clouds, and even transferred between internal and external clouds. This is due to the fact that the virtual machine images are typically incompatible across deployment environments.
V2C Outdated For Today's Cloud Application Lifecycle
One solution often proffered is to put a template image through a conversion process (commonly referred to as virtual-to-cloud, or V2C) to make it able to run in another environment. There are two problems with this solution, however.
While V2C is efficient for a one-time, one-way conversion, it's a nightmare in an environment in which images must be run in multiple places. Trying to repetitively convert images is labor-intensive and error-prone.
Even more challenging is the fact that the mental model of conversions is increasingly outdated in today's IT world. The vision underlying the conversion process is that of a stable image with static software components that rarely change. The reality is that today's applications are constantly evolving with changes going on continuously. The entire agile movement is directed against large, static releases, recognizing the fact that the "Big Bang" release theory too often delivers obsolete code well past deadline.
The new model is frequent small code releases with small amounts of incremental functionality. In fact, there's a name for this approach: continuous integration. This process lets you constantly check progress and make quick course corrections long before you're lost and becalmed. This agile approach militates against the "one and done" conversion approach.
Given these two issues, an operations approach that is based on transferring large static templates around is doomed. Simply put, the speed of application evolution finds the plodding pace of template conversion and movement intolerable.