The service and support shell game

If a vendor has a de facto monopoly, it can force you into buying bundles you don't need. Case in point: VMware

Whenever a vendor dominates a product category, you lose, with non-competitive pricing and limited options. There are many examples, starting with Cisco's obscene profit margins, carrying through to Oracle, EMC, and others. Services vendors like Siemens pull the same stunt -- once you're with them, you're stuck with them for everything, and God help you if you try to color outside the lines.

Take VMware. I've noted more than once that it would be nice to see real competition in the enterprise hypervisor space, if for no other reason than to drive down the prices of VMware's industry-leading products. Let's face it -- VMware is the best virtualization platform available today, bar none, but it's also extremely expensive. When you rule the roost, you can pull off that kind of thing.

[ InfoWorld's Paul Venezia takes another look at VMware and virtualization in his Deep End blog post "Virtually there: The state of datacenter virtualization" ]

But what irks me more than the high cost is VMware's assumption that we're all idiots incapable of implementing and maintaining a VMware-based infrastructure without WMware's support. You see, you cannot buy VMware vSphere licenses without also buying some level of support. Gold or Platinum is all that's offered; the former is a 12/5 phone support plan, the latter a 24/7 plan. But hey, I know what I'm doing. I don't need a plan. Can't I just buy the licenses?

The answer is no, you can't. In fact, if you want to upgrade a lapsed licensing agreement, you must pay for all the time your subscription has expired, in addition to another year of support. If you've managed just fine with ESX 3.5, have no need for support, and let your subscription lapse two years ago, you need to buy back all that time to get current and upgrade. Oh, and there's a 20 percent reinstatement fee on top of that.

Another quite common scenario is a VMware customer that has let their subscription lapse and doesn't need to upgrade to vSphere. All they need are a few more CPU licenses for their existing ESX 3.5 farm. They cannot buy them without buying the support contract and, in fact, will be able to upgrade those hosts to vSphere, but not the other hosts in the farm -- how exactly is that handled by the license server anyway?

I understand that most of the issue here is that VMware doesn't want its customers to re-up their licenses just to get a new version -- they want them to maintain a constant subscription. The problem is that folks are getting annoyed with that idea.

VMware and virtualization in general is in a far different place now than it was even three years ago. Hypervisors are well on their way to becoming commodities, and virtualized infrastructures will soon outnumber traditional infrastructures. The key concept in virtualization isn't be so much the hypervisor itself, but the management, performance, and upper-echelon features of the entire infrastructure.

VMware needs to attract and keep customers now, because there will be a time when the rest of the world catches up, and their competition can actually match their flagship product feature-for-feature. A good way to go about doing that might be to lower the barrier to entry. I'm certainly not a financial expert, but I might assume that adjusting your prices and offering more ways to buy your product isn't a bad idea, especially when your competition is giving away their admittedly not-as-good products for essentially free.

But what if they offered a subscription without support for a significant price reduction? I could buy the licenses and maintain a software subscription without having any level of support since I don't need it. If I did need it, they could charge a per-incident fee. Everybody wins.

At the end of the day, I just want to pay for what I use and not be required to spend extra on services that I don't want or need. Is that too much to ask?

Join the discussion
Be the first to comment on this article. Our Commenting Policies