Welcome to my blog!

It seems that a week doesn't go by in which I don't talk to a customer or partner about cost allocation for virtual machines.  Cost allocation, in essence, is placing costs in their respective "buckets".  In fact, there is an entire subset of accounting (cost accounting) that differentiates itself from financial accounting (balance sheets, income statements, cash flow statements, etc).

The IT industry is actually a little behind the manufacturing industry in how we allocate costs.  The manufacturing industry has had to deal with things like shared vs. dedicated components and fixed vs. variable costs for many years now.  Typically, they use an approach called Activity Based Costing (ABC) refined over the years since 1987, and typically associated with Harvard Business School professor Robert S. Kaplan.

Whether we use ABC or not, we are still faced with the challenge of properly allocating the costs of our infrastructure (and its management), and, hopefully, finding a way of properly recovering those costs.  Virtualization gives us a platform to carve up our resources in a much more flexible manner than before, but now we need to recover the costs of those resources in a way that maps to how they are "carved up".

There are a number of tools that can report on resource utilization in a virtual server environment.  Examples include software from V-Kernel, VAlign, Tivoli, VizionCore,  SatoriTech, and Evident.  Those are valuable tools, but they all depend on one basic assumption: we know what our unit costs are.  We will probably never see a tool that can do that for us.

Each virtual infrastructure environment has a set of costs that can be put into one of four quadrants, as in the diagram below:

Shared+Fixed: This is typically our initial build-out.  In a VMware Infrastructure world, it includes the first Virtual Center server, the initial set of ESX Server hosts, and the initial set of shared storage.  It also includes the administration and engineering costs for the core infrastructure

Shared+Variable: Once the initial platform is built, most of the cost benefits are here.  Every subsequent ESX Server host added to the farm is a shared, variable cost.  Additional storage capacity on a modular or expandable array is shared/variable.  

Dedicated+Variable: Depending on how standardized the management and administration procedures are, some element of dedicated work is associated with an individual VM.  This element is becoming more "shared" as we move to a more standardized, templated-based infrastructure, and take advantage of tools like Update Manager.  Also included in dedicated/variable are certain software licenses are that are instance-based.

Dedicated+Fixed: I like to avoid this category as much as possible with virtual infrastructure. 

Once the costs are carved up into these quadrants, we need to do the following:

1. Decide upon one or more core units of measurement.  This may be a VM "slice" (if all VMs are considered "equal", a CPU unit (typically GHz), a memory unit (typically GB), and/or a storage unit (typically GB).  I like to focus on two measures - memory (because it is typically the constraint, more than CPU), and storage (which has a weak correlation with memory and CPU and can grow independently).
2. For all shared infrastructure, calculate the total number of the above units available
3. Subtract any applicable overhead
4. Subtract any applicable excess capacity required for growth or spikes
5. Multiply the total available capacity by the oversubscription ratio (this is an important topic best left for another blog entry - suffice it to say that oversubscription of memory, disk, and CPU can usually more than make up for overhead)
6. Divide the total cost of shared infrastructure by the above number, and the result is your per-unit cost of shared infrastructure.
7. Add in the costs of dedicated infrastructure.

As it is getting to be tax time, this approach may look a little familiar, and just as complicated.  Here is the basic formula:



Note that I have not split out fixed vs. variable costs.  That, again, is a subject for a later blog entry.  For now, let's include fixed and variable costs in the same bucket, and focus on how to carve up shared costs. 

The challenge with fixed costs comes in when our environment grows - the fixed portion becomes a smaller and smaller component as the virtual environment grows - and thus, our total per-unit cost gets smaller as we move to a more variable model.  To keep the model simply, let's assume a steady-state size of the environment, and build all cost estimates based on that.

I am working on an Excel spreadsheet using this methodology, so stay tuned.  For now, you may want to check out VKernel's methodology and calculator. 

[Edited 1/21: fixed VKernel link]