In-Depth
The ISV Support Tug-Of-War
Customers need to demand that they support multiple hypervisors.
Who holds the power in a technological relationship? Is it the Operating System (OS) vendor, infrastructure vendors, Independent Software Vendors (ISVs), or the customer? Each will tell you they're in charge, and give you a good reason why this should be so. Reality is a little more complex, and it tends to boil down to a battle of individual will.
There is a very real debate over who bears the burden of support. Only the very best vendors are willing to own support for aspects of a solution they themselves don't directly control, and many vendors actively refuse to work with other vendors in the stack. This often leaves the customer stranded.
Power Plays
Virtualization projects have long been the victim of these petty power games. Many virtualization administrators will have had the experience of an ISV refusing to support an application if it runs in a virtualized environment. Some go so far as to only allow their application to run on a proscribed set of bare metal hardware configurations: if it works in the ISV's development lab, then that's what customers will use.
Of course, this very narrow approach to support often leaves customers unable to take advantage of advances in technology. Redundancy, resiliency and high availability are easy to achieve with today's virtualization technologies, and both difficult and expensive when restricted to the equivalent of a bare metal copy of some lead developer's laptop.
Over time, OS vendors agreed to support their OS when used as a guest inside a VM. Many, perhaps even most, ISVs relented and agreed to offer limited support for operating inside a guest. While this is a victory for the customer, the battle is far from won.
In case it's escaped notice, VMware is no longer the only vendor offering a viable enterprise hypervisor. VDI has largely been done through Citrix on Xen for some time, and there are quietly a rather large number of CloudStack installations out there running on Xen that never seem to get the media attention they deserve.
Hyper-V has been viable for some time now, and is expected to explode in usage thanks to Azure Stack. Azure Stack is feature-packed and easy to use, offering a "cloud in a can" solution currently unmatched by any other vendor.
Similarly, KVM has been gaining ground. KVM is at the core of Red Hat (and consequently Oracle's) virtualization offerings. It's also being used by numerous hyper-converged players from the highly successful Nutanix and Scale Computing to up-and-comers like Yottabyte and ZeroStack. And this is before we even start talking about hybrid cloud solutions!
Despite this growing demand for heterogeneity in the datacenter, many ISVs are stubbornly sticking with their dated power games. These hypervisor bigots are roadblocks standing in the way of critical projects and preventing progress. It is only together that we stand a chance against them.
Over a BarrelISVs know that they have us all over a barrel. If they don't support something, it won't pass audit and then we can't be certified for whatever certifications we need to hold.
Together, however, we can make our discontent known. When ISVs say they won't support a non-VMware hypervisor, push back! Ask them exactly what those support agreements pay for, and demand deep discounts if they are going to hold up datacenter diversification and advancement.
The ISV support tug-of-war was a dumb game back when the topic was an outright refusal to support virtualization at all. It's an equally dumb game when the refusal is to support alternate hypervisors, containers or public clouds. Let's not wait another 15 years to be able to take advantage of all that today's IT has to offer.
About the Author
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.