Infrastructure as Code: quando parei de clicar no console e comecei a escrever Terraform
O console da AWS parece intuitivo até você precisar replicar o que fez. Terraform foi a resposta — mas a transição mental foi mais difícil do que a técnica.
Eu tinha um ambiente de staging que funcionava. Tinha criado manualmente: VPC, subnets, security groups, EC2, RDS, load balancer. Levou dois dias clicando no console da AWS.
Quando precisei criar um ambiente de produção idêntico, levou outros dois dias. E o resultado não era idêntico — tinha diferenças sutis que eu só descobri semanas depois quando produção se comportava diferente de staging.
Infrastructure as Code não é sobre Terraform especificamente. É sobre a ideia de que infraestrutura deve ser descrita em código, versionada, revisada como qualquer outro código, e aplicada de forma determinística.
O console da AWS é conveniente para aprender e explorar. É um problema para operar. Cada clique é conhecimento tácito que não está registrado em lugar nenhum além da sua memória. Quando você precisa replicar, reconstruir depois de um desastre, ou auditar o que foi criado por quê — você não tem nada.
Terraform resolve isso. Você escreve o estado desejado da infra em HCL, roda terraform plan para ver o que vai mudar, e terraform apply para aplicar. O estado atual fica registrado num state file que pode ser versionado e compartilhado.
O que ninguém conta sobre a transição para Terraform: a parte difícil não é aprender a sintaxe. É parar de usar o console como fonte da verdade.
Durante as primeiras semanas, eu ficava na tentação de "acertar rápido" alguma coisa no console e depois atualizar o Terraform para refletir. Isso é terraform drift — e é um problema sério porque seu state file perde a sincronização com a realidade.
A disciplina que Terraform exige é: qualquer mudança na infra passa pelo código. Se você não pode esperar o apply, você tem um problema de processo, não de ferramenta.
terraform plan foi o comando que mudou minha relação com mudanças em produção.
Antes de aplicar qualquer mudança, você vê exatamente o que vai acontecer: o que vai ser criado, o que vai ser modificado, o que vai ser destruído. E o que vai ser destruído fica vermelho e em destaque — porque destruir um recurso que você não pretendia destruir pode causar downtime.
Tive um momento de susto no terceiro mês: queria modificar uma propriedade de um security group e o plan mostrou que o Terraform ia destruir e recriar o recurso inteiro (alguns recursos AWS não suportam update in-place). Se eu tivesse aplicado sem ler o plan, teria derrubado parte da infra.
Aprendi a ler o plan com atenção antes de qualquer apply em produção.
Remote state é uma das primeiras coisas a configurar quando há mais de uma pessoa mexendo na infra. State local funciona para aprender. Em time, dois engenheiros rodando terraform apply ao mesmo tempo com state local podem corromper o estado da infra. Remote state com locking (S3 + DynamoDB no caso da AWS) resolve isso.
Demorei mais tempo do que deveria para configurar remote state porque parecia "avançado demais para agora". Não é. É básico de operação em time.
Dois anos depois de escrever meu primeiro recurso Terraform, não consigo imaginar gerenciar infra sem IaC. Não porque clicou no console seja proibido — às vezes é o caminho mais rápido para explorar algo novo. Mas para qualquer coisa que vai ficar, qualquer coisa que vai para produção, qualquer coisa que outra pessoa vai precisar entender ou replicar: precisa estar no código.
Essa semana: se você ainda gerencia infra manualmente, pega um recurso simples que você já tem — um bucket S3, um security group — e escreve o equivalente em Terraform. Não precisa migrar tudo. Começa pelo entendimento de que o mesmo recurso pode ser descrito como código.