Guest View: Lowdown on virtualization hype
By Don MacVittie
October 1, 2008 —
(Page 1 of 3)
Related Search Term(s): databases, desktop management, server management, virtualization
Picture a circle of children holding hands on a grassy hill. One wavering voice starts to sing, and soon the entire circle joins in, filling the air with the strains of “Kumbaya.”
That’s the feeling you get when someone says “virtualization” in a crowd of IT folks. Vacuous smiles break out as the conversation turns from serious talk about business requirements to platitudes about virtualization’s benefits. Rarely does anyone mention the issues virtualization creates or the processes required to keep things straight in a highly virtualized environment.
Virtualization is a great tool, but the industry buzz makes it sound as if virtualization is the entire toolbox. Frankly, if all you have is a hammer, everything looks like a nail—and these days all the nails seem to sport “Virtualize me” signs. Many of them should not be virtualized. But that doesn’t matter any more than it mattered in the heady days of XML that not every bit of data is best expressed as text.
Is virtualization good for eliminating hardware dependencies? Yes, in many cases. Running a VM of an operating system that you don’t otherwise support is a handy way to make old software run on new hardware. Is it a good way to merge all of those not-too-busy servers you installed in the days when Larry Ellison was admonishing you not to fall for the “lots of little boxes” solutions? Yes. Having 20 machines sitting around at 10% utilization is wasteful at best.
Is virtualization the right tool for every job? Was the wheel?
There are so many problems that virtualization cannot solve (or should not be used to solve) that we need to let the hype cycle run its course and get on with the business of IT.
If your solution needs to be load balanced, for example, virtualization is the worst solution at hand, unless you’ve got a process in place to guarantee that no two load-balanced instances will end up on the same box (since having two load-balanced instances on the same virtual server just creates more overhead, in the form of context switches and resource allocation/contention). Even then, if your application is so busy that it requires load balancing, why are you putting it onto virtualized servers with other applications?