OpenTofu: Infraestrutura como Código Sem Lock-in de Licença

A mesma disciplina que defendemos para código — arquivos pequenos, responsabilidade única, nomes únicos — se aplica diretamente à infraestrutura. No artigo sobre Floci, mostrei como testar infraestrutura localmente sem depender da AWS. Agora, fechamos o ciclo: como provisionar produção com infraestrutura como código.

Em 2023, a HashiCorp mudou a licença do Terraform de MPL (open-source) para BSL (Business Source License). Na prática, isso significava que empresas competidoras não podiam mais usar o Terraform livremente. A comunidade respondeu em semanas: a Linux Foundation criou o OpenTofu, um fork 100% compatível sob licença Apache 2.0.

O resultado é que hoje temos duas ferramentas funcionalmente idênticas. Uma com licença restritiva. Outra com licença aberta. A escolha é política, mas o impacto é técnico.

Por que Infraestrutura como Código Importa

Antes do IaC, provisionar infraestrutura era um exercício de cliques no console. Criar uma VPC, configurar subnets, definir security groups, lançar um RDS, criar um bucket S3 — tudo feito manualmente, tudo documentado em wikis que ninguém lia, tudo irreproduzível.

O problema não é apenas que o processo é lento. É que ele é invisível. Quando a infraestrutura é definida por cliques, não há diff, não há pull request, não há code review. Se algo quebra, não há histórico de quem mudou o quê e quando. Se um desenvolvedor sai da empresa, o conhecimento sobre a infraestrutura sai com ele.

Infraestrutura como código muda isso completamente. A infraestrutura vira texto. Texto pode ser versionado. Versionado pode ser revisado. Revisado pode ser testado. Testado pode ser automatizado. Automatizado pode ser confiável.

O OpenTofu é a ferramenta que transforma essa cadeia em realidade. Você escreve a infraestrutura em HCL (HashiCorp Configuration Language), uma linguagem declarativa que descreve o estado desejado dos seus recursos. O OpenTofu compara esse estado com o que existe na AWS e cria, atualiza ou destrói recursos para alcançar a convergência.

Arquitetura Modular: Oito Módulos, Uma Responsabilidade Cada

A maior lição do Clean Code aplicada à infraestrutura é: cada módulo faz uma coisa e faz bem. No projeto SafeHire, a infraestrutura AWS é dividida em oito módulos OpenTofu, cada um com uma responsabilidade clara.

O módulo de networking cria a VPC, as subnets públicas e privadas, o Internet Gateway, o NAT Gateway e os security groups. É a fundação — sem rede, nada mais funciona.

O módulo de IAM define as roles e políticas que permitem aos serviços ECS baixar imagens Docker, escrever logs no CloudWatch e acessar S3, SQS e RDS. É o sistema de permissões.

O módulo de RDS provisiona o PostgreSQL 15 com a extensão pgvector habilitada, storage criptografado e backups automáticos. É onde os dados relacionais vivem.

O módulo de storage cria o bucket S3 para armazenamento de currículos, com versionamento, criptografia e política de expiração de versões antigas. É o sistema de arquivos da aplicação.

O módulo de messaging configura a fila SQS para processamento assíncrono de candidatos, com uma dead-letter queue para mensagens que falham repetidamente. É o sistema de mensageria.

O módulo de cache provisiona o ElastiCache com Valkey (compatível com Redis) para cache de sessões e dados quentes. É a camada de performance.

O módulo de monitoring cria os log groups do CloudWatch para cada serviço e um dashboard consolidado com métricas de CPU, memória e latência. É a janela de observabilidade.

E finalmente, o módulo de ECS — o consumidor de todos os outros. Ele cria o cluster Fargate, o Application Load Balancer, as task definitions de cada serviço (api-gateway, core-management, agent-worker, frontend-app) e os serviços ECS que rodam as containers. O ECS depende de networking para subnets, de IAM para permissões, de RDS para banco, de storage para arquivos, de messaging para filas, de cache para performance e de monitoring para observabilidade.

Essa separação não é estética. É estratégia. Quando você precisa mudar apenas a configuração do RDS — digamos, aumentar o storage de 20 para 100 gigabytes — você modifica apenas o módulo de RDS. O plano de execução do OpenTofu mostra exatamente o que vai mudar, sem tocar no resto da infraestrutura.

State Remoto com Locking: A Cola que Mantém Tudo Coeso

Toda ferramenta de IaC precisa de um estado: um registro de quais recursos foram criados, com quais configurações, e quais são seus identificadores na nuvem. Sem estado, o OpenTofu não saberia que a VPC que ele criou ontem é a mesma VPC que ele precisa atualizar hoje.

O estado pode ser local — um arquivo no seu laptop. Mas isso cria um problema imediato: se dois desenvolvedores rodam tofu apply ao mesmo tempo, ambos tentam modificar a mesma infraestrutura sem saber da existência um do outro. O resultado é corrupção de estado, recursos órfãos e, no pior caso, infraestrutura destruída acidentalmente.

A solução é state remoto com locking. O OpenTofu armazena o estado em um bucket S3 e usa uma tabela DynamoDB como mecanismo de lock. Quando um desenvolvedor inicia um apply, o OpenTofu cria um lock na tabela DynamoDB. Se outro desenvolvedor tenta rodar apply simultaneamente, o segundo processo espera o lock ser liberado — ou falha com uma mensagem clara de que alguém já está modificando a infraestrutura.

