Killing the OS Octopus

The inspiration for this blog post title comes from a Paul Maritz (CEO of VMware) quote, during his presentation to financial analysts last week. Paul used the phrase "severing the tentacles of complexity" multiple times when referring to the new level of business flexibility that is possible when applications are liberated from their physical host by encapsulating them inside of a virtual machine with “just enough operating system (or JeOS).” They can be provisioned much more quickly because there is no need to provision physical assets. They can be moved from datacenter to datacenter more quickly because there is no onerous installation and validation process required. Indeed, virtualization enables cloud computing because the applications are no longer defined by the physical computers upon which they run. But, until VMware truly embraces a JeOS approach with their operating system support matrix, they are simply recommending “isolating” the tentacles of complexity. And the result will be a perilous and expensive condition often referred to as VM sprawl.

So what is the difference between “isolating” the tentacles of complexity and “severing” them? Isolating the tentacles means shoving the previous definition of your application running on a physical server into a virtual machine box. When you put a virtual machine box around the octopus, it can no longer create mischief with other application octopi running on the same physical host. Its tentacles are “isolated,” and utilization on the physical host can be much higher. This approach is valuable, and it has catapulted VMware into the spotlight as one of the hottest technology companies on the planet.

However, the octopus is still alive and well inside the box, and system administrators must continue to feed that hungry animal in exactly the same way they did when it was living on a physical server host. The level of maintenance has not been reduced. The level of security vulnerability has not been reduced. Although isolated, it is still a resource hog because those crazy tentacles demand CPU, and memory, and disk to flail and flap as they do. This condition of ever expanding system administration grief associated with the frictionless deployment of virtualized applications whose tentacles of complexity have simply been isolated and not severed is known as VM sprawl. And it will be a nightmare of system administration expense for those that embrace it.

In order to avoid the nightmare of VM sprawl, the tentacles of the complexity octopus must actually be severed, not simply isolated. Application developers and system administrators alike must re-think the category of the operating system in the context of a virtualized datacenter. Since the operating system is no longer the conduit for managing the hardware, it should become a simple shared library for system services required by the application. Two great example of this approach are rPath and BEA's (now Oracle) liquid VM technology. With both of these platforms, the operating system is specified in a manner that explicitly supports the needs of the application – without any extra bloat associated with the typical general purpose OS approach. As a result, the OS in both of these cases is 10X or more smaller than the smallest installation option offered by a general purpose OS. In theory, this should lead to a 10X reduction in the scope and scale of administration activities. Severing the tentacles of complexity by re-thinking the OS eliminates the perils of VM sprawl.

But VMware does not currently support this approach. They only support the legacy vendors of general purpose OS technology. Sure, these new approaches have terrific performance and value, and VMware is happy to have them contribute to the value of their virtual appliance market, but their support statement pretty clearly favors “isolation” of complexity over true elimination of complexity. But the winds of change are steadily and surely blowing in favor of this new approach in the market. Red Hat, for example, just announced that they are going to market with a bare metal hypervisor that is directly competitive with the VMware approach in lieu of their historical product architecture - where virtualization was simply a feature of the general purpose operating system. And Paul Maritz was pretty clear in his presentation that “severing the tentacles of complexity” and a “just enough operating system” approach are important to VMware. Perhaps we are drifting toward the precipice of an all out war for the definition of the future datacenter operating system. I said it back in 2006, and I'll say it again today -- let's fry up that OS octopus polvo frito and serve it with some spicy mango chutney and cold beer.

Is JeOS a Tonic for VM Sprawl?

It seems that everyone is worried about VM sprawl these days. When system capacity is easy to consume because the application is prepackaged as a virtual machine (a virtual appliance in the case of an ISV), the virtual infrastructure capacity is quickly gobbled up by those that have been waiting for IT to get around to provisioning systems for them. No more friction due to virtualization means no more waiting and wanting. It also leads to VM sprawl. But why is VM sprawl bad?

VM sprawl is bad because the scale of the management problem used to be throttled by the capital spending associated with the size of the infrastructure. Now, the scale of the management problem is equal to the true demand for application capacity as represented by the number of application images, or virtual machines, that get deployed. This scale factor associated with application images throws the old yardstick of X system admins per Y server machines out the window. What are we going to do to lower the work profile associated with so many new systems that now need to be managed?

I think at least part of the tonic for VM sprawl is the new acronym coined by Srinivas Krishnamurthi of VMware – JeOS. JeOS stands for Just enough OS and it is pronounced “juice.” In my mind, this liquid pronunciation is appropos given my view of its potential potency as a tonic for VM sprawl. A huge part of the burden of system management is the patching and associated regression testing for maintaining the security and functionality of the general purpose OS. If you can shrink the size of the OS by 90% (which is where we have measured the typical size for most applications built with our rBuilder technology) by eliminating any elements not required by the application, you can eliminate about 90% of the patching burden. More importantly, you eliminate the bigger burden of regression and stability testing that is coupled to the patching process.

With a JeOS approach, the number of virtual machines can theoretically grow by 10X the legacy approach without any impact to the cost structure associated with patching and testing the OS changes. I suspect a 10X reduction represents a real win for most shops as the OS patching and testing associated with security and infrastructure performance is a very sizable portion of their management spending. So if you are feeling the pangs associated with VM sprawl, I strongly suggest a healthy slug of JeOS each morning and once again in the afternoon to clear your system of the painful bloating that is brought on by virtualizing the general purpose OS.