O que eu aprendi em quase 20 anos construindo (e quebrando) infraestrutura

Boas práticas para quem está começando um projeto do zero. Sem hype, sem atalhos, só o que realmente funciona.

Foto por Ryan Quintal no Unsplash

Em quase 20 anos da minha trajetória profissional aprendi bastante depois de participar de vários projetos, tanto aqueles de infra mais raíz, quanto migrações para cloud, Kubernetes e por aí vai. Em algumas vezes tomei decisões erradas, mas o importante disso é o aprendizado. E nada mais justo do que repassar esse conhecimento a diante.

Por isso, eu vejo muitas pessoas (desde os que estão começando agora até os mais experientes) tomando decisões ou querendo surfar a onda do hype, ou como costumávamos dizer na Leroy Merlin, sendo “bleeding-edge”.

Esse post é para quem está trabalhando em projetos greenfield, stealths ou começando do zero.

1 - Escolha tecnologias maduras (boring tech)

Sim, escolha tecnologias maduras ao iniciar novos projetos. Aquele novo orquestrador de conteiner, aquele novo serviço da AWS ou aquele framework novo que promete ser 20% mais rápido que o framework que você utiliza não vale todo o overhead operacional.

Sim, é legal usar e testar novas tecnologias, eu gosto e todo mundo gosta, mas cuidado ao usar em projetos novos. As vezes o tempo gasto dando manutenção em algo que “ninguém usa”, seria muito mais útil se aproveitado trabalhando em melhorias reais de performance.

2 - Infra as Code desde o início

Simples como o título. Provisionar infra não é mais o famoso “next, next, finish” na console da AWS (ou qualquer outra cloud). Sem saber o que e como foi feito só vai gerar mais dívida técnica e impossibilitar de recriar o ambiente em caso de necessidade.

Sem contar as inúmeras vantagens que IaC traz, como rastreabilidade, consistência e redução de erros, já que o código pode ser revisado e testado.

3 - Segurança planejada, não acidental

Adicionar segurança depois que o projeto já está rodando, ou depois de um incidente é muito (mas muito) mais difícil do que construir desde o dia zero. Começar com o menor privilégio possível em roles, keys e etc já é um baita começo. Use IRSA ou Pod Identity na AWS.

Se seu escopo for além da cloud, Dependabot (ou Renovatebot) e Trivy salvam muito.

4 - Automatize tudo

É o mesmo ponto de Infra as Code. Não se trata de velocidade e sim de consistência. Processos manuais criam silos de conhecimento e pontos únicos de falha.

O mínimo aceitável é ter um fluxo de deploy automatizado tanto para infraestrutura quanto para o código.

5 - Documente decisões

Não adianta só documentar seu código, documente suas decisões e os motivos de escolher determinadas arquiteturas.

Um bom início é escrever ADRs (Architectural Decision Records). Não precisa ser nada rebuscado, um markdown em um repositório no GitHub já ajuda. Com certeza, vai ajudar as próximas pessoas do seu time a entender o por que as coisas são do jeito que são.

6 - Se questione o “por que”

Esse vai de encontro com o ponto acima.

A arquitetura das aplicações (ou infraestrutura) devem servir ao negócio, não ao contrário. Tecnologia não é o objetivo, é o meio. Mantenha as coisas simples, com propósitos e alinhado ao negócio.

Provavelmente você não precisa de microserviços para um MVP.

7 - Planeje para falhas

Uma hora seu serviço, sua infra, seu DNS vai falhar. Toda rede tem problemas. Desenhe sua arquitetura esperando que isso vai acontecer em algum momento.

Aprendi com um antigo gestor durante uma migração de servidores Microsoft Exchange 2003 para 2010 (ainda existe isso?), o seguinte pensamento:

Quem tem um, não tem nenhum.
Quem tem dois, tem um.
Quem tem três, tem dois.

E é sobre isso. Tenha no mínimo duas réplicas do que é core para o negócio.

8 - Observabilidade

O papo de observabilidade não é monitoração já tá batido. Identifique seus SLIs e defina SLOs para acompanhá-los. Novamente, tecnologia a favor do negócio e não ao contrário.

Comece instrumentando seu código e pontos chaves da infraestrutura. A stack LGTM é um ótimo ponto de partida.