Duas alavancas, não uma
Todo o custo cloud é, no fundo, utilização vezes tarifa. Para o baixar há dois caminhos:
- Reduzir a utilização: consumir menos para fazer o mesmo.
- Reduzir a tarifa: pagar menos por cada unidade consumida, normalmente comprometendo consumo em troca de desconto.
As duas são legítimas. O problema é a ordem.
Primeiro a utilização, depois a tarifa
- Eliminar o que não se usa. Recursos órfãos, ambientes esquecidos, discos e cópias que ninguém consulta. É a poupança mais rápida e não tem risco para o negócio.
- Ajustar o tamanho. Recursos dimensionados para um pico que não chega. Ajustam-se com dados de utilização real de várias semanas, não com uma fotografia de um dia.
- Programar o arranque. Ambientes de desenvolvimento e testes que não precisam de funcionar à noite nem ao fim de semana.
- Comprometer a utilização estável. Só depois dos três passos anteriores: com o consumo já limpo, compromete-se a base que se sabe estável a uma tarifa melhor (planos de poupança, reservas, descontos por utilização comprometida).
Porque é que a ordem importa
Se se comprometer primeiro, compra-se desconto sobre um consumo inflacionado. Depois, ao limpar e ajustar, a utilização desce abaixo do comprometido e acaba-se a pagar por capacidade que já não se usa. O compromisso que devia poupar transforma-se num custo fixo que dura um ou três anos.
Ao contrário, com a utilização já otimizada, o compromisso cobre apenas o que é realmente estável e o desconto é aproveitado por inteiro.
Como decidir o que mexer
- Ordenar por impacto e esforço. Muitas oportunidades pequenas e automatizáveis costumam somar mais do que uma grande em que ninguém se atreve a mexer.
- Medir o compromisso: que percentagem do consumo elegível está coberta e quanto do compromisso é realmente usado. Os dois números devem ser revistos todos os meses.
- Registar cada decisão: o que se mudou, quanto se esperava poupar e quanto se poupou. Sem isso, a otimização não deixa aprendizagem.
Otimizar uma vez é fácil. Mantê-lo otimizado exige responsáveis e um ritmo de revisão, que é o que se vê no próximo artigo.
Como o aplicamos: Engenharia FinOps.