How would you approach optimising your cloud spend?
For most organisations, the answer is simple: rightsizing.
A feature of the transition to cloud architecture has been that many businesses have gone overboard when provisioning for capacity. For example, using an extra-large AWS EC2 instance when a medium-sized instance would meet demand. As I discussed in an earlier post, the root of this problem is simply that many organisations misunderstand the importance of accurate planning for peaks and troughs in demand.
So, it makes complete sense that your first step in optimising your cloud costs should be to scale back on all the capacity you don’t need. There are plenty of tools available to help businesses identify where they’re overspending – such as AWS Cloudability and Cloudyn – making it a relatively simple task, provided you carry out up and downstream risk assessments.
And it will likely be effective, at least in part.
But here’s the kicker. In our experience, the real cloud cost-savings are to be found in engineering your applications for cost-efficiency. In fact, we’ve found that building efficiency into apps can deliver up to four times the savings typically gained from rightsizing.
This poses two obvious questions. Firstly, why? And secondly, if that’s the case then why are companies not writing efficiency into apps from the off?
To tackle the ‘why’ first. Most apps have been written in such a way that they consume more cloud resource – such as CPU usage, memory, and network performance – than they ought to.
It’s completely understandable; most development teams have very little incentive to write efficiency into the code. It’s never previously been part of their remit, and, as a result, there isn’t usually any penalty or accountability attached to it. Besides, if you’re a developer working on building a product, why would you even consider it? Cloud capacity is limitless, and, if an app requires more, you simply use some.
So why aren’t businesses doing more to ensure dev teams are aware of this and view it as part of their role?
Well, partly because many organisations simply aren’t aware of the problem themselves. But, it’s also down to it being very difficult to backtrack and re-engineer apps once they’re in production. This is largely due to the nature of dev teams’ role within organisations.
Often at the bleeding edge of a company’s advancement, dev teams are in high-demand and under pressure to move onto something new once a project is completed. There’s always a new release that needed to go out yesterday or a new product to build. So, going back to address technical debt in existing software isn’t an easy sell – even if it’s likely to be worthwhile in the long run.
What’s more, even if dev teams can get executive-level buy-in for tackling inefficiencies in live software, the fact remains that it’s very difficult. Peeling back all the layers of an app to find where the inefficiencies lie in the code is time-consuming and tricky. This is borne out by research from IBM and others which suggests that returning to existing apps to rewrite the code that leads to cost inefficiencies is considerably harder than building for the problem from the beginning.
How then do businesses make sure that software is built with cloud costs in mind?
We suggest adopting a framework to plan for it. We include cost-efficiency as the third pillar in our Seven Pillars of Software Performance, as do AWS in their 5 Pillars of a Well-architected Framework. The problem, as we’ve already covered, is that many businesses don’t move beyond the first element of our performance framework, which is throughput and response time.
It’s not a simple fix, but it requires a mentality shift in the way dev departments plan and write software to change this. The real issue lies in it being very hard for IT leaders to incentivise this behaviour. We often come across organisations in which Development has zero accountability for cloud budgets.
But there is a route around this. The basic principles of DevOps – in which coders are directly responsible for the performance of the apps they develop – are well-suited to tackling the problem. You could quite easily build in a cost-efficiency element to DevOps by implementing KPIs around it and making it a non-functional requirement of all software development processes.
At present, there are very few dev teams adopting this model – although, a few of our clients have and are seeing real success. Nevertheless, the model is there and will only become more effective as more teams utilise it and iron out the creases.
It’s worth asking yourself: can your business really afford not to?
