Cloud in Plain English

I must take my hat off to Jake Sorofman, who runs marketing for rPath. Jake has done an incredible job distilling a bunch of complex stuff into a consumable and entertaining video. Do yourself a favor, and check out his Cloud Computing in Plain English video. Al Gore never looked so good.

And Happy Holidays!

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.

Will Managing VM Sprawl lead to Rogue Cloud Deployments?

I just read an interesting article regarding the potential cost pitfalls associated with VM sprawl. Jett Thompson, an enterprise computing architect from Boeing, has developed a cost model regarding the benefits of virtualization and the related pitfalls of VM sprawl. It seems that virtualization is easy to justify, so long as you don't give the users everything that they want. Here is the money quote from the article:

However, all of those savings [from virtualization] can be eliminated if sprawl isn't controlled. With virtual servers easy to spin up, users may ask for large numbers of new virtual machines and it's up to IT to hold the line, Thompson says.

"If you don't have demand management and good governance in place you're actually going to cost your company money," he says. "Virtual server sprawl can wipe out any savings."

Gartner analyst Thomas Bittman also says virtual server sprawl can be tough to control and is harder to measure than physical server sprawl. "Fundamentally, we believe virtualization sprawl can be a much bigger problem than physical sprawl," Bittman said

I believe that the unintended consequences of "IT hold[ing] the line" will be rogue cloud deployments. Rogue cloud deployments describes the phenomenon of business unit developers taking matters into their own hands when IT "holds the line" on making computing resources available. Once the business units understand that resources can be made available on-demand, either internally or via services such as Amazon EC2, they are simply not going to take "no" for an answer. Deploying applications as virtual machines, or virtual appliances in the case of an ISV application, removes all of the friction from the deployment process. This same friction was formerly the tonic that IT sprinkled about in order to "hold the line" on availability (and the subsequent management costs) of computing resources. The instant gratification culture that we are cultivating with SaaS and cloud will not be held in check if IT "holds the line" by saying "no" to requests for capacity/capability.

I have a recommendation for Jett and the folks at Boeing and elsewhere who are fearing the unintended consequences of frictionless system capacity brought about by virtualization. Push the control point for deployment policy upstream via automated build, release, and management processes for applications released as virtual machines, manage the scale problem by going vertical with a JeOS architecture, and build a seamless bridge managed by IT to cloud offerings like Amazon EC2. Charge the users with the costs for deployment and management, but give them the technology to do it the right way. Check out our cloud computing adoption model and the webinar that accompanies it. Rogue cloud deployments can be avoided, even in the face of VM sprawl control measures, when you say "yes" to your users while holding them accountable for building manageable system images.

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.