A infraestrutura é sua, goste você disso ou não

Tem uma frase que ouço em quase toda auditoria: 'a gente não faz infra de verdade, só faz deploy na plataforma'. Eu entendo o sentimento. Ninguém quer passar a semana mexendo em registro de DNS e policy de IAM. Mas a frase é falsa, e essa falsidade custa dinheiro.

Se o seu produto roda em algum lugar, a infraestrutura é sua. Você pode nunca ter escrito um arquivo de Terraform. Pode ter clicado num dashboard e aceitado todos os defaults. Esses defaults agora são a sua arquitetura. Quando eles falham, o cliente não liga para a plataforma. O cliente liga para você.

Default é decisão

Um Postgres gerenciado com o limite de conexões padrão é uma decisão. Uma função serverless com o timeout padrão é uma decisão. Um container sem limite de memória é uma decisão. Você não tomou nenhuma delas de propósito, mas vai debugar todas de propósito, geralmente na pior hora possível.

A armadilha é que os defaults são calibrados para a demo, não para o seu tráfego. O pool de conexões padrão é pequeno o suficiente para esgotar com um deploy modesto de Next.js em que cada instância serverless abre as próprias conexões. A retenção de log padrão é curta o suficiente para que a evidência do incidente da semana passada já tenha sumido. A janela de backup padrão pode estar ótima, ou pode cair exatamente quando o seu batch roda.

Você não precisa mudar todos os defaults. Precisa saber quais está aceitando e por quê. Eu mantenho uma lista simples por projeto: cada serviço gerenciado, cada default que mantive e o número que importa (limite, timeout, retenção). Leva uma tarde e já me economizou semanas.

O stack real do engenheiro full stack

Eu me chamo de full stack e falo isso literalmente. O stack não termina no ORM. Ele inclui o runtime, a rede entre o runtime e o banco, o load balancer, o DNS, o certificado que vence em noventa dias, a CDN que cacheou uma resposta que você achava que era privada.

Cada uma dessas camadas pode produzir um bug que parece bug de aplicação. Uma requisição que estoura o timeout do load balancer em trinta segundos parece query lenta. Uma entrada de DNS velha parece serviço instável. Uma CDN cacheando página autenticada parece vazamento de sessão. Se você não sabe ler essas camadas, não encontra esses bugs, e alguém vai dizer que o código está certo enquanto o produto está quebrado.

O que ser dono significa na prática

Ser dono da infraestrutura não quer dizer rodar servidor próprio. Eu uso serviço gerenciado em quase tudo e recomendo o mesmo para a maioria dos times. Ser dono quer dizer quatro coisas concretas.

• Você consegue desenhar o caminho da requisição do navegador até o banco e de volta, incluindo cada salto que não é o seu código.
• Você sabe quais são os três ou quatro limites que vão estourar primeiro sob carga, e mais ou menos em que tráfego.
• Você consegue restaurar o sistema do zero num tempo documentado, e já fez isso pelo menos uma vez.
• Você sabe quanto custa por mês e qual linha vai crescer mais rápido.

Se qualquer uma dessas falta, a plataforma é dona de você, e não o contrário.

A versão barata

Para um time pequeno, isso não é um investimento grande. Um documento com o caminho da requisição e os limites. Um arquivo de ambiente que lista cada dependência externa. Um restore ensaiado. Uma olhada mensal na fatura. Algumas horas por mês, e a diferença entre um time que é surpreendido pela infraestrutura e um time que é só incomodado por ela.

Os engenheiros em que mais confio não são os que sabem mais de Kubernetes. São os que nunca dizem 'essa camada não é minha'. Tudo que o cliente toca é a sua camada. Aceitar isso cedo é muito mais barato do que descobrir durante uma queda.