Custo versus Escalabilidade

O trade-off entre custo e escalabilidade é a tensão entre pagar por capacidade que ainda não
é usada e arriscar indisponibilidade quando a demanda chega. Capacidade provisionada acima
do necessário vira custo ocioso mês após mês; capacidade abaixo do necessário vira erro 503
no pico de vendas, e o prejuízo de um incidente costuma superar a economia de meses. Em
produção, a pergunta certa não é "escalar ou economizar", é o quanto de folga o negócio
precisa, em qual camada, e com qual mecanismo de ajuste automático. A resposta depende da
curva de demanda, do custo de indisponibilidade e da elasticidade de cada componente. Este
arquivo trata das duas extremidades, dos mecanismos de escala e de suas curvas de custo, e
dos instrumentos de FinOps que transformam a decisão em processo contínuo.

Superprovisionamento versus insuficiência

As duas falhas têm naturezas diferentes e exigem métricas diferentes. O superprovisionamento
é desperdício silencioso: instâncias ociosas, réplicas paradas, armazenamento não anexado e
ambientes esquecidos não geram alerta, apenas fatura. A insuficiência é ruído alto: latência
que sobe, fila que cresce, erros de limite e, eventualmente, indisponibilidade, com custo
direto em receita e indireto em confiança. O equilíbrio se estabelece por camada: serviços
críticos de receita operam com folga maior e failover testado, e o restante opera com
utilização alvo mais agressiva.

Referências comuns de mercado situam a utilização média saudável entre cinquenta e setenta
por cento para serviços elásticos, com margem para absorver pico e para sobreviver à perda
de uma zona. O objetivo operacional é utilização estável e monitorada, e não o máximo
teórico, porque utilização acima de oitenta por cento elimina a folga que absorve picos,
reinícios e falhas. Headroom, nesse contexto, não é desperdício; é prêmio de seguro pago por
hora de máquina.

Escala vertical e horizontal

A escala vertical aumenta o recurso da mesma máquina, e ganha pela simplicidade: nenhum
código precisa mudar, e o estado local continua funcionando. O teto, porém, é físico e
econômico, porque instâncias maiores cobram prêmio por capacidade, e a máquina única é ponto
único de falha; redimensionar costuma exigir janela de indisponibilidade. A escala
horizontal adiciona máquinas, e exige que o serviço seja sem estado ou tenha o estado
externalizado em banco e cache distribuído; entram o custo de projeto do balanceamento, da
descoberta de serviço e da gestão de dados particionados.

O custo da escala horizontal não é linear: a cada passo aparecem coordenação, consistência
eventual entre réplicas e operação de mais peças. A política prática usa as duas formas
juntas: vertical até o teto econômico por instância, horizontal conforme a demanda, com
autoscaling baseado em métrica de experiência do usuário, como latência p95, em vez de
apenas CPU. Essa combinação mantém o desenho simples nos limites conhecidos e elástico nos
limites incertos.

As curvas de custo do serverless

Serverless muda a forma da curva: paga-se por invocação e por duração, com custo próximo de
zero em carga baixa ou intermitente, e sem custo de manter servidor ligado. Essa forma é
ideal para carga esporádica, job agendado, endpoint de baixo volume e tráfego de validação
de produto. Em utilização constante e alta, a curva inverte: o custo por unidade de trabalho
do serverless fica acima do custo de capacidade reservada, porque o preço por invocação
embute a margem da elasticidade. O ponto de cruzamento depende da utilização média, e por
isso a análise precisa ser feita com dados reais de tráfego, e não com tarifa isolada.
Custos ocultos também pesam: cold start em cargas sensíveis a latência, transferência de
dados entre serviços e a operação de estado externo, já que funções são sem estado por
natureza. A política comum é serverless nas pontas e nos picos, e capacidade provisionada no
núcleo de tráfego constante.

Cenários de decisão por carga

Três cargas típicas ilustram a escolha. A carga estável de núcleo de negócio, com tráfego
previsível de dia útil, encaixa em contêineres com dimensionamento fixo e compromisso de
uso, porque previsibilidade compra desconto. A carga esporádica, como processamento de
upload e endpoints de integração raramente chamados, encaixa em serverless, porque pagar por
invocação é mais barato que manter máquina acesa. A carga explosiva e sazonal, como campanha
de vendas, encaixa em autoscaling agressivo com fila amortecendo o pico, porque provisionar
o pico permanente seria inviável.

