Is there a best-fit pricing model for public cloud management services? - 2

In my previous blog, traditional pricing models and the typical characteristics of public cloud management. So the question to ask is, will the long established pricing models work here? T&M is evergreen but risky for customers, thus forcing them to quickly move away from this model. Providers do not want to go with fixed price model either given the variable/agile nature. I’ve seen some providers trying to price it using the technology/service component based model such as per VM, per-network element, per-storage element, and so on. In my opinion, this is incorrect as you will not find a public cloud environment that is completely Infrastructure as a Service (IaaS) and only use these elements.

Take any other established pricing model and try to fit them into this situation. The outcome will be a highly complicated model that no customer would be able easily understand, thus delaying the decision-making and buying process!

So what is the right answer? A more appropriate question would be ‘Is there a right answer, yet?’ Customers expect pricing models to have certain characteristics – simple to calculate, low-risk, outcome-driven, fairly predictable/upper spend capped. Basically, some sort of ‘predictably agile’ pricing model for infrastructure management services (IMS) should be developed. The fundamental principle of this model should ensure fairness in distribution of risks and encourage efficient work benefiting both parties, all of this while keeping the model simple.

I’ve seen some providers use a cloud spend-based, layered pricing model with a good amount of success. The layers typically are:

• Layer-1: X% of customer’s public cloud spend as the charges for cloud platform level activities
• Layer-2: Additional a% for OS level activities
• Layer-3: Additional b% for application platform level activities
• Layer-4: Additional c% for tool chains level activities

This may seem to fit the aforementioned principle. However, depending on the characteristics of the ‘workload model’, i.e., workload type| environment| deployment model | automation quotient, the risks and benefits could swing either the customer’s or the provider’s way. Therefore, it is imperative to define a few standard ‘workload models’ (which becomes the unit of charge) and the percentage charges should be based on those models. The models can be a combination of the below listed aspects and then you can keep the percentage that you charge against the ‘cloud spend for these workloads’ based on the combinations you’ve arrived at and your traditional aspect of SLA performances.

A quick assessment of customer’s cloud environment (questionnaire based?) should be able to provide with a decent understanding of the existence of these ‘workload models’.

Now, the percentage that you want to charge for each model is still going to be a tricky game, but patterns will emerge. Unless the providers know how much manual and automated work typically is involved in maintaining each of these workload models, it is going to be a hard time justifying the ‘% charge’ with your customer and the provider’s business finance team. I’m not saying this is the best fit pricing model for the management of IT infrastructure environment on cloud, but this is something that could be explored as it is fairly easy to understand and has fairness when it comes to risk sharing. 

There are a few other innovative pricing modes like ‘equity-based’ ones that are interesting but for now there is not much evidence of their widespread usage and are more experimental in nature.

Let me know what you think, and in case you find a better fit, predictable pricing model for managing the agile IT infrastructure on cloud, do post your comments!