What is wrong with the pricing of Cloud providers?

When I passed out of MNNIT in 2010, the latest buzzword in the IT industry was cloud computing. Everyone was talking about how cloud computing is poised for exponential growth in the coming years. The prevailing consensus at that time was that public cloud computing industry had stabilized after several years of continuous development and adoption of AWS, Azure, Google Cloud Platform and other service providers. The cloud industry had evolved from the "startup era" to being "enterprise ready". More than 6 years have passed and the overall sentiment today is exactly the same as before i.e. being at the threshold of a major change. However, cloud computing has still not become the de-facto standard for enterprises (except tech enterprises) as almost everyone had predicted, during my engineering days. The transition from a non-cloud environment to a cloud environment remains as challenging as ever. So what has gone wrong?

According to me, there are multiple reasons (data privacy, vendor lock-in, perceived lack of control, lack of bet-your-business SLAs, painful transition, lack of in-house expertise etc.) for the slow transition to the cloud by non-tech enterprises. It is not possible, in this post, to go into detail for each of them. I will probably be taking up each one of them in multiple subsequent posts. In this post, I will focus on just one reason - wrong pricing strategy, by cloud service providers.

Current pricing strategy of Public Cloud providers

The basic pricing strategy(s) of public cloud providers are very similar. There are multiple pricing options for different cloud services by different cloud vendors. I will classify them into the following two broad types of pricing strategies -

Type 1: Pay-only-for-what-you-use Pricing Strategy

In this type of pricing strategy, the cloud provider does not guarantee a fixed cost per month/year. The final cost depends on the number of resources provisioned and the usage characteristics of those resources. Internal cost controls for such on-demand/on-spot pricing is done by using tools such as quota/alert mechanism. Some common mechanisms are -

1. Fixed rate, single-metric based pricing: The fixed rate depends on a number of factors/conditions chosen during the initial setup of the cloud resource. The final price to the customer depends on the total usage of some metric such as usage time (hours), storage used (GB), IOPS-month etc. For example - AWS EC2 c1.xlarge instance is priced at $0.11 per hour for 'Asia Pacific - Mumbai' region.
2. Fixed rates, multiple metrics based pricing: This is the most common type of pricing adopted by most cloud providers. The final price depends on fixed rates for multiple usage metrics. Few examples are - (1) AWS EBS SSD io1 volumes are priced at $0.131 per GB-month + $0.068 IOPS-month and (2) AWS RDS db.r3.2xlarge is priced at $1.320 per hour + $0.22 per million requests. (Both for Mumbai region). There is also step-pricing where the fixed rate is different for different ranges of values and add-on pricing for one-time activities such as data transfers, configuration change requests etc.
3. On-spot pricing: In this pricing strategy, the rate per metric(s) is determined through some sort of bidding process (creating a marketplace) rather than being fixed by the cloud provider. This is very popular among startups and tech companies which use this, to lower their operating costs significantly.

For any typical customers, the actual usage of resources reserved is very low. Hence even though the fixed/variable rates for this type of pricing strategy are quite high, the overall bill for the customer is significantly less.

Type 2: Pay-only-for-what-you-reserve Pricing Strategy

In this type of pricing strategy, the cloud provider reserves a certain resource for the customer for a fixed amount, regardless of the usage of the resource. The cloud provider gives alerts to the users when they are close to exhausting the resource reserved. This can be further sub-divided into -

1. Reserved Virtual Resource: The virtual resource is reserved during the initial configuration phase. The cost to the customer changes only if the resource configuration is changed. New resources can be reserved whenever required.
2. Reserved Physical Resource: This strategy is very similar to renting hardware on third-party data centers, where customers reserves physical resources and these resources are not shared with any other customer. This is not the preferred pricing strategy of cloud providers for obvious reasons. However, cloud providers often use this strategy to acquire customers initially.

Most of the cloud services and features have been built keeping pay-for-only-what-you-use model only. The pay-for-only-what-you-reserve pricing model has been introduced much later. Various studies and research papers have shown that large non-tech companies generally prefer pay-for-what-you-reserve pricing while startups and large tech companies generally prefer pay-for-what-you-use pricing. Both these pricing strategies are far more complicated and difficult for customers to understand compared to the simple software licensing agreements in the non-cloud world.

Budgeting & Procurement process in a large enterprise

