Ed Wantuil

Posted on Jan 12

Cloud Sem Falência: O mínimo que você precisa saber de FinOps

#devops #cloud #braziliandevs

Imagine a cena: você trabalha em uma empresa consolidada. Vocês têm aquele rack de servidores físicos robusto, piscando luzinhas em uma sala gelada, com piso elevado e controle biométrico (o famoso On-Premise). Tudo funciona. O banco de dados aguenta o tranco, a latência é zero na rede local. Mas a diretoria decide que é hora de "modernizar".

"Vamos migrar para a Nuvem!", dizem eles, com os olhos brilhando.

A promessa no PowerPoint é sedutora: flexibilidade infinita, segurança gerenciada e o mantra mágico: "pagar só pelo que usar". A migração acontece via Lift-and-Shift (pegar o que existe e jogar na nuvem sem refatorar). A equipe de Infra e Dev comemoram. O Deploy é um sucesso.

Três meses depois, chega a fatura da AWS.

O diretor financeiro (CFO) não apenas cai da cadeira; ele convoca uma reunião de emergência. O custo, que antes era uma linha fixa e previsível no balanço anual, triplicou e agora flutua violentamente.

O que deu errado? Simples: A engenharia tratou a Nuvem como um Data Center físico, apenas alugado.

Hoje, vamos falar sobre os riscos dessa mudança e como aplicar FinOps não como burocracia, mas como requisito de arquitetura.

(Nota: Usaremos a AWS nos exemplos por ser a stack padrão de mercado, mas a lógica se aplica integralmente ao Azure, GCP e OCI).

🦄 A Ilusão da Mágica: CAPEX vs. OPEX na Engenharia

Para entender a conta da AWS, você precisa entender como o dinheiro sai do cofre da empresa. A mudança da nuvem não é apenas sobre onde o servidor roda, é sobre quem assume o risco do desperdício.

1. CAPEX (Capital Expenditure): A Lógica do "PC Gamer"

CAPEX é Despesa de Capital. É comprar a "caixa". Imagine que você vai montar um PC Gamer High-End. Você gasta R$ 20.000,00 na loja. Doeu no bolso na hora, certo? Mas depois que o PC está na sua mesa:

Custo Marginal Zero: Se você jogar Paciência ou renderizar um vídeo em 8K a noite toda, não faz diferença financeira para o seu bolso (tirando a conta de luz, que é irrisória perto do hardware). O dinheiro já foi gasto (Sunk Cost).
O Comportamento do Engenheiro (On-Premise): Como o processo de compra é lento (meses de cotação e aprovação), você tem medo de faltar recurso.
- Mentalidade: "Vou pedir um servidor com 64 Cores, mesmo precisando de 16. Se sobrar, melhor. O hardware é nosso mesmo."
- Código: Eficiência não é prioridade financeira. Um código mal otimizado que consome 90% da CPU não gera uma fatura extra no fim do mês.

2. OPEX (Operational Expenditure): A Lógica do Uber

OPEX é Despesa Operacional. É o custo de funcionamento do dia a dia. Na nuvem, você não comprou o carro; você está rodando de Uber 24 horas por dia.

Custo Marginal Real: Cada minuto parado no sinal custa dinheiro. Cada desvio de rota custa dinheiro.
O Comportamento do Engenheiro (Cloud): Aqui, a ineficiência é taxada instantaneamente.
- Mentalidade: Aquele servidor de 64 cores e 512GB de ram parado esperando tráfego é como deixar o Uber te esperando na porta do escritório enquanto você trabalha. O taxímetro está rodando.
- Código: Um loop infinito ou uma query sem índice no banco de dados não deixa apenas o sistema lento; ele queima dinheiro vivo.

Comparativo para Desenvolvedores (Salve isso)

Feature	CAPEX (On-Premise / Hardware Próprio)	OPEX (Cloud / AWS / Azure)
Commit Financeiro	Você paga tudo antes de usar (Upfront).	Você paga depois de usar (Pay-as-you-go).
Latência de Aprovação	Alta. Precisa de reuniões, assinaturas e compras.	Zero. Um `terraform apply` gasta dinheiro instantaneamente.
Risco de Capacidade	Subutilização. Comprar um servidor monstro e usar 10%.	Conta Surpresa. Esquecer algo ligado ou escalar infinitamente.
Otimização de Código	Melhora performance, mas não reduz a fatura do hardware.	Reduz diretamente a fatura. Código limpo = Dinheiro no caixa.

Por que isso afeta a sua Arquitetura?

Se você desenha uma arquitetura pensando em CAPEX (Mundo Físico) e a implementa em OPEX (Nuvem), você cria um desastre financeiro.

No CAPEX, a estratégia de defesa é: "Superdimensionar para garantir estabilidade". (Compre o maior servidor possível).
No OPEX, a estratégia de defesa é: "Elasticidade". (Comece com o menor servidor possível e configure para crescer sozinho apenas se necessário).

💸 Os 8 Cavaleiros do Apocalipse Financeiro na AWS

Na nuvem, os maiores vilões raramente são tecnologias complexas de IA ou Big Data. Quase sempre são decisões arquiteturais preguiçosas e falta de governança.

1. Instâncias "Just in Case": O Custo do Seguro Psicológico

O sobredimensionamento é um vício comum: o desenvolvedor sobe uma instância m5.2xlarge (8 vCPUs, 32GB RAM) não porque a aplicação exige, mas porque ele "não quer ter dor de cabeça". É o provisionamento baseado no medo, criando uma margem de segurança gigantesca e cara para evitar qualquer risco hipotético de lentidão.

A realidade nua e crua aparece no CloudWatch: na maior parte do tempo, essa supermáquina opera com apenas 12% de CPU e usa uma fração da memória. Pagar por uma 2xlarge para rodar essa carga é como fretar um ônibus de 50 lugares para levar apenas 4 pessoas ao trabalho todos os dias. Você está pagando pelo "espaço vazio" e pelo motor potente do ônibus, enquanto um carro popular (t3.medium) faria o mesmo trajeto com o mesmo conforto e muito mais economia.

2. Ambientes Zumbis: A Torneira Aberta Fora do Expediente

"Ambientes Zumbis" são servidores de Desenvolvimento e Homologação que operam como cópias fiéis da Produção, mas sem a audiência dela. Eles permanecem ligados e faturando às 3 da manhã de um domingo, consumindo recursos de nuvem para processar absolutamente nada. Manter esses servidores ligados 24/7 é o equivalente digital de deixar o ar-condicionado de um escritório ligado no máximo durante todo o fim de semana, com o prédio completamente vazio.

O impacto financeiro atua como um multiplicador de desperdício. Se você mantém três ambientes (Dev, Staging e Produção) com arquiteturas similares ligados ininterruptamente, seu custo base é 300% do necessário. A matemática é cruel: uma semana tem 168 horas, mas seus desenvolvedores trabalham apenas 40. Você está pagando por 128 horas de ociosidade pura por máquina, todas as semanas.

A primeira cura para esse desperdício é o agendamento automático. Utilizando soluções como o AWS Instance Scheduler (ou Lambdas simples), configuramos os ambientes para "acordar" às 08:00 e "dormir" às 20:00, de segunda a sexta-feira. Apenas essa automação básica, sem alterar uma linha de código da aplicação, reduz a fatura desses ambientes não-produtivos em cerca de 70%.

3. O Esquecimento Crônico: O Custo do Limbo

Um dos "pegadinhas" mais comuns da nuvem acontece no momento de desligar as luzes: quando você termina uma instância EC2, o senso comum diz que a cobrança para. O erro está em assumir que a máquina e o disco são uma peça única. Por padrão, ao "matar" o servidor, o volume de armazenamento (EBS) acoplado a ele muitas vezes sobrevive, entrando num estado de limbo financeiro.

O resultado é o acúmulo de EBS Órfãos: centenas de discos no estado "Available" (não atrelados a ninguém), cheios de dados inúteis ou completamente vazios, pelos quais você paga o preço cheio do gigabyte provisionado. É comparável a vender seu carro, mas esquecer de cancelar o aluguel da vaga de garagem: o veículo não existe mais, mas a cobrança pelo espaço que ele ocupava continua chegando todo mês na fatura.

A situação piora com os Elastic IPs (EIPs), que possuem uma lógica de cobrança invertida e punitiva. Devido à escassez mundial de endereços IPv4, a AWS não cobra pelo IP enquanto você o utiliza, mas começa a cobrar assim que ele fica ocioso. É como uma "multa por não uso": se você reserva um endereço IP e não o atrela a uma instância em execução, você paga por estar "segurando" um recurso escasso sem necessidade.

4. O Cemitério de Dados no S3

Buckets S3 tendem a virar "cemitérios digitais" onde logs, backups e assets se acumulam indefinidamente. O erro crucial não é guardar os dados, mas a falta de estratégia: manter 100% desse volume na classe S3 Standard, pagando a tarifa mais alta da AWS por arquivos que ninguém acessa há meses.

Para entender o prejuízo, imagine o S3 Standard como uma loja no corredor principal de um shopping: o aluguel é caríssimo porque o acesso é imediato e fácil (baixa latência). Manter logs de 2022 nessa classe é como alugar essa vitrine premium apenas para estocar caixas de papelão velhas. Dados "frios", que raramente são consultados, não precisam estar à mão em milissegundos; eles podem ficar num armazém mais distante e barato.

A solução é o S3 Lifecycle, que automatiza a logística desse "estoque". Primeiro, ele atua na Transição: move automaticamente os dados que envelhecem da "vitrine" (Standard) para o "armazém" (S3 Glacier). No Glacier, você paga uma fração do preço, aceitando que o resgate do arquivo leve alguns minutos ou horas (maior latência), o que é aceitável para arquivos de auditoria ou backups antigos.

Por fim, o Lifecycle resolve o acúmulo de lixo através da Expiração. Além de mover dados, você configura regras para deletar objetos definitivamente após um período, como remover logs temporários após 7 dias. Isso garante a higiene do ambiente, impedindo que você pague aluguel (seja no shopping ou no armazém) por dados inúteis que não deveriam mais existir.

5. Snapshots: O Colecionador de Backups Fantasmas

Backups são a apólice de seguro da sua infraestrutura, mas a facilidade de criar snapshots na AWS gera um comportamento perigoso de acumulação. O erro clássico é configurar uma automação de snapshot diário e definir a retenção para "nunca" ou prazos absurdos como 5 anos. Embora os snapshots sejam incrementais (salvando apenas o que mudou), em bancos de dados transacionais com muita escrita, o volume de dados alterados cresce rápido, e a fatura acompanha.
Para visualizar o desperdício, imagine que você compra o jornal do dia para ler as notícias. É útil ter os jornais da última semana na mesa para referência rápida. Mas guardar uma pilha de jornais diários de três anos atrás na sua sala ocupa espaço valioso e custa dinheiro, sendo que a chance de você precisar saber a "cotação do dólar numa terça-feira específica de 2021" é praticamente nula. Você está pagando armazenamento premium por "jornais velhos" que não têm valor de negócio.

6. Licenciamento Comercial (O Custo Invisível)

Muitas empresas focam tanto em otimizar CPU e RAM que esquecem o elefante na sala: o custo de software. Ao rodar instâncias com Windows Server ou SQL Server Enterprise na AWS no modelo "License Included", você não paga apenas pela infraestrutura; você paga uma sobretaxa pesada pelo direito de uso do software proprietário. Esse custo é embutido na tarifa por hora e, em máquinas grandes, a licença pode custar mais caro que o próprio hardware.
Para ilustrar a desproporção, usar o SQL Server Enterprise para uma aplicação que não utiliza funcionalidades avançadas (como Always On complexo ou compressão de dados específica) é como fretar um jato executivo apenas para ir comprar pão na padaria. O objetivo (armazenar e recuperar dados) é cumprido, mas você está pagando por um veículo de luxo quando uma bicicleta ou um Uber resolveria o problema com a mesma eficiência e uma fração do custo.

A primeira camada de solução é a Otimização de Edição. É comum desenvolvedores solicitarem a versão Enterprise por "garantia" ou hábito, sem necessidade técnica real. Uma auditoria simples muitas vezes revela que a versão Standardatende a todos os requisitos da aplicação. Fazer esse downgrade reduz a fatura de licenciamento imediatamente, sem exigir mudanças drásticas na arquitetura ou no código.

7. Dilema Geográfico: Reduzindo a Fatura pela Metade

Hospedar aplicações na região sa-east-1 (São Paulo) carrega um ágio pesado: o "Custo Brasil" digital faz com que a infraestrutura local custe, cerca de 50% a mais do que na us-east-1 (N. Virgínia). Migrar workloads para os EUA é, frequentemente, a manobra de FinOps com maior retorno imediato (ROI): você corta a fatura desses recursos praticamente pela metade apenas alterando o CEP do servidor, acessando o mesmo hardware por uma fração do preço.

O principal bloqueador costuma ser o medo da LGPD, mas a crença de que a lei exige residência física dos dados no Brasil é um mito. O Artigo 33 permite a transferência internacional para países com proteção adequada (como os EUA), desde que coberto por contratos padrão. A legislação foca na segurança e privacidade do dado, não na sua latitude e longitude geográfica.

