Reading through the vSphere 5 Communities Licensing Thread, one is struck by some of the similarities between this debate and its associated heartburn and the heartburn and debate over how we pay taxes to the government. When it comes to taxes we have certain expectations as to how the system should work.
Here some things that we expect of our tax system:
- The notion of vertical equity. What this means in English is that people who can afford to pay less should pay less, and people who can afford to pay more should pay more.
- The notion of horizontal equity. This means simply that people at similar income levels and similar situations should pay the same taxes as each other (or at least live by the same rules).
- Taxes should be predicable into the future. This is true for consumers, but especially true for businesses as businesses need to be able to make an investment today, and know how the returns from that investment will be taxed in the future. A corollary of this is that things should not change radically on you after you have invested in something based upon one set of terms and one set of assumptions.
- Compliance (figuring out how much you owe), should not be a burdensome task. It should be easy to get the data and keep the data that you need to figure out how much you owe.
- The tax system should not penalize what is generally accepted to be desirable behavior. For example the tax system should not penalize you for working extra hard if you choose to do so.
- Finally and most importantly the tax system should encourage growth. At an individual level it should make it easy for people to advance, and at business level it should make it easy for new businesses to be formed and existing ones to grow.
The vSphere 5 Pricing (per CPU and per GB of vRAM)
The table below shows the pricing for each of the vSphere 5 editions, the CPU entitlement and the vRAM entitlement for each license, as well as the resulting cost per CPU entitlement and cost per vRAM entitlement.
|vSphere 5 Pricing by Edition per Metered CPU and vRAM resources|
|Included CPU’s||6 CPU’s||6 CPU’s||8 CPU’s||6 CPU’s||6 CPU’s|
|Included GB vRAM||24||24||
|$/GB of vRAM||$21||$187||$417||$547||$458|
Applying the above Concepts to vSphere 5’s new vRAM Pricing
Let’s apply these concepts one at a time to the new vRAM pricing for vSphere 5:
- Vertical Equity. Here VMware has always been fair. The Editions of vSphere that are targeted at the SMB and SME markets (while missing many of the nice high end features in the Enterprise Editions) are considerably less expensive than the full enterprise editions that large enterprises use. Therefore small businesses who can arguably afford to pay less for a virtualization platform are afforded this option by VMware. Of course this ignores the question of why SMB’s and SME’s who can get Hyper-V for free should pay anything for vSphere, but that is another article entirely.
- Horizontal Equity. Here is where things start to get tricky. VMware makes the point that the vRAM entitlements are large enough to handle the needs of “most” of their customers. However it is already clear that customers who have pushed the envelope on density just a bit, or who have virtualized lots of memory heavy applications will have to pay a lot more for vSphere 5 than they paid for vSphere 4. So this boils down to whether or not a customer with 4,000 VMware hosts who is pushing the envelope on density is the “same” as a customer who is not. It also gets down to who should benefit as the customer drives up density. It would seem that the benefit of driving up density is a benefit of the platform and that the customer having paid once for the platform should not have to pay more to get the maximum benefit from it. The vSphere 5 licensing therefore fails this test.
- Predictable into the Future. It should be easy to forecast your licensing costs. With vSphere 5 this requires knowing what applications will be running in the environment, and what their vRAM allocations will be. However, the vSphere team cannot be expected to know how much memory applications will use in the future. The next version of a purchased application could simply require more memory (which may be specified by the applications vendor and out of the customer’s control). Having your application vendor change that memory specification should not cause you to have to go get more vSphere licenses. Similarly if the team building an application decides to increase its functionality, or make some other change that boosts memory needs that should not drive the need for more vSphere 5 licenses. VMware does get an enormous amount of credit for grandfathering all existing ELA customers under their existing terms. So all existing ELA customers will be able to buy vSphere 5 under the same terms that they are currently buying vSphere 4 in their existing ELA. So the new licensing fails this test for people who in in complex situations and who are not under ELA’s.
- Compliance should be easy. When it comes to vSphere 5 licensing that means that it should be easy to figure out how many licenses you need right now and how many you will need into the future. If you have one vSphere environment all pointing to one vCenter then this is not so hard. If, as is the case with many enterprises, there are multiple disparate virtual data centers owned and run by different groups, then consolidated reporting and analysis could be almost impossible. This is also an area where “pooling of vRAM” just does not work. If the test group has purchased N vSphere 5 licenses that have a certain amount of vRAM associated with them, they are not going to let another group use “their” vRAM just because it is technically in the same pool. The new licensing therefore also fails this test.
- Desirable behavior should not be penalized. In this context desirable could mean many different things. For example, for a performance critical application, ensuring that the application met its response time goals would be highly desirable. In order for this to be achieved, it may make sense to allocate 20% more memory to the application that it uses at its peak in order to ensure that memory bottlenecks never occur. In this case meeting the desired goal of applications performance is in fact inhibited by this new licensing as this new licensing will in the aggregate make being conservative about memory allocations more expensive. This also gets back to the previous point about who should benefit when the customer pushes the density envelope. Clearly it is in VMware’s interest for customers to do this, as it improves the overall value of the vSphere story. For VMware to slap a tax on density therefore seems to make no sense. The new licensing therefore fails this test as well.
- Promote growth. This is where the new vRAM entitlements may in fact be a fatal mistake for VMware. Because it may turn out that with this new pricing, adding new applications to an existing environment (increasing density) may become much more expensive than it was before. It may also turn out that virtualizing the next 60% of applications that are not virtualized yet may be more expensive than anticipated, since those applications are likely to be more memory intensive than what has been virtualized to date. The new vSphere licensing clearly fails this test.
Share this Article:
Latest posts by Bernd Harzog (see all)
- VMware vSphere 6 Attacks Amazon with “One Cloud, Any Application” - February 9, 2015
- VMware vSphere 6 Attacks Red Hat: VMware Integrated OpenStack - February 3, 2015
- Will the Public Cloud Be the Next Legacy Platform? - January 20, 2015