Before I start on what is wrong with the current pricing strategy of cloud providers, let me briefly describe the budgeting & procurement process in a typical large enterprise.

Budgeting is one of the most political exercises in any company. In modern times where designations are losing their value, the budgeting exercise establishes the real political power of a person/department in the company. Because of this, budgeting takes a lot of time, effort & negotiations. Given the semi-fixed nature of the budget, different departments overstate their requirements, based on over-optimistic future projections, and add buffers for handling exigencies. A strict time-consuming audit process is required to limit the overall company cost, resulting in a long lead time for budget approval. In this way, a vicious cycle is formed and it becomes worse, the larger a company grows. The net result is that once decided for a year, the budget is not subject to any change for a lot of decision makers in the company.

Because of the very nature of budgeting process, year-after-year, it is essential for any manager that his/her estimations are taken seriously. The budget estimation must closely match the actual spend in that year else it would be extremely difficult to get budget approvals for the next year. Managers hate surprises and uncertainty when it comes to pricing. Also, they are extremely unwilling to let engineers (or even lower level managers) have any role in making monetary decisions for the company.

Most surveys rate "procurement" as the most painful process in any large organization. It is made even more complicated by internal cost allocation rules between different projects/departments/regions, various procurement guidelines etc. The ERP software (generally SAP) is often so complicated, that a special team, generally called MIS team, is designated to manage that. The entire procurement and payment process requires coordination of multiple stakeholders such as - cost approval authority, procurement team, legal team, MIS team, accounts team, audit team etc. Hence it is very important that the 'cost to the company' is easy to understand and allocate internally based on the different company rules. Also, it is very important that the vendor's bill (i.e. line-items in the bill) can be easily matched with the budget approvals entered earlier, in the company's ERP software. Delays in the procurement process for 'Change Requests' is one of the most common reasons for the failure of IT projects, even though the monetary value of the 'Change Request' is insignificant in comparison to the overall project value. This may seem counter-intuitive but that is how all large organizations work.

Preference of CapEx over OpEx

For any large and growing company, that has a steady stream of revenue & a predictable future, there is a strong tendency to prefer capex over opex for all small (<5% of the overall expenses) expenditures, including IT expenditures. Apart from the fact that capital expenditures are easy to budget and procure than operational expenditure, it is easier to get bulk discounts for one-time capital expenditures. The main focus of procurement team is to get the highest possible discounts and if excess resources get purchased due to over-optimistic estimations, that is not the fault of procurement department but the department providing the estimations. Moreover, even if a department gets more resources that it can productively utilize, it will not highlight this waste. Once a capital expenditure is made, its usage is rarely subject to audit, in sharp contrast to operational expenditures (opex).

Challenges with current Cloud pricing strategy

The current pricing strategy of major cloud providers lead to the following challenges for large non-IT enterprises -