O erro comum é aplicar um único modelo a toda a carga por simplicidade de operação. A
inconsistência de modelos tem custo administrativo real, e a decisão de padronizar deve ser
consciente e registrada, preferindo padronizar por domínio de carga, e não pela empresa
inteira de uma vez.

Custo total de propriedade

A fatura de infraestrutura é apenas parte do custo real, e a comparação honesta usa TCO. Um
serviço autogerenciado parece mais barato na planilha até incluir o custo das pessoas que o
operam: plantão, patches, upgrade de versão, backup testado e resposta a incidente. Serviço
gerenciado cobra prêmio e transfere esse trabalho; a troca costuma ser vantajosa quando o
time é pequeno e o custo de mão de obra domina a conta. TCO também inclui licenças,
treinamento, risco de indisponibilidade e o custo de oportunidade do time, que deixa de
entregar feature enquanto opera infraestrutura.

Custos invisíveis de nuvem merecem atenção específica: transferência de dados entre zonas e
provedores, crescimento de log e armazenamento, snapshots acumulados e ambientes de teste
ligados fora do horário útil. A regra de decisão é comparar o custo total mensal dos dois
caminhos com o mesmo nível de confiabilidade exigido, e não o preço de tabela do componente
isolado.

FinOps na prática

FinOps é a disciplina que conecta engenharia, finanças e negócio no ciclo de decisão de
custo, com três fases consagradas. Informar: alocar cada centavo a um serviço e a um time
por meio de tags consistentes, e publicar showback ou chargeback regular, para que o custo
tenha dono. Otimizar: rightsizing com base em utilização real, descontos por compromisso de
uso, eliminação de recursos órfãos, arquivamento de armazenamento frio e revisão de
arquitetura nos maiores itens da fatura. Operar: metas de custo por unidade de negócio, como
custo por mil requisições ou por cliente ativo, alertas de orçamento antes do estouro e
revisão de custo em toda decisão arquitetural relevante.

A unidade econômica é a métrica que aproxima engenharia do negócio. Sabendo o custo por
requisição, fica evidente quando uma otimização paga, quando um recurso gerenciado justifica
o prêmio e quando um recurso novo ameaça a margem. Cultura é o ponto de partida: engenheiro
que escolhe arquitetura precisa enxergar a fatura que ela gera, e a fatura precisa chegar
segmentada por serviço e por time.

Exemplo prático: autoscaling com limites econômicos

# Política de autoscaling com limites econômicos explícitos
autoscaling:
  min_replicas: 2           # sobrevive à perda de uma zona
  max_replicas: 12          # teto de custo aprovado no orçamento
  metrica: p95_latency_ms   # escala por experiência, e não por CPU
  alvo: 350
  cooldown_segundos: 600    # evita oscilação de réplicas e custo ping-pong
alertas:
  custo_diario_usd: 850     # aviso antes de estourar o teto mensal
  utilizacao_media: 0.75    # acima disso, revisar capacidade provisionada
tags_obrigatorias: [servico, time, ambiente, centro_de_custo]

A política torna explícito o compromisso entre custo e disponibilidade: o mínimo garante
sobrevivência a falha de zona, o máximo protege o orçamento, e a métrica de escala segue a
experiência real do usuário em vez de um proxy genérico. As tags obrigatórias fecham o ciclo
de FinOps, porque sem alocação por serviço não existe showback confiável.

Erros comuns e boas práticas

• Dimensionar para o pico anual com capacidade fixa: provisione para o padrão comum e absorva o pico com autoscaling e fila.
• Autoscaling apenas por CPU: métricas de negócio e latência refletem a experiência real, e CPU engana em serviços de I/O.
• Comparar modelos só pelo preço de tabela: inclua TCO, cold start, transferência de dados e custo de operação das pessoas.
• Fatura sem dono: sem tags e alocação por time, ninguém otimiza nada; showback regular cria responsabilidade.
• Compromisso de uso longo sem histórico: reserve apenas a fração estável da carga, com base em utilização real de meses.
• Cortar capacidade para economizar sem validar: cada corte precisa de teste de carga e de alerta de saturação próximo.