Scott Drummonds on Virtualization

Chargeback Resistance (with Survey Results)


A few weeks ago I posted a survey asking for your thoughts on chargeback in virtual infrastructures.  The results I received confirmed my observations of the scarce use of chargeback policies among VMware’s customers.  I have written before that I think this is a mistake.  And by bundling VMware Chargeback with the recently announced vCloud Director it appears that VMware agrees with me.

Before I offer my own thoughts, let me sum up a few interesting statistics from the survey.

  • Only 54 people responded to the survey.  All of my articles are read by hundreds of people and many are read thousands of times.  It is safe to assume that the vast majority of non-respondents did not comment because they have no chargeback policy.
  • Of the 54 that did respond, 13 (24%) have implemented some chargeback system.  I estimate that these 13 account for about 1-5% of the total readers of that entry.
  • The vast majority of those with a chargeback system have based it on homegrown techniques (scripts, manual accounting, etc.)
  • The top three factors in assigning VM cost were (1) VM memory size, (2) a fixed VM cost, and (3) the number of vCPUs.
  • The least used factors from the survey in assigning VM cost were (1) presence of advanced management tools like AppSpeed or CapacityIQ, (2) resource usage, (3) presence of platform features like DRS, HA, FT, and (4) the quality or performance of the physical server.

I have concluded three things from this survey:

  1. As I suspected, very few people are bothering with chargeback policies.
  2. People are (erroneously, I believe) favoring static, perpetual pricing systems over dynamic, metered systems.
  3. No cost is yet being assigned to platform or management features.

Let me comment on each of these in turn.

Chargeback Is Unpopular

Anyone talking to customers about chargeback already knows this. Chargeback policies will likely document IT’s presence in one of two unpopular states: losing money or profiting from its lines of business. The first state makes IT look incompetent. The second makes them look greedy and foolish. Only by balancing the books–a process fraught with unassailable complexity–can everyone be happy.

The fundamental problem with balancing the books in IT is that the value of the infrastructure is amortized over the number of services run upon it. And that number is never known in advance accurately.  When stupidly calculated, the first virtual machine costs $50M and every other one is nearly free. To avoid this situation many IT departments guess the number of virtual machines they will deploy and start their chargeback model with each virtual machine near its proportional use of the shared infrastructure. But if you get this wrong then your IT department either appears to lose money (bad) or profit from the lines of business (worse).

The solution is to stop using fixed cost models that charge the same amount for a virtual machine that uses none of its resources as one that uses all the resources assigned to it. More on this in the next section.

Perpetual Cost Models Are Common, Metered Not

Most software licensing is based on perpetual models, where a cost is assigned to software instances and not by utilization. Perpetual models are easy to understand and estimate with simple tools. But they are incompatible with the notion of utility computing, where consumers expect to pay for what they use, not what they might use. It is only in the broken, anti-competitive mobile phone business plagued by multi-year contracts, a discounted capital expense, and punishing contract termination fees that the utility computing model has not succeeded where it rightfully should.

Metered cost models fix the above problem of hardware cost amortization by forcing IT to plan capacity correctly and suffer when it fails to do so.  But capacity is much easier to plan than virtual machine (or service) counts.  We can estimating capacity using traditional methods on existing software and setting cost assuming utilization will never exceed some threshold (like 80%). End users they pay for the storage, network, memory and CPU that they use as a fraction of this threshold.

But IT needs a more flexible physical infrastructure than is generally available today to support their constant refinements in capacity estimation. This is where the approach taken by the VCE coalition with a Vblock offers great value. In theory a new Vblock can be added to the infrastructure (or scaled up from existing resources) to add capacity in weeks, not months. This saves IT’s bacon in that it will not have to over-purchase early and suffer loss or slow virtualization adoption later to avoid capacity overage.

No Cost Exists For Platform, Management Features

Until recently there was no option from VMware for per-VM licensing schemes in the enterprise. But by offering such for a small number of products (AppSpeed, CapacityIQ, Chargeback, SRM, and others) VMware has planted the seed of per-VM pricing in their customers’ minds. That seed will germinate and form new internal pricing models, for certain. This is a Good Thing.

Platform features like Fault Tolerance change the way virtual machines are managed and how their applications are configured. Management products like SRM can reduce downtime during a disaster, during which hours could be worth hundreds of millions of dollars to the right customer.

The funny thing to me about these platform features is I wonder if their presence should have a reverse cost in a chargeback system. What administrator would not choose VMware HA seven days a week and twice on Sunday over configuring an MSCS cluster? HA’s ease and simplicity make it incredibly attractive where a couple minutes downtime can be tolerated. Should HA then be assigned a negative cost for the virtual machines that use it? I am still pondering this myself.

2 Responses

What about businesses that do not incur departmental wrath?! Namely they are their own boss, with their own infrastructure … there is no cost for end-users to bear in [ab]using resources, so the only ‘cost’ is the negative performance to all users collectively once things get out of hand.

Something is missing, and it isn’t merely the virtual guillotine suspended over their heads with a dollar sign, but a change in the way individual users think about their consumption. Any good economists out there?

  • Scott as a long time customer Id have to agree with this post and inhale always been uncertain about chargeback. One is that our company does not and have not ever had a chargeback model and two I have never believed that you could get an accurate dollar figure with virtualization which has so many layers that come into play. Really how do you account for all the things like thin provisioning, deduplication, Qos, overcommitted resources, etc then whether the vm is using it or not?