Adopting virtualization is not without friction

This much is clear, advanced virtualization techniques are here. Some time ago, we moved beyond base operating system virtualization, towards virtualization approaches that render more functionally complete systems. From single virtual images that contain entire software stacks (i.e. LAMP, JEE servers, content management systems, etc.), to virtual appliances made up of many images integrated to satisfy particular workloads, the functional encapsulation provided by various virtualization techniques continues to expand. On the surface, this is an obvious benefit to end-users, but that does not mean it comes without challenges.

Because of our IBM Hypervisor Edition offerings, I get the chance to talk to quite a few users considering or already starting down the path of advanced virtualization usage. Many of the challenges users discuss with me come down to a friction between standardization/commoditization versus customization. One of the main benefits of virtual images and appliances (besides server consolidation and rapid provisioning), is that they encapsulate the results of installation, integration, and configuration of a given set of software components. This eliminates processes that were, at best, tedious, and often times error-prone and nearly impossible to repeat in a consistent manner. Users get what they should be able to assume are best practice deployments for the software in question.

However, the same technique that eliminates tedious, human-driven, error-prone processes also results in considerable friction. By consuming this method of service delivery, users essentially agree to various degrees of commoditization or standardization in the software stack. Believe me, there are many opportunities for friction here, including:

– Type and version of software components: If anyone tells you about the commoditization of operating systems do not listen. For the most part, users are intensely loyal to their operating systems. Some times this is cultural, other times there is substantial business motivation (i.e. existing skills, type of physical infrastructure, etc.). And that’s just the operating system.

– Configuration of installation: Beyond the type and version of installed software, many users need (or in many cases, simply want) control of exactly how it is installed. As hard as it may be to believe, some users can’t live with software not installed to a particular file system location. (Note: To be entirely fair, sometimes existing management script dictate this. Other times it’s just senseless.).

– Configuration of integration: Given software component A and software component B, users will derive a myriad of ways to integrate the two components. There is absolutely no way to anticipate all of these integration configurations within a virtual image or appliance, much less allow for them.

While the degree of friction varies from user to user, invariably there is always some. The best advice I can give in the face of this friction goes along these lines:

– Identify your degrees of variance: Determine how different the environment produced by the virtual image or appliance is from the environment you produce manually.

– Categorize the variance: Determine if the differences are important. By important, I mean determine if they have a tangible impact on the quality of how you can deliver or manage the service, or if the difference would incur actual costs (i.e. investment in rewriting scripts to deal with different installation locations). Try to avoid categorizing variance as important solely because it is a departure from the way you do things today.

– Make a plan to address the variance: For variance you deem to be important, determine if there is a mechanism by which you can correct it. Typically, these come through capabilities of tools that deploy and manage the virtual images and appliances. This may include methods for tweaking the contents of the virtual image, adding configuration actions to the image activation process, or adding steps to the end of the overall deployment process for the system.

This kind of thought process seems to resonate with many users. Of course, there are ‘gotchas’ along the way, especially at the ‘Make a plan’ step. Some users cannot address their particular points of variance, or the costs to address that variance is simply too high. In those cases, I have no qualms telling them that this mode of service delivery is not a wise choice. Largely though, I believe advanced virtualization applies and brings significant benefits to many situations. So in short, be on the lookout for virtual image and appliance forms of the services you use on a regular basis.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: