FinOps

Chega a primeira fatura real do ambiente de produção do BoxOffice, e ela é três vezes a estimativa. Ninguém sabe explicar por quê: os custos estão espalhados em quarenta itens, metade deles com nomes como USE1-NatGateway-Bytes e DataTransfer-Regional-Bytes, e nenhum recurso tem uma tag com o serviço que o criou. Na nuvem, toda decisão de arquitetura é também uma decisão de compra — e a fatura é a única métrica que todo executivo lê.

FinOps (operações financeiras de nuvem) é a prática de trazer responsabilidade financeira ao modelo de gastos variáveis da nuvem, para que engenharia, finanças e negócio façam juntos os trade-offs entre velocidade, custo e qualidade¹. Para quem projeta sistemas, isso se resume a três habilidades: estimar quanto uma arquitetura vai custar, atribuir quanto ela de fato custa e otimizar sem quebrar os SLOs².

O ciclo de vida de FinOps

A FinOps Foundation organiza a prática em três fases que se repetem continuamente¹:

flowchart LR
    inform["Informar<br/>visibilidade: tags, alocação,<br/>showback, custos unitários"] --> optimize["Otimizar<br/>rightsizing, compromissos,<br/>spot, mudanças de arquitetura"]
    optimize --> operate["Operar<br/>orçamentos, alertas de anomalia,<br/>políticas, revisões"]
    operate --> inform

• Informar — não dá para otimizar o que não se vê. Todo recurso leva tags (project, env, service, team); os custos do Kubernetes são divididos por namespace e label a partir dos requests de recursos dos pods (ferramentas como o projeto da CNCF OpenCost⁴, ou o Kubecost). O resultado é o showback (os times veem seus custos) ou o chargeback (os times são cobrados internamente).
• Otimizar — reduzir desperdício (recursos ociosos e superdimensionados) e pagar menos por unidade (compromissos, spot, arquiteturas mais baratas).
• Operar — orçamentos com alertas, detecção de anomalias no gasto diário, políticas (nenhum recurso sem tag, nada de instâncias com GPU em dev) e uma revisão mensal de custos ao lado da revisão de SLOs.

Anatomia de uma fatura de nuvem

Modelos de preço

O portfólio usual é compromisso para o piso, on-demand para a onda diária, spot para a parte interrompível — o que só funciona se você conhece a sua base, ou seja, depois da fase Informar.

Um modelo de custo do BoxOffice

O modelo abaixo estima a fatura mensal da arquitetura de produção projetada neste curso. Cada número é uma premissa que você pode mudar — esse é o objetivo de um modelo: tornar explícitos os fatores de custo e permitir perguntar "e se?". Os preços são preços de tabela on-demand aproximados da AWS us-east-1; confirme-os na calculadora do provedor antes de citá-los e lembre-se de que outras regiões (incluindo sa-east-1, São Paulo) são mais caras.

Total ≈ $5,042/month. The four on-sales add only $43 because the 24 extra nodes exist for 8 hours; keeping them 24/7 'just in case' would add ≈ $3,364/month. At 400,000 tickets per month the platform costs ≈ $0.013 per ticket sold.

Lendo o modelo

• O pico é barato; a base não. A capacidade elástica para as vendas custa quase nada, porque existe por oito horas. Provisionar para o pico de forma permanente custaria mais que todo o resto da conta de computação. Esse é o argumento econômico para autoscaling, pré-escala e salas de espera (Planejamento de capacidade).
• Serviços de dados dominam a computação. PostgreSQL, Redis e Kafka juntos custam mais que os nós que executam nove serviços. Antes de adicionar um quarto armazenamento de dados, pergunte se um dos existentes não resolve.
• Bytes custam mais que CPUs. A saída da CDN e a ingestão de logs estão entre os maiores itens. Compressão de imagens, tempos de cache mais longos, amostragem de logs de debug e retenção menor mudam a conta mais do que otimizar Java.
• Economia unitária transforma a fatura em uma métrica de negócio: custo por ingresso vendido (ou por 1 000 requisições, por usuário ativo). Uma conta que dobra enquanto os ingressos triplicam é uma boa notícia; uma conta que cresce com os ingressos estáveis é uma regressão — acompanhe-a como uma regressão de desempenho.

Pagar por requisição ou por hora?

Quando FaaS é mais barato que containers sempre ligados? O gráfico compara uma função (100 ms por requisição com 512 MB, atrás de uma porta de entrada HTTP API) com um mínimo de duas pequenas tarefas de container atrás de um load balancer, cada uma atendendo 50 requisições por segundo:

Abaixo de aproximadamente dez requisições por segundo em média, pagar por requisição vence — containers ociosos são puro desperdício. Acima disso, o adicional por requisição se acumula e containers sempre ligados vencem, ainda mais com compromissos. Tráfego em rajadas muda o quadro: o que importa é a média, enquanto os containers precisam ser dimensionados para o pico (ou escalar automaticamente). É por isso que o BoxOffice roda o gerador de miniaturas e os receptores de webhook como funções, e o caminho de compra em containers.

Alavancas de otimização

As alavancas abaixo seguem as práticas de otimização de custo dos frameworks well-architected dos provedores de nuvem³. Cada uma economiza dinheiro e cada uma, exceto a última, pode prejudicar um SLO se aplicada às cegas.

Estimando em uma entrevista de system design

Entrevistadores raramente querem dólares, mas consciência de custo é um sinal forte. Um hábito de três passos basta:

1. Nomeie os fatores de custo: "O custo é dominado pela saída de imagens (CDN), pela camada de dados e pela computação de pico."
2. Ordem de grandeza a partir da sua estimativa de capacidade: "30 nós por 8 horas por mês é barato; 30 nós por 730 horas não é — então fazemos autoscaling e pré-escala."
3. Uma otimização com seu trade-off: "Spot para os workers, porque são idempotentes e fazem retry; nunca para o banco primário."

Como se conecta

flowchart LR
    BILL["a fatura: compute, serviços gerenciados,<br/>armazenamento, transferência, itens fixos"] --> INF["Informar: tags,<br/>custo por requests dos pods"]
    INF --> OPT["Otimizar: rightsizing,<br/>compromissos, spot, ARM"]
    OPT --> OPS["Operar: orçamentos,<br/>anomalias, revisão mensal"]
    BASE["base vs pico<br/>→ autoscaling, pré-escala"] --> OPT
    FAAS["por requisição vs por hora<br/>→ equilíbrio do serverless"] --> OPT
    UNIT["unit economics:<br/>custo por ingresso vendido"] --> OPS
    OPT --> SLO["toda alavanca pode ferir um SLO<br/>→ Confiabilidade"]
    OPT --> LT["rode o teste de carga de novo<br/>→ Performance"]
    BILL --> MAZ["Multi-AZ, segunda região:<br/>custo que compra disponibilidade"]
    BILL --> OBS["fatura de observabilidade:<br/>cardinalidade, retenção"]

Componentes da paleta: sql · cache · kafka (a camada de dados domina o compute) · cdn (egress) · nat (fixo por hora + por GB processado) · objstore (camadas de ciclo de vida) · logs (ingestão) · serverless · worker (candidatos a spot) · payment (taxas, um custo do negócio). Cenários: serverless-burst, multi-region (quanto custa uma segunda região). Continua em: Compute — containers ou serverless, Performance — planejamento de capacidade, Confiabilidade — recuperação de desastres, Redes e segurança — a rede na nuvem (NAT gateways), Observabilidade — sinais (cardinalidade), Projeto — relatório de custos.