Terraform e Infraestrutura como Código: o guia para parar de clicar no console

• O que é Infraestrutura como Código e por que ela virou padrão?
• Como funciona o ciclo do Terraform?
• Por que o state é a parte mais delicada?
• Terraform, OpenTofu, Pulumi ou CloudFormation?
• Quais são os erros mais comuns com Terraform?
• Como começar com IaC sem parar o time?

Terraform troca o clique no console por um arquivo versionado: você descreve a infraestrutura desejada, revisa o plano de mudanças e aplica. O ganho central não é velocidade — é saber exatamente o que vai acontecer antes que aconteça.

O que é Infraestrutura como Código e por que ela virou padrão?

Infraestrutura como Código é tratar servidores, redes, bancos, filas e permissões como software: definidos em arquivos, revisados em pull request, versionados no Git e aplicados por automação. A alternativa histórica — configurar na interface da nuvem — falha por três motivos que aparecem em qualquer time que cresce.

O primeiro é a irreprodutibilidade. Um ambiente montado à mão não pode ser recriado com fidelidade. Quando homologação e produção divergem, o bug que só acontece em produção vira rotina.

O segundo é a perda de conhecimento. A configuração vive na cabeça de quem clicou. Documentação envelhece; a interface é a única fonte de verdade e ninguém consegue revisá-la.

O terceiro é a ausência de revisão. Alterar uma regra de firewall no console é uma ação sem diff, sem aprovador e sem histórico útil. Com IaC, a mesma alteração vira um pull request com o antes e o depois explícitos.

A computação em nuvem tornou isso incontornável: quando cada aplicação envolve dezenas de recursos criados e destruídos com frequência, gestão manual deixa de escalar.

Exemplo prático: replicar um ambiente montado à mão para uma nova região leva dias e produz divergências silenciosas. Com IaC, é mudar uma variável de região e aplicar — o resultado é idêntico por construção.

Como funciona o ciclo do Terraform?

Terraform é declarativo: você descreve o estado final, não os passos. A ferramenta calcula o caminho comparando três fontes — o código, o state e a realidade da nuvem.

O ciclo tem três comandos:

1. terraform init — lê a configuração, baixa os providers necessários e conecta ao backend onde o state fica guardado.
2. terraform plan — consulta a nuvem, compara com o desejado e imprime exatamente o que será criado, alterado ou destruído. Nada acontece ainda.
3. terraform apply — executa o plano, respeitando o grafo de dependências entre recursos.

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = "empresa-tfstate"
    key            = "producao/api.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

variable "ambiente" {
  type        = string
  description = "Nome do ambiente (dev, hml, prd)."
}

resource "aws_s3_bucket" "uploads" {
  bucket = "empresa-uploads-${var.ambiente}"
  tags = {
    Ambiente  = var.ambiente
    Gerencia  = "terraform"
  }
}

O plan é o recurso mais subestimado. Ele transforma uma mudança de infraestrutura em algo revisável: um colega lê o diff e vê que o "ajuste simples" na verdade destrói e recria o banco de dados. Esse é o momento em que o incidente é evitado.

Exemplo prático: um time rodou plan antes de mudar o tipo de instância de um RDS e viu must be replaced na saída. A alteração exigia recriar o banco — descoberta na revisão, não às 3h da manhã com o serviço fora do ar.

Por que o state é a parte mais delicada?

O state é o inventário que liga cada bloco resource do código ao identificador real na nuvem. Sem ele, o Terraform não teria como saber que o bucket descrito no arquivo já existe.

Três regras evitam a maioria dos incidentes:

1. State sempre remoto, nunca no repositório. O arquivo local funciona para quem trabalha sozinho e quebra no primeiro colega. Além disso, ele armazena valores em texto claro — senhas de banco, chaves — e não deve ser versionado no Git.
2. Bloqueio obrigatório. Dois apply simultâneos sobre o mesmo state corrompem o inventário. Backends como S3 com DynamoDB, Terraform Cloud ou GCS oferecem bloqueio automático.
3. Um state por ambiente e por domínio. State monolítico com toda a empresa transforma qualquer alteração em risco global e deixa o plan lento. Separe por ambiente (dev/hml/prd) e por área (rede, dados, aplicações).

Vale conhecer também o conceito de drift: alguém mexeu no console e a realidade não bate mais com o state. terraform plan detecta a divergência e propõe voltar ao que o código descreve. Rodar o plan periodicamente em pipeline é a forma barata de descobrir isso antes que vire problema.

Exemplo prático: um state único de 4.000 recursos fazia cada plan demorar onze minutos e travava o time inteiro durante qualquer aplicação. Dividido em seis states por domínio, caiu para menos de um minuto e as equipes voltaram a trabalhar em paralelo.

