In my previous blog, I showed some common cost ratios (total cost) on an average VM basis. It should not be a surprise, though, that there is no such thing as a standard or common VM, so the costs cannot be too generalized either. Getting to a unit cost by size is important before any VM cost remediate plan gets started.
When we do a VM TCO baseline exercise, we need to know some basics around total # of VM, total # of hosts, age of the assets, total storage etc. Doing a macro-level VM TCO measurement is pretty straight-forward to calculate. The trick comes into understanding and measure the unit cost by VM size. To this end, we ask customers to run a VM script so that we can get some basic information about the size and quantities of all VMs in the estate. This chart is one of the summaries that comes from that script (and some excel pivot tables).
What we learn from this size and quantity distribution:
- How many of the VM are small, medium, large etc.
- In this work, we assigned VM size by number of vCPU per VM (1,2,4,8, 16 etc.) It is also practical to define VM size by memory or even storage (less likely)
- Then by size, we also measure the GB of storage of for each VM in that size. In the above graph, you can see where large and x-large VM have very large storage requirements
To calculate the total cost of the VM estate, we have the client choose from 24 possible options (outlined here). With the total estate costs understood, we can now assign weighted costs per VM. This weighting is usually a combined function of vCPU, Memory and storage per VM. The results for the above example look like the following:
Given the sample chart above, we can now understand the cost structures, and eventual action plans, to reduce VM total costs
- X-small and small VM shown above have a unit configuration, that may favor a hyper-converged solution. But with very low unit costs for these sizes ($30-$60 per Month) it might be hard to justify moving to a separate infrastructure just to reduce costs
- The workload of X-large and Large VM have such a high cost structure that they may be some unique opportunities to look at SMP or other HW options to deliver infrastructures at a lower unit cost.
- Perhaps the type of storage used for these sizes could be re-evaluated
- We see scale-out systems like hadoop and IOT falling into some of these categories, and the storage architecture tends to be the source of the high costs
- Larger VM systems could possibly look at options like object store, or different backup schemes to reduce unit costs
- In this above case, the jump in unit cost between Medium and Large was due to that fact that there was just 1 medium size, but 4 different sizes in the large family. There could be a good case to reduce the number of VM sizes by offering a standard VM catalog.
As we undertake a VM cost improvement program (which is very popular these days with very attractive cloud pricing), it is important not to make too many generalizations. Getting an atomic view of VM definitions, VM cost structures and the reasons behind the costs categories will enable architects to pinpoint the cost problems, and thereby pinpoint better solutions for continuous improvements.