Quanto à técnica, a latência para a Virgínia (~120ms) é imperceptível para a maioria das aplicações web, sistemas internos e dashboards. A estratégia inteligente é adotar uma região como US East como padrão para maximizar a economia, reservando São Paulo apenas para exceções que realmente exigem resposta em tempo real (como High Frequency Trading), evitando pagar preço de "primeira classe" para cargas de trabalho que rodariam perfeitamente na econômica.

8. Serverless: A Faca de Dois Gumes

"Serverless" é computação sem gestão de infraestrutura (como AWS Lambda ou DynamoDB). Diferente de alugar um servidor fixo mensal, aqui você paga apenas pelos milissegundos que seu código executa ou pelo dado que você lê. É como a conta de luz: você só paga se o interruptor estiver ligado.

A Estratégia: Para uso esporádico, é imbatível. Mas e para uso constante? Também pode ser uma excelente escolha! Embora a fatura de infraestrutura possa vir mais alta do que em servidores tradicionais, você elimina o trabalho pesado de manutenção. Muitas vezes, é financeiramente mais inteligente pagar um pouco mais para a AWS do que custear horas de engenharia ou contratar uma equipe dedicada apenas para gerenciar servidores, aplicar patches de segurança e configurar escalas. O segredo é olhar para o Custo Total (TCO), e não apenas para a linha de processamento na fatura.

🕵️‍♂️ FinOps: Engenharia Financeira na Prática

FinOps não é apenas sobre "pedir desconto" ou cortar gastos; é a mudança cultural que descentraliza a responsabilidade do custo, empoderando engenheiros a tomar decisões baseadas em dados, não em palpites. Para que essa cultura saia do papel, ela precisa se apoiar em um tripé de governança robusto: a visibilidade granular garantida pelo tageamento correto (saber quem gasta), a segurança operacional monitorada pelo AWS Budgets (saber quando gasta) e a eficiência financeira obtida através dos Modelos de Compra inteligentes (saber como pagar). Sem integrar essas três frentes, a nuvem deixa de ser um acelerador de inovação para se tornar um passivo financeiro descontrolado.

1. TAGs: Sem Etiquetas, Sem Dados 🏷️

No AWS Cost Explorer, uma infraestrutura sem tags opera como uma "caixa preta" financeira: você encara uma fatura de $50.000, mas é incapaz de discernir se o rombo veio de um modelo crítico de Data Science ou de um cluster Kubernetes esquecido por um estagiário.
Utiliza tags como custo:centro, app:nome, env e dono no momento dos recursos transformara números genéricos em rastreáveis, permitindo que cada centavo gasto tenha um responsável atrelado, eliminando definitivamente a cultura de que "o custo da nuvem não é problema meu".

2. AWS Budgets e Detecção de Anomalias 🚨

Não espere o fim do mês. Configure o AWS Budgets para alertar quando o custo projetado (forecasted) ultrapassar o limite.

Dica: Ative o Cost Anomaly Detection. Ele usa Machine Learning para identificar picos anormais.
- Exemplo: Um deploy errado fez a cahamada para um Lambda entrar em loop infinito. O Anomaly Detection te avisa em horas, não no fim do mês.

3. Modelos de Compra: O Fim do On-Demand 💸

Operar 100% em On-Demand é pagar voluntariamente um "imposto sobre a falta de planejamento". A maturidade em FinOps exige abandonar o preço de varejo e adotar um mix estratégico: cubra sua carga de trabalho base (aquela que roda 24/7) com Savings Plans, que oferecem descontos de até 72% em troca de fidelidade, e mova cargas tolerantes a interrupções, como processamento de dados e pipelines de CI/CD, para Spot Instances, aproveitando a capacidade ociosa da AWS por até 10% do valor original.

Ignorar essa estratégia e manter tudo no On-Demand é uma decisão consciente de desperdiçar orçamento que poderia ser reinvestido em inovação.

🧠 Dev Assina o Código e o Cheque

No mundo On-Premise, um código ruim apenas deixava o sistema lento. Na Nuvem, código ineficiente gera uma fatura imediata. A barreira entre Engenharia e Financeiro desapareceu: cada linha de código é uma decisão de compra executada em tempo real. O desenvolvedor não consome apenas CPU, ele consome o orçamento da empresa.

Para entender o impacto, veja o preço das más práticas:

