Managing costs in the cloud - Why you can end up paying more
"Why - when data is so important, and potentially so expensive - are we not doing a better job of managing this as an asset?"
Synergy Research Group reported that enterprise spend on cloud computing grew by 35% to reach almost $130 billion in 2020, while data center hardware and software spending dropped by 6% to under $90 billion.
This spending pattern is led, writes Matt Yonkovit, Head of Open Source Strategy, Percona, by a drive to take advantage of the benefits that cloud offers - more agility, more speed and more flexibility around deployment.
Ironically though, a recently published report by venture capital firm Andreesen Horowitz (A16z) which looked into the cost of this investment and estimated that companies spending on cloud, rather than buying their own data centre kit, led to a huge loss in market value.
See also: Companies could save billions by ditching ‘Hotel California’ cloud for own infrastructure
According to Sarah Wang and Martin Casado of A16z, the top 50 public software companies currently using cloud infrastructure lost an estimated $100B of market value. This was due to the impact on their margins as a consequence of not running the infrastructure themselves.
The argument for this investment of capital into owned assets and internal resources is that, as companies scale up their operations, spending on cloud is less efficient. Between these two extremes, there are some lessons that companies can learn.
Why choose the cloud?
The first, and most important point is that you are responsible for your cloud operations. You are also responsible for optimising your approach over time. In other words, the cloud providers are not your friends and will not look out for your best interests as a customer. The model for cloud is based on consumption, and it is not in the best interest of your cloud provider to reduce that spend on a service on your behalf. The only person who will proactively carry that work out is you.
The normal approach for many startups now is to scale up cloud services using credit cards - any time a limit looks like it will be reached, you can quickly move up to the next instance size. This is easy to do, but it does not represent the most efficient (or cost effective) approach to scaling. The problem here is one of habit. As teams scale up, do they change those habits, or do individuals continue racking up credit card bills rather than planning ahead?
To be fair to the cloud providers, many are now more sensitive to customers hugely overpaying for services than previously. This is not a result of altruism but rather a realisation that the loss of an unhappy customer who goes elsewhere is far more costly compared to the short-term bump in profitability they get from that overpayment. However, most companies don’t even realise that they are overpaying, because costs are not looked at holistically. They don’t even realise that they could take fairly easy steps to dramatically reduce their cloud costs.
An entire industry has grown up around cloud spend and billing levels, applying consulting skills to managing cloud instances. The typical approach here is to look at the cloud service again. In the market, you can see new launches that are badged as ‘on-demand’ or serverless, and you are told you will only ever pay for what you use.
Similarly, cost optimisation services are also being launched, offering clever things around the storage service levels that you use, with the intention of reducing your infrastructure costs. This can only take you so far if you don’t properly optimise your data. In this case it is your database itself which would need to be examined, as you alone are responsible for ensuring it is working efficiently.
Why is this a problem?
A16z has pointed out that companies could be getting better results themselves rather than potentially overspending on cloud. Secondly, data is pitched as the lifeblood of companies, the source of differentiation, the new oil, and any number of other business cliches. So why - when data is so important, and potentially so expensive - are we not doing a better job of managing this as an asset? Why are tools like databases considered to be not worth the effort and why are people unwilling to try and understand what is going on inside them?
One big reason is that developers believe their cloud providers. When services are offered under terms like “fully managed services” or claims that no DBA is required to operate them, this appeals to time-poor developers who just want to get up and running quickly. When the service works for those initial projects, they commit long-term. When they are then told that the cost of running the service is going up, they don’t object. The fact is that when things are easy and they work, it’s simple to assume that this is how it is supposed to run.
But, that is not actually the case over time. While a database implementation might be suitable at the start, the application that this database supports will change over time too. More fields, more data, and potentially additions like more schema to support all has an impact on performance and on cost.
It’s a nice fantasy that one size fits all, but in reality huge improvements can be made if you have someone who understands how databases operate, particularly at scale. If you don’t have that expertise internally, look at bringing in outside consultants to help.
Another reason is how easy it is to add more instances and servers as fast as you need. This flexibility is great, but the issue often is that people add those instances and never remove them. For example, lots of recent data leaks were caused by someone spinning up some instances to test something and simply leaving them running without the security oversight that the production implementation got.
Managing costs in the cloud: Understanding your DBaaS options
The final big reason to optimise your databases is less to do with the cloud providers and more about the database providers. There are now dozens of smaller ‘as a service’ options for databases of all shapes, sizes and popularity levels. This is because developers often prefer to buy a service rather than run their own instances and then buy support. This is good for the cloud provider, but less so for the open source project and the company set up to monetise that project. When you have shareholders or venture capital backers, you have to scale up and produce profit for them to be happy. And so, if you can’t beat the cloud, you may need to join it.
The consumption model is currently far more successful from a business perspective than a pure support model in the open source software space. If you buy a support license, you may run your implementation on a huge server, you may virtualise it or run it in the cloud. You have choices. When you buy a database as a service product, you may think that you are supporting the open source community, and you may think what you are getting is open source too, but this is often not the case.
Shareholders and investors are keen to see revenues going up and to the right. MongoDB, for instance, previously changed their server licensing to charge based on memory, to try and capture the market falling off. Following this, the company switched focus to its Atlas cloud service, which has been a huge source of growth. The combination of cloud and as a service models gives vendors like Elastic, MongoDB and others the opportunity to charge for what is really being used.
This model is proving to be successful, and this leads companies to reserve features and tooling for only their cloud users in an effort to drive more people to the cloud and away from a DIY setup, Additionally, it does get confusing when cloud providers offer these "open source" services, but the features are nowhere to be found in the open source repositories or available to run outside a paid-only relationship.
The success of pay-as-you-go cloud services is good and bad for open source. If you tune your systems and keep them optimised, then spending on just what you need is great. However, you have to put in the work to understand this and take responsibility for how things run.
You are responsible over time for your database, even in the cloud, and as your company changes its approach or grows its install base, you should re-evaluate whether you have the right approach now, and for the upcoming years. What suited a nippy challenger brand doesn't work for a market leader with global operations and millions of customers.
The report from A16z demonstrates how much value is delivered by cloud services, particularly as companies develop and grow. However, that value will change over time based on different circumstances. Keeping up with company and database changes is essential. This means being aware, if the time comes, of how you can take back services. For this to succeed, you have to understand the impact of your choices, where there might be lock-in, and where you can balance the speed that cloud services offer in the short-term against long-term cost savings and improvements in performance that you can drive.
