Virtualization, Cloud, Infrastructure and all that stuff in-between

My ramblings on the stuff that holds it all together

Killing vRAM is a backward step

 

VMware announced today that it was undoing the vRAM based licensing it announced to much boo’ing last year and will revert to the original per-CPU model (without the core limitations), I had hoped that vRAM was an intermediary step to pure per-VM licensing to help people (and the industry/channel) over the hump to move from legacy to something more radical – it would seem this will not be the case for the forseeable future.

Whilst I admire VMware for listening to customers that complained about vRAM changes and judging by the applause in the room when incoming CEO Gelsinger made the announcement you’ll probably not agree with me but I think this is a backward step given the stated vision for building cloud infrastructure. In my humble opinion they should have dispensed entirely with per-host, per-socket or even standard/enterprise/enterprise plus editions and bundles and focused purely on a per-VM (or vApp/Group of VMs) feature license. crazy? moi? maybe – but let me state my case…

Cloud is all about dynamic workloads, rapid provisioning and self-service, not being tied into X capacity or capability which has to be paid for up-front, in advance just incase you might need to use it one day – it’s about pay as you go – pay for what you use; it means you can’t take too many risks, or be too innovative because you need to sink significant cost upfront to make things happen or go to established clouds like Amazon, Azure, google etc. where someone has already taken that risk.

I’ve previously written about the need for the software industry to move away from legacy perpetual licensing models and move to a rental/subscription based model with lower cost of entry – allowing real flexibility to scale up and down, and allow businesses to attribute true cost to service lines or business units before the fact, rather than after.

Why not set a lower unit cost for vSphere per-VM but let consumers buy premium vSphere features and add-on products (like SRM, vCenter Ops, etc.) a la carte? on a PER VM basis then people can buy commodity hardware as and when they need it – without having to absorb large chunks of software license costs per physical asset, this is a good way of removing the cost barrier for small organizations (that may have them looking at Microsoft or other solutions and reduces the risk/uncertainty in planning implementation – pay for what you use (or license what you think you’ll need).

By way of a very simplistic example – with some dummy costs to illustrate the point is below

There is a base license to use (LTU) cost – which is per VM, regardless of how many ESX hosts, clusters, sites, datacenters it runs on, so you merely specify on a monthly/quarterly/annual basis how many VMs you are running – or have vSphere report the number (this is how it works for VMware’s service provider licensing – VSPP).

image

So the per-VM cost is built up in layers – base and premium functionality, pay for what you need, pay for what you use – don’t be tied into bundles, editions and planning for changes that may never come – easy to step up and down in levels of functionality for individual vApps (or even individual VMs).

Depending on how it’s implemented this may need some changes to the product to facilitate – maybe it’s not a hard block that you cannot enable a feature, but vCenter will report that vApp 1,3 and Test 1 are out of compliance with your licensing (think host-profiles) and give you a click-through option to uplift your VMware licensing rental agreement, or even disable the functionality for offending vApps.

Hardware is cheap and commodity but slow to procure and has a traditional manufacturing/distribution chain behind it, you can’t generally sell it back or scale it down.

Software is relatively expensive but quick to procure and implement (automatable, even in terms of the software defined datacenter)

Neither are particularly flexible today with legacy sales, channel and distribution infrastructures that underpin a massive workforce in VARs, SI companies etc.

It’s hard for hardware vendors to price and sell their products on a flexible basis (they have to cover cost of design/manufacturing for a physical asset (although I’ve previously written that I think this is where VCE should have focused here instead of becoming just a reseller/SI)

Software vendors can do much better to clean up here today as they are less-burdened with a traditional manufacturing and distribution chain – whilst they obviously have shareholders to satisfy and costs to cover they can be much more innovative with how they sell and distribute their products – taking a longer vision and more incremental revenue (maybe less satisfying to shareholders and analysts, but..)

In the cloud (especially so in the private cloud) Workload is important, not infrastructure; and cost should be attributed accordingly.

None of this will change overnight – but I do believe this is a better model for the future – feel free to disagree (constructively) in the comments!

8 responses to “Killing vRAM is a backward step

  1. JeffS August 27, 2012 at 9:01 pm

    I see where you’re going and think the flexibility you describe is a good thing. That said, the idea that a tiny linux appliance vm has the same cost as a huge mission-critical vm rubs me the wrong way for some reason.

    In a private cloud, a virtual machine in an of itself only has a cost associated with it if you’re bumping up against your host maximums. If I am billing back, it’s not a problem, but if I’m not it causes budget issues. Then again, the idea that there should be different pricing models for different size businesses has always been an idea many were in favor of.

  2. Dejan Ilic August 27, 2012 at 9:40 pm

    On the other hand the new licensing it seems it will be on the level with Windows 2012 / system center 2012 datacenter licenses, so i suppose that is what Vmware was looking at when deciding on the new model.

  3. Pingback: vSphere 5.1: what 5.0 should of been! « TechOpsGuys.com

  4. EtherealMind August 28, 2012 at 2:32 pm

    vRam makes little cost difference within a three year timeframe. Over a five year timeframe as memory consumption increases VMware would gain more revenue for no extra effort. That’s the taxation effect and that’s what I’m against.

  5. Bruno J. Melo August 28, 2012 at 9:39 pm

    Is a nice idea but I also share JeffS’s opinion… Furthermore, you need to take into account that, in order for “vendor lock-in” to work, most vendors present solution bundles in which you have a lot of features combined in hope for costumers to start using them and see the real benefit.
    If they only presented prices per premium feature, as you suggest, some of those features could possibly be disregarded by the customers opening a window of opportunity for third party developers and a more fierce competition for VMware…

  6. Pingback: VMworld 2012 - The hare and the tortoise | www.vExperienced.co.uk

  7. Pingback: Welcome to vSphere-land! » vSphere 5.1 Link-O-Rama

  8. Pingback: vSphere 5.1 Link Documentação « Osvaldoneris's Blog

Leave a comment