Data centers

10:24 AM
Joe Onisick
Joe Onisick
Commentary
50%
50%
Repost This

Forget Multiple Hypervisors

Multiple hypervisors in the data center may seem like a good idea: You get leverage during negotiations, and potentially avoid vendor lock-in. But dig deeper and the arguments begin to fall apart.

The concept of managing multiple hypervisors in the data center isn't new--companies have been doing so or thinking about doing so for some time. Changes in licensing schemes and other events bring this issue to the forefront as customers look to avoid new costs. VMware recently acquired DynamicOps, a cloud automation/orchestration company with support for multiple hypervisors, as well as for Amazon Web Services. A hypervisor vendor investing in multihypervisor support brings the topic back to the forefront.

The arguments for multiple hypervisors are typically cost-based. If price weren't a factor, very few data centers would run anything other than VMware. VMware is the 800-pound gorilla in the virtualization market, with a slew of robust features that are time-tested with production workloads. That being said, cost is an issue--and VMware is at the top end of that scale.

The other side of the cost argument for multiple hypervisors involves leverage and lock-in. The leverage argument is based on pitting hypervisor vendors against one another in a pricing war to maximize discounts. From a lock-in perspective, the thinking is that using multiple hypervisors helps companies avoid being locked in and, therefore, beholden to one vendor.

On the surface, these arguments are sound and a multihypervisor environment makes sense. The problem is the arguments exist in a vacuum, and when you expand your view to the big picture, they begin to fall apart. When each argument is separated from its isolated base, we see that a multihypervisor environment is rarely the better choice.

The cost argument is the most common, so we’ll start there. This argument is based on hypervisor licensing and support contract costs, and is therefore capex related. There's no arguing that capital can be saved by choosing less expensive hypervisors for the workloads that don’t require advanced management or reliability features. Opex is where the issue lies. At a minimum, utilizing two hypervisors requires two separate IT skill sets, deployment methods and management models. This is an ongoing expense that will quickly outweigh the capex savings. You'll need data relevant to your business to back this up: salary data for the responsible admins, training costs to ramp staff up on new systems, additional hire requirements, and so on.

While the cost argument makes sense from an isolated capex perspective, the leverage argument holds little weight on its own. Actually deploying a multihypervisor environment based on gaining vendor leverage isn't necessary. If required, vendors can be pitted against one another during the sales cycle without deploying more than one product--think playing poker. For the most part, hypervisor vendors are well aware that the competition has become stiff, and pricing plays a big role.

Like the leverage argument, deploying multiple hypervisors to avoid lock-in holds little to no weight. It’s true that using multiple hypervisors prevents you from being beholden to one vendor, but you still incur the additional operational costs of managing them both. Additionally, you’ll still suffer the same pain if you choose to ditch one of the vendors completely, although on a possibly smaller scale. The virtual machines and/or apps will have to be moved onto whichever hypervisor is staying around. You’d also need to bring in a new hypervisor to maintain a multihypervisor-to-avoid-lock-in environment. After all, if such an environment made sense before, why would it have changed?

The most common deployment for multiple hypervisors is VMware as the production system, with Microsoft Hyper-V or Citrix XenServer running test/development systems. VMware is chosen for the performance and features needed for production, while another hypervisor is chosen to lower cost in another environment. Applications are developed and tested on one system, then migrated to the production system. This is a dangerous idea. In the Marines we used a saying: "Train like we fight, fight like we train." This applies well outside of combat, too. A system thoroughly tested on one hypervisor has not been properly vetted for another. Testing should be done on identical systems, down to firmware revision.

Regardless of which hypervisor is chosen, most environments will incur the least cost and gain the most overall benefits from a single hypervisor deployment. Standardizing on a single hypervisor reduces complexity and configuration points and, therefore, opex. Ensure that you look at the big picture when making hypervisor decisions, as it’s easy to get wrapped up in myopic views that lead to poor decisions.

Disclaimer: In my primary role I work closely with several hypervisor vendors. This post is not intended as an endorsement for any of those vendors or products mentioned.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Metacloud2012
50%
50%
Metacloud2012,
User Rank: Apprentice
9/24/2012 | 7:57:01 PM
re: Forget Multiple Hypervisors
Agree but don't. Requirements and delivering business services win over IT's struggle with complexity. We have multiple vendors / OSs / form factors in other parts of IT, why not cloud. Choice wins. Embrace the diversity - make holistic decisions based on requirements and ROI. Why not a managed service provider based on OpenStack at a fraction of the cost and functional parity? IT gets much lower costs, reduced complexity, and the business is rewarded with cloud services.
More Blogs from Commentary
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Building an Information Security Policy Part 4: Addresses and Identifiers
Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.
Hot Topics
3
Converged Infrastructure: 3 Considerations
Bill Kleyman, National Director of Strategy & Innovation, MTM Technologies,  4/16/2014
2
Heartbleed's Network Effect
Kelly Jackson Higgins, Senior Editor, Dark Reading,  4/16/2014
White Papers
Register for Network Computing Newsletters
Cartoon
Current Issue
Video
Slideshows
Twitter Feed