IT Management Goes Vertical

About 6 months ago, I had the privilege of engaging with the CTO of a large Wall Street investment bank on the topic of virtual machine management. One of his staff who was also participating in the conversation informed me that they had done a broad survey of their management technology providers regarding a new approach for system management -- vertical instead of horizontal. He said they polled the vendors with the following question:

Q: When does the unit of management shift from the physical host (horizontal) to the virtual machine (vertical)?

A: About 3 - 5 years

He said that all of the vendors agreed that this shift was inevitable, and the time frame for it to be in full swing was "about 3 - 5 years." He said they followed on with a second question after they received the response above:

Q: When do you plan to begin providing us with technology to manage vertically via virtual machines instead of horizontally via the physical hosts?

A: We'll worry about that in 3 - 5 years.

Amazing. The problem with this response, aside from the obvious, is that "about 3 - 5 years" is quickly becoming here and now. The term "vm sprawl" is on the tip of every analyst tongue, and the IT blogosphere is beginning to buzz with the imperative for managing the deployment of applications as coordinated collections of virtual machines (or virtual appliances in the case of applications delivered by a third party provider).

Lori MacVittie from f5 DevCentral writes:

When applications are decoupled from the servers on which they are deployed and the network infrastructure that supports and delivers them, they cannot be effectively managed unless they are recognized as individual components themselves.

Traditional infrastructure and its associated management intrinsically ties applications to servers and servers to IP addresses and IP addresses to switches and routers. This is a tightly coupled model that leaves very little room to address the dynamic nature of a virtual infrastructure such as those most often seen in cloud computing models . . . .

That model is broken in a virtual, dynamic infrastructure because applications are no longer bound to servers or IP addresses. They can be anywhere at any time, and infrastructure and management systems that insist on binding the two together are simply going to impede progress and make managing that virtual infrastructure even more painful.

The impending challenge is that the horizontal approach will become prohibitively expensive when the number of instances to be managed "horizontally" increases by an order of magnitude due to the liquidity of system capacity provided by server virtualization. Because it is so "easy" to provision a VM, lots of them will be provisioned for lots of very valid reasons. Managing 100 hosts becomes managing 1000 virtual machines. When this happens to you, be prepared to go "vertical."

Going vertical means defining and managing the contents of the virtual machines based upon the needs of the application. When a "host" is defined as the minimal software that is required to support the system functions of the application within the VM, 90% of the operating system software falls away because it becomes irrelevant. This smaller, Just Enough OS (JeOS or "juice") approach which considers only the needs of the application is more scalable because 90% of the management burden disappears. If the number of VMs increases by an order of magnitude, at least the footprint has shrunk by a corresponding order of magnitude.

Going vertical also means extending the discipline of Application Lifecycle Management (ALM) into the realm of the virtual machine. Since all of the system software that supports an application is now based upon the needs of the application rather than the needs of the infrastructure (which is, after all, the point of virtualization), it is now possible to put the entire software content of the VM under strong version and release management. This version management discipline, which is classically associated with ALM, enables change management on a much larger scale than the ad hoc approach of the legacy horizontal model.

Historically, the boundary between applications and IT operations was fuzzy because it was impossible to discern the portion of the operating system that was responsible for supporting the application from the portion that was responsible for supporting the infrastructure. They were intrinsically coupled due to the duality of the operating system role - hardware support and application support. With virtualization, the fuzziness becomes a bright, clear line. The hypervisor supports the allocation of hardware resources, and the host inside the VM supports the application.

With this new bright line separating application development from IT operations, all of the change management advantages associated with years of prior art in the ALM space become available as a scalable mechanism for managing production releases of the application as a set of VMs. The expensive testing burden for promoting an application from development to production is dramatically reduced when every software component of every VM falls under a unified change management system. The unintended consequences of change are largely eliminated because version management provides visibility and pinpoint accuracy regarding the deployment of changes across the universe of VMs - those in production as well as those in the library repository.

When coupled with JeOS, strong version management provides the scalability for IT management to go vertical. If you stay horizontal in the face of the impending VM tsunami, you might drown in the technical equivalent of the 1000 year flood.