As many of you already know, VMware launched its new core suite last Tuesday, comprising the new vSphere 5, Site Recovery Manager 5, vCloud Director 1.5 and vShield 5.
By now everybody already knows about the new licensing and I promised myself that I would not spend time on it, given that almost every blogger in the world already beat the argument to the ground with examples and 'what-if' scenarios, but after a long chat with a guy 'in-the-knows' 🙂 I decided to write something on it before start talking about the product itself and the new ground breaking features that they bring to the market (especially in the storage side of things).
VMware started using per-VM licensing a couple of years ago with many products of their portfolio, most notably SRM, and it worked fine for almost everybody, giving great flexibility with a true ITaaS cost model.
At first, almost everyone was expecting a shift into per-VM licensing with the new version of vSphere, and even when the new VSPP licensing came out, several weeks ago, based on vRam entitlements, nobody really paid attention to the new licensing scheme, after all, it was very SP-oriented.
And then the bomb dropped and almost every person involved in the virtualization practice started to freak out on the new licensing: customers, consultants, even VMware employees.
With this post I'd like to give a very humble advice to VMware: please reconsider per-VM licensing.
Per-VM licenses are, in my opinion, the best fit for a true ITaaS environment (even better than having vRAM+CPU socket) and they're easy on those who won't (or simply can't) embrace the whole Private/Public Cloud paradigm.
You can still keep different versions based on different feature sets and keep a VM size limit to fence the "create a huge machine and stuff everything in it" problem. For the upgrades you can use your statistical data to understand how many VM per Socket are averagely used at your customers sites and create an upgrade path.
I understand that I'm being simplistic, but the uproar that the new licensing scheme has caused needs to be tamed, and on the other hand, VMware needs to protect its revenue stream in the future, narrowed by ever-increasing hardware capabilities, this, in my opinion, is what people expected and in these new 'cloudy' days we can't rely on licensing based on hardware, but you still need a licensing scheme that can still stand on its own feet for the years to come, just try to imagine a 48GB/socket entitlement two years from now…
“just try to imagine a 48GB/socket entitlement two years from now”
Two years? How about year ago? You can stuff 1TB (1024GB) in a 4U IBM X5 with 4 sockets – 1.5TB with an expansion unit. 192GB looks quite ridiculous in comparison. per-VM licensing would certainly simplify the cost calculations, even if there were some other limits imposed (say 8vCPU/64GB vRAM per VM). Taking out (even partly) the resources for the VM in the calculation would also definitely lower the bar for entering virtualization. The new licensing raises it just as it was getting lower and lower with each release.
I know, it’s tricky stuff, but at least our calculations show without doubt that full utilization would roughly double the licensing costs, even though we no longer have to pay for the failover capacity.
I’m pretty sure that IBM (but for that matter, everyone else with a memory expander tech) is mad at VMware for this new licensing scheme because they’re effectively destroying their unique market value proposition.
I’m glad to see other people like per-VM licensing proposal, if VMware really pays attention to the customers and community feedback I’m sure that they will tweak the new licensing scheme.
Fabio, I am not talking for VMware here. This is my personal perspective.
I can assure you that VMware is listening. No question. Whether this is a real problem affecting a large user base, if it’s normal turbulence introduced by a change or if it’s just hitting a very small (yet vocal) install base … that I don’t know and I can’t say but if this turns out to be the former I am sure there is a willing to make it work. I trust we made this move to cope with what’s going on in the industry and to adapt for the future rather than for overtaxing existing customers (see second paragraph).Â
It would be nice if you could articulate more with the per-VM pricing you have in mind. To me the current pricing is a kind of per-VM pricing where, instead of being charged for single VMs you are effectively buying for a “bundle” of vRAM that you can then use when deploying VMs. After all you would need to be charged proportionally to your actual VM deployment (a 1vCPU/2GB VM would be charged differently compared to a 4vCPU/256GB of memory). I also think it’s a moot point that of people saying that to instantiate a “monster VM” you would need to pay 73.000$ (?) with this licensing schema. Would it be different if we were to charge 73.000$ for that single VM in a per-VM pricing?Â
I am just trying to understand if it’s the model the problem (vs a per-VM model) … or if it’s the price itself the problem. I can’t (and don’t want to) say anything for the latter (not my area) but as far as the former..I don’t see this HUGE difference… other than that the “pooling” model is more flexible in some scenarios.
I can see that the hybrid CPU/Memory model could be confusing but … would it change drastically if we were only selling vRAM as opposed to “CPU with a cap on vRAM”. Again, not my field, but it’s not like if we were to sell vRAM expansions we would sell them cheaper (IF we all agree that right now memory is the hot topic).Â
My own thoughts written in my spare time.Â
Massimo.
“just try to imagine a 48GB/socket entitlement two years from now”
Two years? How about year ago? You can stuff 1TB (1024GB) in a 4U IBM X5 with 4 sockets – 1.5TB with an expansion unit. 192GB looks quite ridiculous in comparison. per-VM licensing would certainly simplify the cost calculations, even if there were some other limits imposed (say 8vCPU/64GB vRAM per VM). Taking out (even partly) the resources for the VM in the calculation would also definitely lower the bar for entering virtualization. The new licensing raises it just as it was getting lower and lower with each release.
I know, it’s tricky stuff, but at least our calculations show without doubt that full utilization would roughly double the licensing costs, even though we no longer have to pay for the failover capacity.
I’m pretty sure that IBM (but for that matter, everyone else with a memory expander tech) is mad at VMware for this new licensing scheme because they’re effectively destroying their unique market value proposition.
I’m glad to see other people like per-VM licensing proposal, if VMware really pays attention to the customers and community feedback I’m sure that they will tweak the new licensing scheme.
Fabio, I am not talking for VMware here. This is my personal perspective.
I can assure you that VMware is listening. No question. Whether this is a real problem affecting a large user base, if it’s normal turbulence introduced by a change or if it’s just hitting a very small (yet vocal) install base … that I don’t know and I can’t say but if this turns out to be the former I am sure there is a willing to make it work. I trust we made this move to cope with what’s going on in the industry and to adapt for the future rather than for overtaxing existing customers (see second paragraph).Â
It would be nice if you could articulate more with the per-VM pricing you have in mind. To me the current pricing is a kind of per-VM pricing where, instead of being charged for single VMs you are effectively buying for a “bundle” of vRAM that you can then use when deploying VMs. After all you would need to be charged proportionally to your actual VM deployment (a 1vCPU/2GB VM would be charged differently compared to a 4vCPU/256GB of memory). I also think it’s a moot point that of people saying that to instantiate a “monster VM” you would need to pay 73.000$ (?) with this licensing schema. Would it be different if we were to charge 73.000$ for that single VM in a per-VM pricing?Â
I am just trying to understand if it’s the model the problem (vs a per-VM model) … or if it’s the price itself the problem. I can’t (and don’t want to) say anything for the latter (not my area) but as far as the former..I don’t see this HUGE difference… other than that the “pooling” model is more flexible in some scenarios.
I can see that the hybrid CPU/Memory model could be confusing but … would it change drastically if we were only selling vRAM as opposed to “CPU with a cap on vRAM”. Again, not my field, but it’s not like if we were to sell vRAM expansions we would sell them cheaper (IF we all agree that right now memory is the hot topic).Â
My own thoughts written in my spare time.Â
Massimo.