Managing a virtual machine is not the same thing as managing the stuff inside it.

I’ve been noticing a disturbing, though not unexpected, trend in the world of virtualization and cloud computing around management of infrastructure, particularly around virtual network appliances (VNAs). Specifically this trend is claiming the ability to manage virtualized infrastructure.

You’d think I’d be happy about that. I probably would - if the solutions were actually capable of managing the infrastructure.

Digging into these management solutions shows that for the most part the definition of the term “manage” is about as deep as a puddle; the buck (and control) stops at the virtual machine. What management and automation solutions promise is the ability to provision, manage, and migrate virtualized infrastructure. What they actually provide is provisioning, management, and migration of virtual machines. Whether it is infrastructure or applications running internal to the virtual machine is pretty much irrelevant; the solution is about managing virtual machines.

The ability to launch, start, stop, and decommission a virtual network appliance is not an insignificant task. These pieces of the management puzzle must be accomplished somehow in order to control the operational costs associated with the more dynamic and ultimately volatile virtual infrastructure. But managing solely at the virtual machine layer – and claiming “infrastructure management” borders on deceit. It’s glossing over reality and interpreting “management” and “infrastructure” as loosely as possible in order to imply capabilities that don’t actually exist. Actually managing virtual infrastructure requires the ability to communicate and manage the actual infrastructure solution, not just its virtual container. This is an important distinction and one that needs to made early in the evolutionary process of virtual data center management lest the inability of management solutions push organizations toward what would result in a rigid, inflexible infrastructure that requires more operational support than its physical predecessor.

Without the ability to manage the infrastructure solution, operations is left to their own devices (sorry for that one, really) to find a way to manage the virtual infrastructure. Even if the management system is capable of invoking scripts to automate the configuration and/or modification of VNAs when they are launched, the scripts are still separate entities, managed distinct from the management system, and prone to the same invocation and processing errors as they are today. What we end up doing is turning network administrators into integration specialists; responsible for overseeing the creation and management of lots of little scripts and ultimately running into the same issues with which enterprise application integration (EAI) specialists have always struggled.

These management systems may be great at determining when a VM is near or at capacity in terms of RAM and CPU utilization and thus are capable of kicking off auto-scaling processes, but scaling VNAs is not the same as scaling applications. While the latter can often be considered little more than a cloning exercise, and thus virtual machine level management will suffice, the former requires modification of not only its own configuration but quite possibly a variety of other infrastructure devices as well. When you start making changes to the network, there is often a cascading effect in which upstream and even downstream devices are impacted.

Managing virtualized infrastructure at the virtual machine layer also lacks the on-demand adaption from which so many operational benefits are realized. The integration between a Load balancer and virtual machine management systems such as VMware vSphere and Microsoft System Center allows the management system to utilize network and application network layer data when making its decisions. Auto-scaling applications isn’t just about RAM and CPU, after all. Network throughput (bandwidth) can be an important factor in the decision making process as can the rate at which new requests are being received. It is impossible for a single application instance – especially in a distributed, virtualized environment – to have visibility into the “big picture”. The load balancer, however, does have that information and can provide it – if it’s been integrated and can share the data with the management system.

Conversely, when an application instance is launched as a means to address capacity, it must be added to the load balancing solution. A management system capable of automatically launching the instance is fine, but unless it’s actually managing the load balancer itself then manual intervention will be required to add the application instance to the load balancer and ultimately increase the application’s capacity.

If a management solution is not managing the infrastructure solution, but instead is only managing the virtual machine, this integration does not happen, this automation is lost, and auto-scaling isn’t.

Management solutions touting the ability to provision and manage “virtual infrastructure” should be closely examined to understand what they’re really managing. The management of most network and application network infrastructure can be accomplished via standards-based control planes – APIs – and thus the form they take, i.e. virtual or physical, is irrelevant. A management solution should be able to provision, manage, and control Infrastructure 2.0 capable solutions regardless of form factor. If a solution is specifically using “virtualized infrastructure” in its list of capabilities, that should be a warning sign that the solution may be as deep as a puddle when it comes to actually managing infrastructure.

The ability to deploy and manage a completely virtualized architecture is indeed appealing, but it’s important to remember that managing virtual machines is not the same thing as managing the infrastructure. Managing infrastructure requires deeper integration than just interacting with the virtual machine control-plane; it’s got to get under the hood and integrate with the actual infrastructure solution.

While standards will certainly make this task easier and may, in fact, end up resembling the “adapter-style integration” of enterprise application systems, it is not impossible to achieve today via similar abstraction techniques. The integration and management of the infrastructure – not its container – is necessary if data centers are going to successfully move toward a more virtual and dynamic infrastructure.