Cloud e operação são domínios onde as decisões
erradas custam dinheiro real, produzem dependências
de décadas, e só ficam visíveis quando o problema
já está instalado. As perguntas abaixo forçam
articular o que está em jogo.
Terraform ou Pulumi para IaC?
Terraform tem ecossistema massivo de providers,
comunidade enorme, e HCL que a maioria dos
engenheiros de infra já conhece. O problema
é que HCL não é uma linguagem de programação
— loops e condicionais existem mas são awkward,
e abstrações complexas ficam difíceis. Pulumi
usa linguagens reais (TypeScript, Python, Go)
— o que significa que toda a expressividade de
uma linguagem de programação está disponível,
e o código pode ser testado com unittest. A
decisão prática: Terraform para infra gerida por
time de platform/DevOps que já conhece a ferramenta;
Pulumi para times de desenvolvimento que querem
IaC sem aprender nova linguagem. OpenTofu (fork
open source do Terraform pós-mudança de licença
em 2023) é alternativa viável para quem quer
Terraform sem HashiCorp.
Managed Kubernetes (EKS/GKE/AKS) ou Kubernetes self-managed?
Self-managed Kubernetes (kubeadm, k3s, Talos)
dá controle total sobre versão, configuração e
custos de control plane — mas exige que o time
opere o próprio etcd, gerencie upgrades de
cluster, e tenha expertise profunda em Kubernetes.
Managed (EKS, GKE, AKS) delega o control plane
ao provider: upgrades automáticos, SLA de
disponibilidade do API server, integração nativa
com IAM/RBAC do provider. O custo extra de EKS
($0.10/hora de cluster) raramente justifica operar
o próprio control plane para times com menos de
10 clusters. A exceção: requisitos de air-gap,
compliance com dados em jurisdição específica,
ou equipe com expertise suficiente para o custo
operacional valer.
GitOps (ArgoCD/Flux) ou pipeline push (GitHub Actions)?
Pipeline push: o pipeline de CI tem credenciais
de cluster e faz kubectl apply ou helm upgrade.
Simples de entender, direto. O problema: o pipeline
tem permissões de produção, drift entre o que
está rodando e o que está no git não é detectado,
e o "estado desejado" fica espalhado entre scripts
de pipeline. GitOps: o cluster puxa do git e um
operator garante convergência. Drift é detectado
e alertado automaticamente. Credenciais de
produção nunca ficam no pipeline. O custo: mais
uma ferramenta para operar (ArgoCD tem UI, RBAC,
e upgrade próprio). Para times com mais de 5
engenheiros e múltiplos ambientes, GitOps paga
o investimento. Para times menores ou setup único,
pipeline push é pragmático.
Reserved Instances: quanto comprometer e por quanto tempo?
On-demand tem custo zero de compromisso e
máxima flexibilidade — paga o preço cheio.
Reserved Instance de 1 ano com pagamento upfront
dá ~40% de desconto; 3 anos, ~60%. Savings Plans
(AWS) são mais flexíveis — commitment de
$ por hora, não de instância específica. A
análise correta: identificar o baseline estável
de compute (quanto você sempre vai precisar,
independente de pico) e cobrir com reserva.
Excedente fica on-demand ou spot. O erro comum
é reservar com base no pico — você paga por
capacidade que fica ociosa 20h/dia. Regra
prática: reserve 60-70% do baseline histórico
de 90 dias, revise trimestralmente.
Platform team ou squads autônomos cada um com sua infra?
Squads completamente autônomos ("you build it,
you run it" extremo) maximizam velocidade inicial
mas geram fragmentação: 8 squads com 8 formas
diferentes de fazer deploy, 8 stacks de observabilidade,
8 modelos de custo opacos para a liderança.
Platform team centraliza as preocupações comuns
em golden paths — o squad de produto ainda faz
deploy de sua aplicação, mas em rails já provisionados
pela plataforma. O risco é a plataforma virar
gargalo ou burocracia. Team Topologies (Skelton
& Pais) oferece o modelo: platform team como
"stream-enabling" — reduz carga cognitiva dos squads,
não centraliza decisões de produto. A transição
faz sentido quando o custo de coordenação entre
squads supera o custo de manter a plataforma.