There is plenty of cloud cost management software, dozens of otimização de custos de nuvem 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.
No caso ideal, as empresas devem utilizar ferramentas que:
- dar uma maneira de definir e atualizar TTLs, notificações sobre expiração. Definir tags e executar um script para enviar e-mails pode ser uma opção
- dê aos engenheiros uma maneira de rastrear seus recursos, receber alertas e atualizar TTLs via Slack ou Microsoft Teams
dar recomendações personalizadas sobre os recursos do engenheiro para que ele ou ela não precise interagir com os profissionais de TI - dar aos gerentes e proprietários de orçamento uma maneira de monitorar o progresso e os resultados para tomar ações corretivas, se necessário
- educar engenheiros e gestores e simplificar o uso dos instrumentos e
explicar a necessidade comercial de tais ações
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.
Para colocar a teoria em prática, você pode fazer um teste gratuito, sem precisar de cartão de crédito → https://my.optscale.com/register
