Infraestrutura como código: review técnico do Terraform

Adotar infraestrutura como código é o que separa times que operam cloud por cliques de times que operam cloud por contrato versionado. Neste review técnico, analiso o Terraform da perspectiva de quem mantém ambientes reais: donos de SaaS, CTOs e engenheiros de plataforma que precisam de previsibilidade, auditoria e repetibilidade, sem romantizar a ferramenta.

Como o Terraform funciona por dentro

O Terraform é declarativo. Você descreve o estado desejado em HCL (HashiCorp Configuration Language) e a ferramenta calcula a diferença entre esse desejo e o que existe de fato. Esse ciclo se apoia em quatro peças:

Providers: plugins que traduzem recursos HCL em chamadas de API (AWS, Azure, GCP, Cloudflare, Kubernetes, entre outros).
Grafo de dependências: o Terraform monta um DAG dos recursos e paraleliza o que não depende entre si.
State: o arquivo que mapeia cada recurso declarado ao objeto real na nuvem.
Plan e apply: o plan mostra o diff antes de qualquer mudança; o apply executa.

Em infraestrutura como código, o plan é o recurso mais valioso. Ele transforma uma mudança de infraestrutura em algo revisável em pull request, com o mesmo rigor aplicado a código de aplicação.

State, backend e locking: onde a maioria dos problemas nasce

O state é o coração e também o maior ponto de risco. Ele pode conter dados sensíveis em texto claro, então nunca deve ficar no repositório Git. A prática correta é usar um backend remoto com criptografia, controle de acesso e bloqueio contra execuções concorrentes. Um exemplo com S3:

terraform {
  required_version = ">= 1.5"
  backend "s3" {
    bucket  = "minha-empresa-tfstate"
    key     = "prod/network/terraform.tfstate"
    region  = "sa-east-1"
    encrypt = true
  }
}

O mecanismo de locking varia conforme o backend e a versão da ferramenta, então confirme na documentação oficial a opção vigente para o seu caso. O ponto central é não abrir mão do lock: dois apply simultâneos contra o mesmo state podem corromper o estado e gerar drift difícil de reconciliar.

Outra decisão de arquitetura é o tamanho do state. Um único state para tudo deixa o plan lento e amplia o raio de impacto de qualquer erro. Separar por camada (rede, dados, aplicação) e por ambiente reduz o blast radius, ao custo de gerenciar dependências entre states via terraform_remote_state ou data sources.

Módulos e organização do código

Módulos são a unidade de reuso. Um bom módulo expõe poucas variáveis, tem outputs claros e esconde a complexidade de recursos acoplados, como VPC com subnets, rotas e NAT. Alguns princípios que funcionam bem:

Versione módulos por tag e fixe a versão no consumo.
Evite módulos genéricos demais: um módulo com dezenas de variáveis condicionais vira uma segunda linguagem de programação.
Use validation em variáveis para falhar cedo.
Mantenha um diretório por ambiente, ou workspaces com cautela, pois workspaces compartilham a configuração e podem mascarar diferenças reais entre ambientes.

Quando a infraestrutura como código roda em pipeline, o fluxo típico é: fmt e validate no commit, plan anexado ao pull request e apply apenas após aprovação, com credenciais de curta duração via OIDC em vez de chaves estáticas.

Prós e contras reais

Pontos fortes

Ecossistema de providers: cobertura ampla, o que permite gerenciar cloud, DNS, monitoramento e até SaaS com a mesma linguagem.
Plan previsível: revisão de mudanças antes da execução.
Linguagem declarativa legível: curva de entrada razoável para quem já conhece cloud.
Comunidade e material: muita documentação e módulos públicos, que exigem revisão antes do uso em produção.

Limitações

Gestão do state: exige disciplina, e operações como state mv e import pedem cuidado.
Drift: mudanças manuais no console fazem o código divergir da realidade, e o Terraform só percebe no próximo plan.
HCL tem limites: lógica complexa com for_each, dynamic e condicionais pode ficar difícil de manter.
Destruição acidental: um rename mal planejado pode virar destroy e create. Use lifecycle { prevent_destroy = true } em recursos críticos e leia o plan com atenção.

Terraform, OpenTofu e alternativas

Em 2023, a HashiCorp mudou a licença do Terraform para a Business Source License, o que levou à criação do OpenTofu, um fork mantido sob a Linux Foundation. Para a maioria dos times a sintaxe e o fluxo são equivalentes, mas vale avaliar a licença e a política da empresa antes de padronizar. Existem ainda Pulumi (linguagens de propósito geral), AWS CDK e Crossplane (modelo baseado em Kubernetes). Cada um troca simplicidade declarativa por flexibilidade ou integração com outro ecossistema.

Quando adotar e quando não

O Terraform brilha em ambientes multi-conta, multi-cloud ou com mais de um engenheiro mexendo na infraestrutura. Também ajuda quando você precisa replicar ambientes de staging e produção com fidelidade. Para uma única VPS e um deploy simples, o custo de operar state, pipeline e módulos pode superar o benefício.

Se você usa containers, o Terraform costuma provisionar a base (rede, cluster, banco, DNS), enquanto a camada de aplicação fica com outra ferramenta. Para decidir essa camada, veja o comparativo em Orquestração de containers: Kubernetes, Swarm ou Nomad?. E, se a dúvida é quem vai operar tudo isso, o framework de outsourcing ou time interno para founders ajuda a dimensionar o time.

Conclusão

Como abordagem de infraestrutura como código, o Terraform continua sendo uma escolha sólida pela maturidade, pelo plan revisável e pelo ecossistema. O custo é a disciplina operacional: state remoto com lock, módulos enxutos, pipeline com revisão e políticas contra drift. Comece pequeno, com a camada de rede ou um ambiente de teste, meça o ganho em repetibilidade e só então expanda.