O Custo da Leitura: Uma query sem "WHERE" ou um Full Table Scan no DynamoDB não é apenas um problema de performance; você está pagando unidades de leitura para ler milhares de linhas inúteis. É como comprar a biblioteca inteira para ler uma única página.
O Custo da Ineficiência: Um código com vazamento de memória engana o Auto Scaling. O sistema provisiona 10 servidores para fazer o trabalho de 2, desperdiçando dinheiro para compensar código ruim.
O Custo do Ruído: Logs em modo VERBOSE esquecidos em produção são vilões. O CloudWatch cobra caro pela ingestão. Enviar gigabytes de "log de lixo" é literalmente pagar frete aéreo para transportar entulho.

A Cultura de Engenharia Consciente de Custos:

Estimativa no Refinamento: O custo deve ser debatido antes do código existir. Durante o Refinamento, ao definir a arquitetura, faça a pergunta: "Quais recursos vamos usar e quanto isso vai custar com a volumetria esperada?". Se a solução técnica custa $1.000 para economizar $50 de esforço manual, ela deve ser vetada ali mesmo.
Feedback Loop: O desenvolvedor precisa ver quanto o serviço dele custa. Painéis do Grafana ou Datadog devem mostrar não só a latência da API, mas o custo diário dela. Só existe responsabilidade quando existe consciência do preço.
Cerimônia de Custo (FinOps Review): Estabeleça uma reunião recorrente dedicada a olhar o "Extrato da Conta". O time analisa os custos atuais, investiga picos não planejados da semana anterior e discute ativamente: "Existe alguma oportunidade de desligar recursos ou otimizar este serviço agora?". É a higiene financeira mantendo o projeto saudável.

🌐 O Mundo Híbrido e Multicloud: Complexidade é Custo

Nem tudo precisa ir para a AWS, e nem tudo deve sair do seu Data Center local. A maturidade em nuvem não significa "desligar tudo o que é físico", mas sim saber onde cada peça do jogo custa menos. Empresas podem operam em modelos híbridos estratégicos:

O Lugar do Legado (On-Premise): Aquele banco de dados gigante ou mainframe que já está quitado, não cresce mais e roda de forma previsível? Deixe onde está. Migrar esses monstros para a nuvem apenas copiando e colando ("Lift-and-Shift") costuma ser um desastre financeiro. Na nuvem, você paga caro por performance de disco (IOPS) e memória que, no seu servidor físico, já são "gratuitos".
O Lugar da Inovação (Nuvem): Seu site, aplicativos móveis e APIs que precisam aguentar milhões de acessos num dia e zero no outro? Leve para a nuvem. Lá você paga pela elasticidade e pelo alcance global que o servidor físico não consegue entregar.

Cuidado com a Armadilha Multicloud
Muitos gestores caem na tentação de usar AWS, Azure e Google Cloud ao mesmo tempo sob o pretexto de "evitar ficar preso a um fornecedor" (Vendor Lock-in). Na prática, para a maioria das empresas, isso triplica o custo operacional. Você precisará de equipes especialistas em três plataformas diferentes, perderá descontos por volume (diluindo seu gasto) e pagará taxas altíssimas de transferência de dados (Egress) para fazer as nuvens conversarem entre si. Complexidade técnica é, invariavelmente, custo financeiro.

Como gerenciar essa infraestrutura sem perder o controle? O uso de ferramentas como Terraform ou OpenTofu. Com elas, criar um servidor não é mais clicar em botões numa tela, mas sim escrever um arquivo de texto (código).

Isso habilita a Revisão de Código Financeira:

Um desenvolvedor propõe uma mudança no código da infraestrutura.
Antes de aprovar, o time revisa num "Pull Request".
A pergunta muda de "O código está certo?" para "Por que você alterou a máquina de micro para extra-large?".

O Code Review de infraestrutura torna-se a primeira e mais barata linha de defesa do FinOps, barrando gastos desnecessários antes mesmo que eles sejam criados.

Conclusão: A Nuvem não é um Destino, é um Modelo Econômico

Migrar para a nuvem não é apenas trocar de servidor; é adotar um novo paradigma operacional e financeiro. Tratar a AWS como um "datacenter glorificado" é o caminho mais rápido para transformar a inovação em prejuízo: ao fazer isso, você acaba pagando a diária de um hotel cinco estrelas apenas para estocar caixas de papelão que poderiam estar num depósito simples.

A virada de chave acontece na cultura. Comece pelo básico bem feito: aplique Tags rigorosamente, automatize a limpeza de recursos e traga o custo para o centro das decisões de arquitetura. Lembre-se que, neste novo mundo, a excelência técnica é inseparável da eficiência financeira: o melhor código não é apenas o que funciona, é o que entrega valor máximo consumindo o mínimo de orçamento.

DEV Community