* IT organizations may have their doubts about virtualization
Consolidation, standardization, virtualization and utility are the four stages of development data centers pass through as IT organizations move towards a truly services-based model. Virtualization is the first step in the process that goes beyond straightforward optimizations and requires a small leap of faith.
Many data center managers see that they already have applications that perform poorly even when running alone on dedicated servers, sometimes obviously bound by poor coding rather than machine resources – performing poorly but still only using a fraction of the current machine’s capabilities.
When contemplating moving that application onto a virtualized server, they have to ask: Will it slow things down, make the performance even worse? Make already disgruntled users even less “gruntled”?
The unfortunate answer is “yes.” Virtualizing the infrastructure under that application will slow it down. Depending on the particulars, users can expect to see anywhere from 3% to as much as 15% slowdown in their applications on the change from dedicated to virtualized servers, all things being equal.
In many cases, of course, all things are not equal. Organizations move to production use of virtualization on new servers (often blades) deployed for the purpose, so any loss in performance due to the inevitable overhead of virtualization is more than compensated for by the improvement found in a newer server.
But if new servers are not a part of the mix (and they are not, in some cases, as when virtualization projects begin by consolidating pools of test/development/QA servers, and everything proceeds from there on the pool of freed-up machines) there are two points to comfort organizations making this change, one for the short term, one for the long term.
In the short term, the improved management possible in the virtualized scenario will make it easier to avoid significant downtime on the application, in essence trading slight slowing for better maintainability and availability. In the somewhat longer term, the organization must consider Moore’s Law as it applies to them, and how quickly they will gain performance back as they do bring new hardware into the resource pool.
Add to this the fact that migrating the application environment to new hardware will be vastly easier (as is rolling back, should the need arise) and you have a compelling case for accepting a short-term decrease in responsiveness in the interest of a long-term improvement overall.
And of course, it is always good to keep in mind that if the application is a dog, running it on a virtual as opposed to a real server won’t make it less of one – there is no magic code-improving genie being uncorked here – but the unused server resources that dog is holding hostage will at least be freed for other uses.
Likewise, it is important to resist the temptation to combine an application upgrade and the virtualization of that application’s server; our research shows that mixing upgrades or migrations with virtualization is a frequent cause of disastrous problems.
