Proceed with caution: Taking the long-view on Virtualization

I was recently pointed to Amrit Williams' excellent observations about virtualization -- including the myths and misconceptions about it as well. Amrit's observations are a really great place to start when you're considering a virtualization initiative. Forewarned is forearmed.

A consistent observation we at Cassatt have been professing for some time is that virtualization is not an end-in-itself. It is an enabler of much higher-level data center management structures. So, when virtualization is implemented as if it is the goal, the outcome could easily be more cost and complexity, rather than the reverse. As illustrated by Amrit:

Virtualization reduces complexity (I know what server I am. I’m the server, playing a server, disguised as another server)

It seems counter-intuitive that virtualization would introduce management complexity, but the reality is that all the security and systems management requirements currently facing enterprises today do not disappear simply because an OS is a guest within a virtual environment, in fact they increase. Not only does one need to continue to maintain the integrity of the guest OS (configuration, patch, security, application and user management and provisioning), one also needs to maintain the integrity of the virtual layer as well. Problem is this is done through disparate tools managed by FTE’s (full time employees) with disparate skills sets. Organizations also move from a fairly static environment in the physical world, where it takes time to provision a system and deploy the OS and associated applications, to a very dynamic environment in the virtual world where managing guest systems - VMsprawl - becomes an exercise in whack-a-mole.

There are also a variety of other perspectives on this new tool called virtualization. Take for example the implicit assumption that *everything* will be virtualized. The answer is maybe, but perhaps not in our lifetime. Begging the question "how to I manage all the other stuff?" The de-facto answer has been that IT uses its existing systems for Physical, and VM management tools for the rest. Now you've bifurcated your datacenter management, and added to complexity once agai n. (Thanks to Amrit for the pic.)

My advice is - and has been - to treat virtualization as a *feature* of something larger. Don't implement it if you're treating it as a point-solution; Treat it as an enabler of your next systems management architecture. Rules-of-thumb have to be

• Assume heterogeneity of VMs & VM management; plan for it
  
• Assume you'll always have physical servers somewhere; manage them alongside your virtual servers
  
• Assume you'll have more virtual object to manage than you can keep track of; use an automation tool
• Never assume that once you've consolidated, things will be stable; plan for constant re-adjustment of scale and capacity (another argument for automation)
  

Have an end-game in sight if your'e introducing VMs in your environment. Take the long-view.