Everything I Needed to Know about Chargeback I learned in Kindergarten - by Jamal Malik

Everything I Needed to Know about Chargeback I learned in Kindergarten - by Jamal Malik

  • Comments 2
  • Likes

imageIf Jimmy has five apples and he eats two of them, how many apples does Jimmy have left?

I’m sure everyone at some point in their lives were asked a question resembling the one above. Cloud and Datacenter Solutions HubInterestingly enough, it is not far from a method of chargeback based on consumption based pricing (no pun intended).

Although we talk about chargeback (or ‘showback’ in some circles) in regards to building clouds most conversations default to consumption based usage of achieving chargeback.

There are however multiple methods of achieving chargeback and I wanted to discuss a few of them in this thread.

These different methods only differ in terms of complexity and provide models to charge for services based on the needs\maturity of the organization and composition of Services.

The first and easiest Chargeback method is Notional Pricing. Notional Pricing aggregates the cost of services as a single unit and it is then shared to Business Units. This method makes sense for organizations that are not looking to turn a profit from providing cloud services and instead just want to “showback” to the business the cost of providing cloud capabilities. It can still have an impact on consumption behavior because usage of services can at least be related to the business in terms of “who is using what” however this does not happen through the service provider\service consumer relationship.

The second form of chargeback is “Fixed + Variable Pricing”. This chargeback method builds on Notional Pricing as there is a “base” fee for consuming cloud services and a variable cost is added to specific services hosted for individual business units. This can be a method to share the cost of “Shared Services” (more on that later) and then for additional resources business units can be charged separately. This method provides better consumer behavior as usage of resources can be provided almost immediately and tied specifically to business units.

The third (and most popular) form of chargeback is “Consumption Based Pricing”. This is by far the most complex of the chargeback models however it enables completely the service provider model of delivering services. Business units (or tenants) are charged specifically for every Service that is used. Now, this form of chargeback can get a bit complex and the different methods of enabling this model can fill a book. So, for the purposes of this thread I’ll stick to “Quota-Based” chargeback (and not metered or measured use Chargeback).

Quota based chargeback is fairly straight forward. Tenants (or business units) are assigned a specific amount of quota (Jimmy has been assigned five apples). The tenants however are only charged for the quotas that they consume (Jimmy only ate two apples). Here, resources can be oversubscribed to tenants (which is perfectly fine) and service providers then manage capacity and demand of resource pools to fulfill tenants request for resources (easy right?). Tenants are only charged for the resources they deploy based on their quota assignment. In regards to IaaS (for example) we are referring to virtual machines here where:

1 Quota Point = $100

  • Small VM = 1xCPU + 1 GB RAM + 40 GB Storage + 1GB NIC  = 1 Quota Point ($100)
  • Medium VM = 2xCPU + 2GB RAM + 100 GB Storage + 10GB NIC = 2 Quota Points ($200)
  • Etc…

In this model the tenants are charged for resources that are deployed over time (let’s say 30 days).

If the Virtual Machine sits idle for the 30 days at little to no CPU Utilization the cost of the VM does not change.

It is important to note that if an organization is beginning their journey towards building a cloud solution it is important to start with Notional Pricing and work their way up to consumption based pricing. If you are working with a hoster or service provider for example they will want to jump into Consumption Based Pricing for obvious reasons. The reason why it is important to make this gradual change is because organizations typically need time to adjust to a new model of consuming for\paying for services.

Additionally, most organizations do not have the financial systems in place to support Consumption Based Pricing ‘out-of-the-door’. If for example an organization’s IT department is 100% funded by the business then turning around one day and telling business units you must now pay for IT services will sound absurd (if not unachievable). I am over simplifying the quota point method and certain variable can also be added to the cost of resources if desired (additional memory or Storage and etc…) A multiplier or premium can also be added for the type of storage being utilized (Bronze, Silver, Gold for example).

The plot thickens once you start working up the cloud stack (PaaS and SaaS). In regards to charging back for workloads you now have to define whether you are providing Services to Tenants based on Workload Segmentation or Infrastructure Segmentation. That however, is a conversation for another day…

To read more about Chargeback methods and Financial Management for Cloud Capabilities check out this article on TechNet:


Would like to hear the community’s thoughts on their own experiences in working with organizations in enabling chargeback.

I imagine many issues to ‘overcome’ have more to do with organizational dynamics more so that technical challenges,

Jamal Malik
Business Solutions Architect
Datacenter/Private Cloud Center of Excellence

Go Social with Building Clouds!
Building Clouds blog
Private Cloud Architecture Facebook page
Private Cloud Architecture Twitter account
Building Clouds Twitter account
Private Cloud Architecture LinkedIn Group
Building Clouds Google+ Community
Cloud TechNet forums
TechNet Cloud and Datacenter Solutions Site
Cloud and Datacenter Solutions on the TechNet Wiki

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Well written, and much appreciated.  A lot of people I talk to struggle with how to set costs for consumption.  Exactly how much is a vCPU or a GB or RAM worth?  How do you suggest they approach these?

  • Hi Yuri, great question. The answer to that depends on what you really trying to achieve. If, for example, you were acting in the capacity of a true service provider you are looking to monetize as many of the resources  you are providing to consumers (partly to manage resources properly and of'course also to make the most money possible). If you are part of an in house IT shop you are probably more likely looking to incent consumer behavior to choose only the resources they need when deploying workloads and secondly to 'showback' to the consumer the resources which they are consuming. If you fall in the later category you don't have to get very 'deep' in allocating cost to each individual unit of resource (vCPU, Networking, Storage and RAM). Additionally, in order to ensure that the services you offer to consumers (in this case VM's) are used as efficiently as possible and that your IT department is able to scale in terms of demand and capacity management. In this case the trade-off means offering the 't-shirt' size of VM's (small, medium and large for example) and not allowing consumers to 'add' additional individual resources when needed. This is a tough thing to explain to a developer that is used to asking for very defined VM types (2 vCPU, 4GB of RAM and 100GB of storage and 1xNIC). If they require more capacity than they consuming within an individual VM they will have to 'step-up' to the next larger VM. This makes allocating a cost to the different VM types easier for you and also aids in capacity and demand management functions. The trick is to assign a cost to aggregated resources. Check out the link above in the post for how to achieve this level of "Service Catalog Management".

    If you absolutely 'must' figure out the cost of an individual capacity resource (vCPU)  you start defining a 'scale unit'. This is a fixed configuration of Servers, Networking and Storage that you deploy VM's on. You then figure out the total 'capacity' of the scale unit. If you have the aggregated cost of the scale unit you could break down individual cost of resource however if you don't use the 't-shirt' model of deploying VM's you can finadvertantly overload on vCPU (as an example) and have 'wasted' resources in the scale unit becauase although there might be enough storage and networking to support more workloads you will have to provision another entire scale unit because vCPU's have been maxed. In Cloud Solution EVERYTHING is interconnected and managing resource individually for an internal IT department might be more effort that it worth especially since the overall goal might be 'cost recover' more so that revenue attainment. I hope this helps.