There is plenty of cloud cost management software, dozens of cloud cost optimization scenarios and strategies but practically all of them have a serious issue that limits the result of saving.
The main idea of traditional cloud cost management tools is to scan your cloud billing and discover existing resources to give you a recipe of what needs to be done to save on
your cloud bill. The main focus is on:
- unused resources (volumes, AMIs, snapshots, elastic IPs etc.)
- issues with rightsizing – when the wrong flavor is selected and, in the majority of the cases, downsize can be applied
- reserved instances and saving plan recommendations
And that is a really nice report with a nice and appealing number of X dollars possible savings. But the problem is who the user of this data is. Usually, there are one or two IT guys responsible for cloud cost saving. They can take SRE, CloudOps, DevOps or Central IT positions, in different companies they have different titles. And they can definitely purchase more reserved capacity or saving plans but when it comes to unused resources or rightsizing, they can’t just go and apply recommendations, they have to interact with the resource owners. And this interaction kills the majority of the cost saving potential as those one or two guys have to talk to engineers and SREs, make them review the resources, explain their goals.
Engineers want to write code and close Jira tickets. They don’t go to cloud consoles, forget to clean up resources and don’t care about costs. And now they need to change flavors taking risks that some jobs will fail with out of memory, review some old resources. It’s obvious that they will do their best to postpone such tasks and avoid discussions. As a result, usually, companies can save only 20–30% of that nice possible savings amount, IT guys will do their best to avoid the next round of communication with engineers and a company just accepts that they cannot save more.
How can it be improved? Only by engaging engineers in the process. Yes, we remember that they don’t care about costs and don’t want to take new responsibilities but engineers need to have only one simple task: to be responsible for their own resources and their lifecycle and a company’s task is to give them instruments to make the process simple and non-intrusive.
In the ideal case companies should use tools that:
- give a way to set and update TTLs, notifications about expiration. Setting tags and running a script to send emails can be an option
- give engineers a way to track their resources, get alerts, update TTLs via Slack or Microsoft Teams
give personalized recommendations about engineer’s resources so he or she doesn’t need to interact with IT guys - give managers and budget owners a way to track progress and results to make corrective actions if necessary
- educate engineers and managers and simplify their usage of the instruments and
explain the business need of such actions
As a result, it gives not just one or two iterations of cloud cost optimization but builds a simple but invaluable process where R&D team that generates a significant chunk of cloud expenses helps to save and engineers don’t feel they have another annoying task, just to take care about their resources.
As with the majority of things in IT, the best principles and standards are only as good as how well they are followed by the whole team. The limiting factor and risks, more often than not, aren’t the effect that modern technologies offer, but the people and processes involved. The intersection of an engineering team comes into play when it gets to FinOps adoption and cost optimization. So if you are eager to be aware of the cost of deploying resources and how to architect for cost optimization, you definitely need to actively involve your engineering team in FinOps and cloud cost savings.
Today when a lot of companies rely on an OpEx environment, an engineering team feels a lot of freedom and can effortlessly spin up resources as desired to run their services. It is recognized that for many cloud users, it’s often a challenge – where engineering spins up resources without standardized guidelines such as setting up budgets, TTL, alerts and notifications, appropriate resource tagging and frequent cadence – to view cost from an engineering and finance perspective. Although this ‘freedom’ empowers velocity and better product development, it’s not the optimal way to build an R&D process.
Involving engineers as owners of the majority of resources is a critical issue in order to define budgets, keep cloud costs under control and forecast expenses correctly. Every team member can help build an effective cloud usage experience and manage cloud costs.
Our product, OptScale, assists companies in engaging engineers in cloud cost management via Slack – regular reports, alerts and commands to manage resource lifecycle.
To put theory into practice, you can have a free trial, no credit card needed → https://my.optscale.com/register