1. The cloud pricing is far more complicated than simple license-based pricing for IT products or pro-rate based or milestone based custom product development pricing models that most companies are used to, for all their IT needs. For different cloud services, the pricing depends on very technical usage metrics, which are difficult to understand for decision makers in large companies.
2. In a non-cloud environment, a very high-level design is sufficient to finalize the hardware requirements and make a relatively accurate capex/opex projections. Multiple virtual machines can be spawned off from the bare metals as required by the IT architecture decided later on. However, if an enterprise decided to build a new IT product using public cloud providers, the final price that the company needs to pay each month/year depends entirely on the detailed IT architecture. The current pricing strategy makes budgeting difficult for companies who have no experience with a cloud provider earlier. One of the main reasons why the Bare Metal Server by IBM SoftLayer is so popular is because it is easier to get budget approvals for it, even though it comes with minimal features.
3. The biggest pain point for enterprise customers is the variability in monthly/yearly bills by the cloud provider. The last thing that a product manager wants to do is to go to the accounts department and explain to them the line-items in the bill and get it cleared for any vendor. It is a thankless job which no one wants to do. In general the more complicated the bill (irrespective of the total amount) the longer it takes to process it. I know a lot of executives who give their personal credit card information to cloud providers and then get the amount reimbursed from the company under miscellaneous category just to avoid the procurement process of the company.
4. Most cloud providers like to delight their customers by reducing their pricing unilaterally when their costs come down (due to the economies-of-scale effect). Also, most cloud services have provision for some sort of monetary penalty to be paid to the customer, in case they are not able to meet the SLA agreed upon. While customers surely are delighted by these, enterprise customers find it difficult to account for them in SAP/ERP. This is especially true if the costs are internally allocated to multiple cost centers.
5. Cloud resources (on which customer billing is done) can only be created by system engineers or software developers or 3rd party vendors. However, they cannot be allowed to take any monetary decision on behalf of the company. In most companies, even engineering managers or product managers do not take any monetary decisions. The process in large companies are designed to ensure that untracked and unauthorized expenses do not happen, even by mistake by developers/QA/system engineers etc. Public cloud platforms do have quotas (and similar mechanisms) to manage/control the resources used/reserved but they are considered inadequate for micro-managing costs. This leads to a feeling of “lack of cost control”.
6. For a lot of cloud services (especially where billing is based on IOPS-month), the customers are completely dependent on cloud providers to find out the actual usage metrics and there is little that they can do to cross-verify these claims. This increases the strong stickiness problem (being vendor hostage) that anyways cloud providers have to deal with.
7. The extremely detailed pricing of public cloud providers, do a good job at highlighting resource waste in any department. Departments using public cloud providers are flagged far more often by internal audit team for improvements. However, this sometimes lead to non-adoption of cloud by the decision makers. This is also one of the reasons why pay-for-what-you-reserve is more popular in enterprises that pay-for-what-you-use pricing. IT audits hardly ever highlight under-utilized capex/reserved resources of any department.

Most of these pricing problems are applicable only for IaaS (Infrastructure as a Service) and PaaP (Platform as a service) cloud services and not for SaaS (Software as a service). SaaS are generally license based very similar to the familiar non-cloud license based software.

Suggestions / Recommendations

I don’t think there are simple solutions to the pricing problems that I have listed above, for all the different cloud services. Please note that the current pricing strategies work very well for startups (and even large IT companies) and hence they must also continue. The below recommendations are only for large enterprise customers -

1. Simplify Pricing for Enterprises: All cloud services should have an alternate pricing strategy especially for enterprise customers. The pricing should be as simple and very similar to license-based pricing which enterprises are so familiar with. The pricing should not be linked to usage or any metric and there should be no additional cost for data transfer, configuration change requests etc. Instead of transferring cost of each underlying resource used (compute, storage, network etc.) to the customer transparently, the cloud provider needs to provide a uniform price assuming average utilization of the underlying resource. This will result in a revenue loss for some customers and a revenue gain for some customers but will help simplify cost and get more enterprise customers. For any application, customers use several cloud services. Hence for this pricing strategy to work, it must be applicable to all cloud services and not just for some select services. This is what is lacking in the pricing strategy of all cloud providers currently.
2. Integration with SAP and other ERP solutions: Cloud providers must build add-on(s)/middleware(s) which integrates their billing and pricing module with SAP and other leading ERP providers. This should improve the “Resource Tagging” feature and make it easy for all stakeholders to match the budget approvals to the monthly bill by cloud providers. It should make the work of auditors easy by highlight price reduction by the cloud vendor, SLA penalties and other reasons for variations in the monthly bill.
3. Create tools/process for better micro-management of cost: There are some cloud providers who do not provide an admin login to change any quotas. The quotas are made zero by default (except if some service is provided for free). Any change in quotas requires contact to the customer support team which would increases quota for that service on behalf of the customer. Cloud services can also create internal approval tools where the engineers can only request for any new cloud resource or any other cloud service (initial data transfer, configuration change request etc.) which impacts billing. The request would then goes to the customer’s IT procurement team for approval. Also, changes need to be made in services such as Elastic Load Balancing to add extra approval processes.
4. Budgeting & Procurement process change consulting: Cloud providers generally do a great job of technical follow-up of customer cloud implementations and resolving their technical queries. They generally have senior architects helping customers with initial cloud adoption. However, cloud providers neglect helping enterprise customers change their budgeting and procurement process, to deal with the different cloud pricing mechanisms (especially on-demand or on-spot pricing). These are not small process changes for customers. Process consultants are required which can take a large enterprise, step-by-step (first adopting simple pricing mechanism and then shifting to on-demand or spot pricing) into the cloud platform, after stabilizing & auditing the process changes for each step.