Here’s a quick challenge, name one vendor that didn’t make a change to product licensing without upsetting someone.
In the desktop virtualization world Citrix incurred the wrath of it’s XenDesktop customers when it introduced named user licensing with the introduction of Xendesktop 4 back in October 2009. Microsoft does it every time it goes near anything to do with desktop virtualization. And yesterday given all the noise in the Twitterverse you could be forgiven for thinking that with the launch of vSphere 5 it was VMware’s turn to drink for the cup of licensing ineptitude.
#VMware vSphere Simplifies IT for Small and Midsized Businesses > As simple as “You can’t afford it any more”
Well, as much fun as it is to express outrage at any vendor with the temerity to change its licensing mechanism, VMware’s new system isn’t as bad as many have made out. Now that the true impact of changes are beginning to be understood saner heads are starting to prevail.
Bob Plankers and Carter Shanklin have written excellent posts on the impact and nature of the licensing changes and Josh Atwell has offered a solid explanation of why the changes were made. I’d urge you to read them all before going any further. Yes it’s going to hurt some customers, but if you are one of those that it does hurt, you don’t HAVE to stick with VMware, although you might still choose to and don’t forget that license costs are negotiable.
The “trouble” stems from VMware’s decision to change licensing from a processor-centric to a committed memory-centric (vRAM) model. VMware really had little choice but to make this change to memory-based licensing. As virtualization extends across a broader range of processor platforms it would otherwise have become increasingly difficult for VMware to maintain licensing parity between processor architectures, especially when it comes to dealing with emergent enterprise processor architectures such as those coming from ARM Holdings. charging by the core not a viable strategy when the capabilities of each core can very so much, and when the number of processor cores are likely to increase far more rapidly than memory utilization for any given workload. While this change makes a lot of sense for customers who are ready to fully embrace the idea of treating its virtual infrastructure as a private cloud service, and should be acceptable to the large majority of remaining customers once they have come to terms with the costs and benefits of vSphere 5, some will loose out badly.
The only real flaw in VMware’s licensing strategy is that it lacked the courage to fully embrace a memory centric licensing model. By imposing limits on both cores and memory it has created problems for itself and its customers: firstly it creates artificial inequalities between its customers, those who fall within the boundaries of the combined processor/memory envelopes for any given addition will be happy, those with workloads that do not fit the model will suffer, and splitting customers into separate camps this way is never a good strategy. Secondly it cannot sustain this model indefinitely, and will once again risk its customers anger as it revisits licensing a year or two from now to complete the transition to an all memory-based licensing model.
VMware knew that it was going to take some heat for the changes. It had briefed analysts as well as some select customers before announcing the changes, but even so it could have done better. Some questions remain unanswered. Small details like how Disaster Recovery environments will be factored into the new licensing rules are not yet clear. Will customers be required to license DR environments separately so that they can be tested, or will VMware allow a grace period of regular testing as well as for any post-disaster recovery period. VMware has not yet offered a definitive answer to that question, or rather if it has it has not been well communicated yet, and it should be clear to VMware that there is only one really acceptable answer to this uncertainty; it must not charge customers test their DR plans, nor should it attempt to charge them for over-committing on licensing during a post-disaster recovery.
A bigger question mark hanging over vSphere 5’s licensing policies is seen in VDI environments. A quirk in the way ythat vSphere is licensed for View means that VMware View customers shops are not going to be impacted by the new licensing rules. vSphere 5 will be free of charge for View deployments. However, vSphere shops who have built VDI solutions using Citrix XenDesktop or any other VDI platform are going to have to make some hard choices. With vSphere’s vRAM-centric licensing model and VDI’s high RAM requirements, the cost implications of running any other VDI platform on top of vSphere will be significant.
Suggestions have been made that VMware offer a VDI only version of vSphere to better support the needs of customers impacted by this change, but there is little real possibility of VMware responding favorably to this call. VMware main gain a few more vSphere licenses by supporting customers this way, but anything that reduces the cost of its competitors VDI solutions would not be viewed favorably within VMware. Leaving customers with the hard choice of either changing platforms (VDI or virtual infrastructure) or facing a significant price hike with the move to vSphere 5.
I’m running a live poll to assess the impact of this change, you can vote or just see the results below. So far the response favors a shift away from vSphere towards XenServer, but I would expect inertia to result in few migrations that the poll’s initial results suggest.