A infraestrutura como código deixou de ser diferencial e virou requisito para qualquer time que opera cloud com seriedade. Entre as ferramentas disponíveis, o Terraform segue como uma das referências mais usadas do mercado. Neste review técnico, olho para o que ele entrega, onde ele costuma machucar e em que cenários a adoção faz sentido de verdade.
Como o Terraform funciona por dentro
O Terraform é uma ferramenta declarativa: você descreve o estado desejado em HCL (HashiCorp Configuration Language) e o motor calcula o que precisa mudar. Esse modelo se apoia em quatro peças principais:
- Providers: plugins que traduzem recursos HCL em chamadas de API (AWS, Azure, GCP, Cloudflare, Kubernetes, GitHub e muitos outros).
- State: um arquivo que mapeia os recursos declarados aos objetos reais na nuvem, incluindo IDs e atributos.
- Grafo de dependências: o Terraform monta um DAG a partir das referências entre recursos e paraleliza o que for independente.
- Plan e apply: o
terraform plancompara código, state e realidade; oterraform applyexecuta as mudanças aprovadas.
O ponto central é o state. Ele é o que diferencia o Terraform de um script imperativo, mas também é a maior fonte de incidentes operacionais, como veremos adiante.
Pontos fortes como ferramenta de infraestrutura como código
Na prática, o maior valor da infraestrutura como código com Terraform aparece em quatro frentes.
Previsibilidade com plan
Ver o diff antes de aplicar muda a cultura do time. O plano entra no pull request, é revisado como qualquer mudança de código e deixa trilha de auditoria no Git. Isso reduz mudanças manuais no console e dá rastreabilidade.
Ecossistema de providers e módulos
Um único fluxo de trabalho cobre rede, compute, DNS, banco, filas e até SaaS de terceiros. Módulos permitem padronizar blocos reutilizáveis, como uma VPC ou um cluster, e aplicar o mesmo padrão em vários ambientes.
Reprodutibilidade de ambientes
Subir um ambiente de homologação idêntico ao de produção deixa de ser projeto e vira parâmetro. Para quem busca eficiência financeira, isso conversa diretamente com o que explico em Custo de Cloud: como reduzir até 70% com DevOps na prática, já que ambientes efêmeros e destruição automatizada evitam recursos esquecidos.
Multi-cloud sem ilusão
O Terraform oferece uma linguagem comum para vários provedores, mas não abstrai os recursos. Um aws_instance continua sendo específico da AWS. Você ganha um fluxo único, não portabilidade automática.
Limitações e trade-offs que ninguém deveria ignorar
- Gestão do state: state local em equipe é receita para conflito. É obrigatório usar backend remoto com locking e controle de acesso, pois o arquivo pode conter dados sensíveis em texto claro.
- Drift: alterações feitas fora do Terraform divergem do código. O
plandetecta, mas só quando você executa. Sem rotina de verificação, o drift se acumula. - Blast radius: um state monolítico torna cada apply arriscado e lento. Dividir por domínio e ambiente é quase sempre necessário.
- Linguagem limitada: HCL é declarativa, e lógica complexa com
for_each,dynamice condicionais fica verbosa. Para quem prefere linguagens gerais, alternativas como Pulumi ou CDK existem, com seus próprios custos. - Licenciamento: em 2023 a HashiCorp mudou a licença do Terraform para a Business Source License. Em resposta surgiu o OpenTofu, fork mantido sob a Linux Foundation e compatível em grande parte com o fluxo atual. Para a maioria dos times o uso interno segue sem restrição, mas vale ler a licença com o jurídico se você vende produtos que concorrem com a HashiCorp.
Estrutura mínima recomendada
Um bom começo para infraestrutura como código é separar backend, provider e recursos, com versões fixadas. Exemplo simplificado com state remoto na AWS:
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
backend "s3" {
bucket = "meu-tfstate"
key = "prod/rede/terraform.tfstate"
region = "us-east-1"
# configure o locking conforme a documentação da sua versão
}
}
provider "aws" {
region = var.region
}
Algumas práticas que reduzem risco no dia a dia:
- Fixar versões de provider e do próprio Terraform, evitando upgrades surpresa.
- Separar states por ambiente e por camada (rede, dados, aplicação).
- Rodar
fmt,validateeplanno pipeline e exigir aprovação antes do apply. - Usar segredos via cofre ou variáveis do pipeline, nunca em arquivos versionados.
- Aplicar políticas e scanners de segurança sobre o plano antes de executar.
O pipeline é o que dá escala à prática. Se você ainda não automatizou essa etapa, o passo a passo em Deploy Automatizado com GitHub Actions e Docker: Tutorial Passo a Passo mostra a base de CI/CD que pode ser reaproveitada para rodar plan e apply.
Quando vale adotar e quando evitar
O Terraform faz sentido quando você tem mais de um ambiente, mais de uma pessoa mexendo na infraestrutura ou necessidade de auditoria e repetibilidade. É especialmente útil para donos de SaaS que precisam subir clientes, regiões ou ambientes de forma padronizada.
Ele pesa demais quando a operação é um único servidor simples, quando ninguém no time domina o básico de rede e IAM, ou quando o ambiente muda tão rápido que o código nasce desatualizado. Nesses casos, comece pequeno: importe os recursos críticos com terraform import e evolua por camadas, em vez de tentar descrever tudo de uma vez.
Conclusão
O Terraform não é mágica: é uma ferramenta madura que exige disciplina com state, versionamento e revisão de planos. Em troca, entrega previsibilidade, padronização e auditoria, que são os pilares reais da infraestrutura como código. Se o seu time já sente dor com mudanças manuais e ambientes inconsistentes, a adoção tende a se pagar rápido. Comece por um módulo pequeno, automatize o plano no pipeline e só então expanda.
