E-Commerce

VMware's new model: Is consumption-based pricing the way of the future?

With a major product announcement last week from VMware, many IT environments are required to fundamentally change their approach to licensing and provisioning. IT pro Rick Vanover shares the details.

Last week was a great week for virtualization products with VMware vSphere 5 being announced. This is clearly a push to cloud-modeled technologies delivered to each and every data center. While there were scores of updates to VMware products along with one new product, all of the news was entirely overshadowed by the new pricing mechanism.

With vSphere 5, VMware has introduced a new pricing model for virtualized servers explained in a new PDF. The new pricing model introduces vRAM. vRAM is a memory allocation that is provided with a socket (processor) license. This is different than the previous exclusive per-socket (CPU) only licensing that exists with VMware vSphere 4.

vRAM is entitled to a pooled environment by combining a number of CPU licenses. Specifically, vSphere is commonly deployed in clusters of many hosts. Those hosts each would be licensed with CPUs that each has a vRAM entitlement that is pooled together for a licensing pool of allocated vRAM. The individual CPU licenses are still purchased, and each CPU adds a vRAM quantity to the pool. The vRAM pool is then consumed from active virtual machines within the environment.

vRAM is provided at either 24, 32 or 48 GB per socket; depending on socket licensing level. So, if 10 sockets are purchased at the Enterprise level, there would be 10 x 32 GB of vRAM made available to the environment; which would permit a total of 320 GB of RAM allocated to active virtual machines. If more vRAM is needed (though it is not enforced within vCenter); additional vRAM allocations can be added by either adding more CPU licenses at the same Enterprise level; or upgrading one or more sockets to Enterprise Plus.

The reactions have been frequent and generally negative. I was expecting per-VM pricing for vSphere with this release; which is what we have seen with other products like VMware’s Site Recovery Manager. Many environments will be okay; meaning their current level of licensing will translate fine to the vRAM allocation. Highly consolidated environments will have to license a single socket at two socket licenses per physical socket to adhere to the vRAM allocation.

In the end, this is a big change. Does consumption-based pricing make sense? Is it inevitable? What do you think of this bold move on pricing? Please share your comments below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

9 comments
b4real
b4real

They've changed the vRAM policy.

pgit
pgit

There's always the 30 or 60 day trial... why make a convoluted license bound to pi$$ people off for a questionable marketing advantage?

reggaethecat
reggaethecat

Do the producers of software have a wager to see who can come up with the most complicated and annoying licensing model? Microsoft have been winning this contest for several years but I think VMware may well have just gained the lead. Why licence on both socket AND memory? What was wrong with per socket? What is wrong with per server?

pgit
pgit

This seems unnecessarily convoluted. What difference does it make to them where they derive pricing? Is someone using more of their own RAM causing VMWare harm somehow, that warrants extracting a higher cost? Or is this to ultimately make more money but leaving the front-facing cost, the one 'advertised,' (per socket) low enough to remain competitive? I'm having a hard time seeing any benefit to users here, and definitely seeing some headaches for not a few folks. Maybe someone from VMWare (preferably not marketing) could illuminate us as to the benefits.. ?

b4real
b4real

Long enough to bait you in, yet too short to really get a feel.

b4real
b4real

Isn't really great either... As things like virtual appliances would be costed. Also, all VMs are not created equal. So, the dev file server would cost the same (1 VM) as the production email server. That's inherently unequal also.

AnsuGisalas
AnsuGisalas

I guess it lets people justify sampling the product, meaning more people will stick with it... not the most evil scheme I've heard of.

pgit
pgit

It's not the most desirable scenario, but there have been a few occasions where testing hadn't quite been definitive (yes or no) withing the trial period and we (ahem..) tinkered with the clock a bit to keep it going a few days beyond the alloted time. It depends on what we're testing, but I dare say near all of it is done on isolated, dedicated testing hardware. I can't remember the last time I deployed something untested in a working environment.

b4real
b4real

the model with vSphere 4 and VI3 was really straightforward and scaled well. I don't think the same can be said for vSphere 5.

Editor's Picks