Logby

FinOps na Prática: Como Desenvolvedores Podem Ajudar a Controlar o Custo da Nuvem

Por Tiago

Se você trabalha com desenvolvimento de software há alguns anos, provavelmente já ouviu falar de FinOps. Mas é bem provável também que você tenha associado o termo a planilhas, dashboards de custo e reuniões chatas entre financeiro e infraestrutura — algo distante do seu dia a dia como programador. A boa notícia (ou má, dependendo do ponto de vista) é que isso está mudando rápido: cada vez mais empresas percebem que o custo da nuvem nasce no código, e quem escreve esse código tem um papel central em mantê-lo sob controle.

Neste post, vamos sair da teoria de frameworks e certificações e falar de FinOps de um jeito prático: o que você, como desenvolvedor .NET (ou de qualquer stack), pode fazer hoje para escrever software mais barato de operar, sem virar um especialista em contratos de nuvem.

O que é FinOps, sem o jargão corporativo

FinOps é basicamente a junção de "Finanças" com "Operações" (o mesmo espírito do DevOps, só que aplicado a dinheiro). A ideia central é simples: em vez de o time financeiro receber a fatura da nuvem no fim do mês e sofrer em silêncio, todo mundo que decide como os recursos são usados — incluindo devs — passa a ter visibilidade e responsabilidade sobre esse custo.

Isso muda a relação com a nuvem. Ela deixa de ser um recurso "infinito e barato" e passa a ser tratada como qualquer outro insumo de engenharia: tem limite, tem trade-off, e vale a pena otimizar.

Por que isso importa para quem escreve código

Muita gente pensa que custo de nuvem é problema de arquitetura ou de DevOps. Só que boa parte das decisões que impactam a fatura são tomadas linha a linha, no código:

  • Uma query sem índice que faz table scan em um banco gerenciado caro.
  • Um loop que faz N chamadas HTTP quando uma chamada em lote resolveria.
  • Um serviço rodando 24/7 quando poderia ser serverless.
  • Logs excessivos sendo enviados para uma ferramenta de observabilidade cobrada por volume.

Nenhum desses problemas aparece em uma reunião de FinOps tradicional — eles aparecem no pull request. E é aí que entra o papel prático do desenvolvedor.

Práticas que você pode adotar já na próxima sprint

1. Trate custo como um requisito não funcional

Assim como você pensa em performance, segurança e escalabilidade, custo deveria entrar na lista de critérios de aceite de uma feature. Antes de subir um novo serviço, pergunte: "isso vai escalar sozinho quando não tiver tráfego?", "esse recurso fica ocioso à noite?".

2. Prefira consumo sob demanda quando fizer sentido

No ecossistema .NET, isso costuma significar escolher Azure Functions no plano de Consumo em vez de um App Service dedicado rodando o tempo todo, especialmente para cargas de trabalho esporádicas ou orientadas a eventos. O mesmo raciocínio vale para containers: um job em Azure Container Apps ou AWS Fargate que escala a zero é bem mais barato do que uma VM ligada 24h esperando trabalho.

3. Cuide do "right-sizing"

É comum um serviço nascer em uma SKU generosa "só para garantir" e nunca mais ser revisado. Vale revisitar periodicamente:

  • O tamanho da instância de banco de dados realmente condiz com a carga atual?
  • O plano do App Service está superdimensionado para o tráfego real?
  • As réplicas do Kubernetes estão configuradas com HPA (Horizontal Pod Autoscaler) ou ficam fixas em um número alto "por segurança"?

4. Otimize antes de escalar

Escalar horizontalmente é fácil, mas caro se a causa raiz é ineficiência de código. Antes de aumentar réplicas ou subir a instância, vale investigar:

// Antes: N+1 queries, uma chamada ao banco por item
foreach (var pedido in pedidos)
{
    var cliente = await _dbContext.Clientes
        .FirstOrDefaultAsync(c => c.Id == pedido.ClienteId);
}

// Depois: uma única consulta com Include
var pedidosComCliente = await _dbContext.Pedidos
    .Include(p => p.Cliente)
    .ToListAsync();

Esse tipo de ajuste reduz carga no banco, tempo de resposta e, indiretamente, a necessidade de escalar recursos — ou seja, custo.

5. Cache é FinOps disfarçado

Cada chamada evitada a um banco de dados gerenciado, a uma API paga por requisição, ou a um serviço de IA cobrado por token é dinheiro economizado. Introduzir uma camada de cache (em memória, Redis, ou até cache de resposta HTTP) costuma ser uma das otimizações de custo com melhor relação esforço/retorno.

6. Preste atenção em observabilidade

Ironicamente, ferramentas de monitoramento e logging podem se tornar uma das maiores linhas de custo se não forem configuradas com critério. Vale revisar:

  • Taxas de amostragem (sampling) no Application Insights ou OpenTelemetry.
  • Retenção de logs — nem tudo precisa ficar guardado por 90 dias.
  • Métricas customizadas em excesso, geradas "só para garantir".

7. Marque (tag) tudo que você provisiona

Recursos sem tags de time, projeto ou ambiente são o pesadelo de qualquer análise de custo. Se você provisiona infraestrutura via Terraform, Bicep ou Pulumi, inclua tags obrigatórias desde o template inicial. Isso não economiza dinheiro diretamente, mas é o que permite que alguém — você mesmo, no futuro — descubra de onde vem cada centavo da fatura.

Construindo o hábito, não só a técnica

Nenhuma dessas práticas exige aprovação de orçamento ou um projeto formal de FinOps. Elas cabem em revisões de código, em decisões de design e em conversas de arquitetura que já acontecem no dia a dia. O ponto principal é cultural: encarar custo de nuvem como parte da qualidade do software, no mesmo patamar de performance e confiabilidade.

Um bom teste prático é incluir, nas descrições de pull request de mudanças de infraestrutura, uma linha simples: "impacto estimado de custo: nenhum / redução / aumento". Isso já cria o hábito de pensar sobre o assunto antes de o código ir para produção — o momento mais barato para corrigir qualquer problema, inclusive o financeiro.

Conclusão

FinOps não precisa ser um processo pesado imposto de cima para baixo. Na prática, muitas das melhores otimizações de custo em nuvem nascem de decisões simples de engenharia: uma query mais eficiente, um serviço que escala a zero, um cache bem posicionado, uma tag adicionada no lugar certo. Como desenvolvedor, você já tem as ferramentas e o contexto técnico para fazer essas escolhas — falta só incorporar o custo como mais uma lente de qualidade no seu trabalho diário. O resultado costuma ser duplo: sistemas mais eficientes tecnicamente e faturas de nuvem que fazem sentido no fim do mês.