O requisito que aparece na fatura
As revisões de arquitetura costumam ver se o desenho é seguro, se escala e se se pode operar. O custo aparece depois, na primeira fatura, quando mudar o desenho já é caro. Aí a conversa já não é de arquitetura, mas de cortes.
Tratar o custo como requisito significa que uma arquitetura não está concluída enquanto não tiver uma estimativa de quanto custará operá-la, por componente e com os seus pressupostos escritos.
Estimar por componente
Uma estimativa útil não é um valor total, mas uma tabela:
- Cada componente com o seu custo mensal estimado.
- Os pressupostos que o determinam: tamanho, horas de utilização, volume de dados, região, tráfego de saída.
- Como cresce com a utilização: que componentes escalam com os utilizadores e quais são fixos.
- O que se pouparia com compromissos de utilização, quando o consumo estabilizar.
Os pressupostos são tão importantes como os números: quando a fatura real se desviar, mostrarão exatamente o que mudou.
Porque é que corrigir tarde sai caro
Mudar uma decisão de arquitetura custa pouco no quadro branco e muito em produção. Escolher mal o tipo de base de dados corrige-se em minutos durante o desenho; em produção exige migração, janela de corte e risco. O mesmo acontece com a região, o modelo de rede ou a repartição de serviços.
Por isso, a estimativa de custo vai dentro do desenho, junto a cada registo de decisão, e não num relatório posterior.
Como encaixa no FinOps
A estimativa de desenho é o orçamento inicial. Quando o sistema entra em produção, o pipeline de custos mede o gasto real, atribui-o a cada componente e compara-o com a estimativa. A diferença entre o estimado e o real é o sinal de que algo no desenho ou na utilização mudou, e a sua explicação transforma-se no registo de decisão seguinte.
Relacionado: Orçamento e previsão (série FinOps). Como o aplicamos: Arquitetura Cloud.