Terraform, OpenTofu, Pulumi ou CloudFormation?

O mercado tem quatro opções relevantes, com trocas distintas:

A mudança de licença de 2023 merece contexto: o Terraform continua gratuito para praticamente qualquer uso interno; a BUSL restringe oferecer o produto como serviço concorrente. Para a maioria das empresas, o impacto prático é nenhum. Ainda assim, o OpenTofu ganhou tração por remover a incerteza jurídica — e a migração é direta, já que a sintaxe e os providers são compatíveis.

O caso do Pulumi é diferente em natureza: usar uma linguagem de programação real permite laços, condicionais e abstrações que o HCL expressa com dificuldade — ao custo de abrir espaço para a complexidade que a declaratividade evitava.

Exemplo prático: uma empresa que só usa AWS e já tinha times fluentes em CloudFormation não ganharia nada migrando para Terraform. Outra, com AWS, Cloudflare e GitHub sob gestão, ganha muito: um fluxo só para os três.

Quais são os erros mais comuns com Terraform?

Cinco padrões aparecem repetidamente e todos têm correção conhecida:

1. Rodar apply na máquina local em produção. Sem pipeline, não há revisão, não há histórico e não há garantia de versão. Aplicações de produção devem sair de CI/CD, com plan publicado no pull request e apply acionado após aprovação.
2. Não fixar versões. Provider sem restrição de versão significa que a mesma configuração pode gerar resultados diferentes em dias diferentes. Use restrições explícitas e versione seus módulos seguindo versionamento semântico.
3. Segredos no código. Senhas em .tf vão para o Git e para o state. Use um gerenciador de segredos (Secrets Manager, Vault, SSM) e referencie por data source.
4. Abstrair cedo demais. Módulos genéricos criados antes de existirem três casos de uso reais viram camadas que escondem o que está acontecendo. Duplique primeiro; abstraia quando o padrão ficar evidente.
5. Ignorar o custo. IaC facilita criar recursos — e esquecê-los ligados. Ferramentas de estimativa no pull request e a disciplina de FinOps evitam que a agilidade vire fatura.

Exemplo prático: um ambiente de testes criado por Terraform para uma demonstração ficou dois meses no ar porque o destroy nunca foi executado. A correção foi trivial e estrutural: terraform destroy agendado em pipeline para ambientes efêmeros.

Como começar com IaC sem parar o time?

Um caminho incremental que não exige migração de tudo:

1. Comece por um ambiente novo, não pelo legado. Escrever Terraform para infraestrutura existente exige importar recursos um a um — trabalhoso e arriscado como primeiro contato.
2. Um projeto pequeno e completo. Um bucket, uma função, um DNS. Passe pelo ciclo inteiro: código, backend remoto, plan revisado, apply por pipeline.
3. Estruture desde o início. main.tf, variables.tf, outputs.tf e um diretório por ambiente. Convenção simples que evita reorganização dolorosa depois.
4. Coloque o plan no pull request. É o passo que converte o time: quando as pessoas veem o diff da infraestrutura na revisão, a resistência costuma acabar.
5. Depois expanda para o legado por domínio. Comece pelo que muda com frequência — regras de rede, permissões — e deixe o estável para o fim.

Em organizações maiores, esse caminho naturalmente se encontra com engenharia de plataforma: módulos Terraform prontos viram os blocos que um time de produto consome sem precisar entender a nuvem por baixo. E quando o alvo é orquestração de containers, a combinação usual é Terraform criando o cluster e manifests versionados descrevendo o que roda dentro dele — o padrão detalhado no guia de Kubernetes.

Exemplo prático: um time começou com um único bucket em Terraform e pipeline de plan. Três meses depois, toda a rede e as permissões estavam versionadas — sem nenhum "projeto de migração" formal, apenas convertendo o que já ia ser alterado de qualquer forma.

Conclusão

Infraestrutura como Código resolve um problema que não é de automação, e sim de governança: fazer com que mudanças em ambientes críticos sejam explícitas, revisáveis e reproduzíveis. O Terraform virou o padrão dessa prática por combinar um modelo declarativo simples com um ecossistema de providers que cobre praticamente tudo que tem API — e o plan, que mostra o futuro antes de ele acontecer, é sozinho a maior razão para adotá-lo. Os pontos de atenção são conhecidos e têm receita: state remoto com bloqueio, versões fixadas, segredos fora do código, aplicação por pipeline e vigilância sobre custo. Sobre a licença, a BUSL não afeta o uso interno da maioria das empresas, e o OpenTofu está aí como alternativa compatível para quem precisa de garantia jurídica. Comece pequeno, num ambiente novo, e deixe o plan no pull request convencer o time pelo resto.