O custo desse mecanismo é irrisório: menos de um centavo de dólar por mês. O valor é imenso: a garantia de que duas execuções concorrentes nunca vão corromper o estado da sua infraestrutura.

Task Definitions nos Submódulos: Segregação de Responsabilidades

Uma decisão arquitetural importante no projeto SafeHire foi onde colocar as task definitions do ECS. Em vez de centralizar tudo no módulo OpenTofu, cada submódulo (api-gateway, core-management, agent-worker, frontend-app) mantém seu próprio arquivo ecs-task-definition.json dentro do seu diretório docker/.

A razão é simples: o dono do serviço é o dono da sua definição de deploy. Se o time do api-gateway precisa adicionar uma variável de ambiente ou mudar a porta do container, eles não precisam abrir um pull request no repositório raiz de infraestrutura. Eles mudam o arquivo no seu próprio repositório, e o OpenTofu lê esse arquivo automaticamente durante o deploy.

O OpenTofu usa uma função chamada templatefile() para ler esses JSONs e substituir variáveis como o registry de imagens, a tag da versão, o endpoint do RDS, o endpoint do cache e a URL da fila SQS. O resultado é que cada task definition é renderizada com os valores reais da infraestrutura no momento do deploy.

Essa separação é elegante porque respeita os limites de responsabilidade. A infraestrutura (VPC, RDS, S3) é gerenciada pelo módulo OpenTofu na raiz. A definição de como cada serviço roda (imagem, portas, variáveis) é gerenciada pelo dono do serviço no seu submódulo. O OpenTofu apenas orquestra.

CI/CD Orquestrado: Do Push ao Deploy

O pipeline de deploy do SafeHire é acionado manualmente via workflow_dispatch no GitHub Actions. O desenvolvedor escolhe o ambiente — VPS, AWS staging ou AWS production — e opcionalmente especifica uma tag de imagem.

O pipeline faz o checkout do repositório com todos os submódulos, configura as credenciais AWS, instala o OpenTofu e executa a sequência clássica: init, plan, apply.

O init configura o backend S3 com a chave correta para o ambiente escolhido. O plan gera um arquivo de plano que mostra exatamente o que vai mudar. O apply executa o plano e atualiza a infraestrutura.

Para staging, os recursos são menores: banco db.t3.medium com 20 gigabytes, cache t3.micro, tasks Fargate com 0.25 vCPU e 512 megabytes de memória, uma única task por serviço, duas zonas de disponibilidade.

Para produção, os recursos escalam: banco r6g.large com 100 gigabytes, cache r6g.large, tasks com 1 vCPU e 2 gigabytes de memória, duas tasks por serviço para redundância, três zonas de disponibilidade.

O custo estimado para staging é de aproximadamente 160 a 180 dólares por mês. Produção, com recursos maiores e redundância, fica na faixa de 300 a 400 dólares. Não é barato, mas é previsível — e previsibilidade é o que infraestrutura como código oferece de mais valioso.

O Fork que Salvou o Ecossistema

A história do OpenTofu é um caso raro na indústria de software: uma comunidade que se mobilizou para proteger uma ferramenta crítica contra mudanças de licença. Em poucos meses, a Linux Foundation criou um fork funcionalmente idêntico ao Terraform, com compatibilidade total de providers, módulos e sintaxe HCL.

Para quem usa a ferramenta, a transição é invisível. O comando muda de terraform para tofu. A sintaxe é a mesma. Os providers são os mesmos. Os módulos são os mesmos. A única diferença é a licença: Apache 2.0 em vez de BSL.

Essa diferença de licença importa porque garante que a ferramenta continuará aberta para sempre. Nenhuma empresa pode fechar o código, mudar os termos ou cobrar licenças. O OpenTofu pertence à Linux Foundation, e a Linux Foundation pertence à comunidade.

Conclusão

O OpenTofu resolve o problema fundamental da infraestrutura moderna: como gerenciar recursos de nuvem de forma previsível, versionada e automatizada. A resposta é tratar infraestrutura como código — com a mesma disciplina de revisão, teste e automação que aplicamos ao software.

A arquitetura modular do SafeHire — oito módulos, cada um com uma responsabilidade, todos convergindo para o ECS — demonstra que os princípios de Clean Code não se aplicam apenas ao código de aplicação. Eles se aplicam a qualquer coisa que descrevemos em texto: infraestrutura, configuração, documentação.

Combinado com o Floci para desenvolvimento local e com um pipeline CI/CD orquestrado, o OpenTofu fecha o ciclo completo: do código ao deploy, tudo versionado, tudo testável, tudo reproduzível.

Esta série cobriu dois pilares: desenvolvimento local realista com Floci e infraestrutura de produção versionada com OpenTofu. Juntos, formam o ciclo completo de desenvolvimento cloud-native em 2026.

Este artigo faz parte de uma série sobre desenvolvimento cloud-native. O artigo anterior, Floci: Emulador AWS All-in-One para Desenvolvimento Local, discute como desenvolver aplicações cloud-native sem depender da AWS real.