Introduction
Cloud computing has socially engineered us to think in terms of consumption based pricing. Whether we are provisioning a terabyte of storage or a virtual core of compute, we expect to pay for only what we use. Unfortunately, this distinctly 21st century thinking has not translated into the support services offered by most clouds today. Providers such as Amazon and IBM price their services based on the classic software maintenance model of the 1980s, resulting in customers paying more for less in cloud support.
How Cloud Pricing Works
To review what is wrong with cloud support, we’ll use Amazon as an example, since it is both readily recognized as one of the highest quality providers of IaaS services and is a pioneer in consumption based pricing. Amazon offers a typical tiered support model, with four tiers (Bronze, Silver, Gold, Platinum). At the high end (Platinum), you pay the greater of $15K per month or 10% of your monthly bill for phone support and 15 minute responsiveness; at the low end (Bronze) you pay a flat fee of $49 for access to community forums.
So if you are an Amazon customer who spends $100K per year on AWS infrastructure and need one hour phone support, you will pay an additional $10K per year for Gold support. Premium support - which comes with 15 minute response time and architectural support - would cost you an additional $180K per year.
There are essentially two problems with this approach to cloud support:
The classic software maintenance model was created before SaaS and MRR, and represented a way for software providers to drive recurring revenue. The typical model resulted in customers being charged 20% on average annually for a provider to support the software. The issue with applying this model to cloud support is that there is no custom installation of software for a customer, so the likelihood of the support being specific to the customers’ specific use is substantially lessened.
To prove the point, I did an analysis of one year of support issues across a series of AWS accounts for which I am responsible, and found that 80% of all issues were caused by failure or performance problems with the underlying APIs. The breakdown was as follows:
- 38% of issues were related to the provisioning and deprovisioning of infrastructure (e.g. API call to delete instance becoming stuck)
- 21% of issues were related to reboot API requests either failing or taking an unexpectedly long time
- 21% of issues were related to performance issues with the network or storage infrastructure
Amazon offers a world class cloud with highly reliable infrastructure. But when my team opens a support issue, it is almost always not related to our application. The reason is simple: the interface between a cloud provider and a customer is limited to a well-defined API. The cloud provider does not support what you do with the infrastructure you provision with the API, and you do not have direct visibility into the health and performance of the infrastructure behind the API. So in effect, your support costs are paying for the privilege of asking what is happening on the other side of the API requests.
#2: Proportional Costs
The second issue with the pricing of cloud support it that it is priced proportional to your monthly costs. This actually made sense with software licensing, where the complexity of supporting an installation was directly proportional to its scope and thus cost. But as mentioned previously, the cloud provider is not actually supporting your specific use of their infrastructure, but rather the availability, performance and security of their infrastructure.
So if we exempt support issues related to failed or non-performing API calls, is a user with 100 instances likely to open 10 times the number of support issues as a customer with 10 instances? Is a customer with a 1000 instances likely to open 100 times the number of support issues as a customer with 10 instances? It is much more likely the frequency of support issues is related to the experience of the customer and quality of the cloud infrastructure.
Solution: Consumption-Based Pricing
The time has come for a cloud provider to innovate in the pricing for support. We need support services that are priced per incident, with different tiers to allow customers to pay more for either accelerated or consultative services (e.g. architecture consulting). In the meantime, I recommend customers carefully review their support needs and the available options to ensure they are getting the best value for their money.
Related Posts: Cloud Escape Velocity: PaaS on IaaS, Ten Commandments of the Cloud