Terraform en 2026: infraestructura como código para todos los niveles

Infraestructura como código (IaC) es el principio de definir y gestionar la infraestructura cloud mediante archivos de configuración versionados, en lugar de configurar recursos manualmente en la consola. Terraform, de HashiCorp, es la herramienta más adoptada para esto, con soporte para AWS, Azure, GCP y cientos de proveedores más a través de su sistema de providers.

Los conceptos que debes entender antes de escribir código

State: Terraform mantiene un archivo de estado (terraform.tfstate) que mapea los recursos definidos en tu código con los recursos reales en el cloud. Este archivo es crítico: sin él, Terraform no sabe qué existe. En producción, el state debe almacenarse de forma remota (S3 + DynamoDB en AWS, Azure Blob Storage, Terraform Cloud) y nunca en el repositorio de código.

Plan antes de apply: terraform plan te muestra exactamente qué va a crear, modificar o eliminar antes de hacer ningún cambio. Revisar el plan siempre —especialmente en producción— es lo que distingue un uso responsable del "apply y reza".

Módulos: La unidad de reutilización en Terraform. En lugar de copiar y pegar bloques de configuración entre proyectos, defines un módulo (una carpeta con sus propios inputs y outputs) y lo reutilizas. El Terraform Registry tiene módulos de calidad para los patrones más comunes: VPCs, clusters EKS, bases de datos RDS.

Estructura de un proyecto real mantenible

Un proyecto Terraform que escala bien se organiza así:

infrastructure/
├── modules/               # Módulos reutilizables internos
│   ├── vpc/
│   ├── eks-cluster/
│   └── rds/
├── environments/
│   ├── dev/
│   │   ├── main.tf        # Usa los módulos con vars de dev
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── prod/
└── .github/workflows/     # CI/CD para terraform plan/apply

Separar por ambiente es fundamental: una configuración de dev y prod en el mismo directorio con variables condicionales es una receta para errores costosos.

Lo que hace difícil Terraform a escala

Drift: Si alguien modifica un recurso manualmente en la consola, Terraform ya no refleja la realidad. terraform refresh y los checks de drift automatizados (como Driftctl) ayudan, pero la disciplina de nunca tocar la consola para recursos gestionados por Terraform es el único remedio real.

Tiempo de ciclo: En proyectos grandes, terraform plan puede tardar varios minutos porque consulta el estado actual de todos los recursos. El uso de target para operar solo en subsecciones específicas es un workaround aceptable, pero tiene sus riesgos si no entiendes las dependencias.

Estado compartido entre equipos: Cuando múltiples equipos operan sobre el mismo state, los locks de DynamoDB previenen conflictos, pero la coordinación entre equipos sigue siendo necesaria.

Alternativas a considerar en 2026

Pulumi: Define infraestructura con código real (TypeScript, Python, Go, C#). Para equipos de ingeniería con buen dominio de programación, el poder expresivo es mayor que el HCL de Terraform.

OpenTofu: El fork open source de Terraform, mantenido por la Linux Foundation, tras el cambio de licencia de HashiCorp a BUSL en 2023. API-compatible con Terraform, lo que facilita la migración para quienes quieren evitar el vendor lock-in.

CDK de AWS/Azure: Si estás 100% en un cloud específico, los CDK nativos ofrecen integración más profunda con los servicios del proveedor y se escriben en lenguajes de programación convencionales.

Para la mayoría de equipos que empiezan con IaC hoy, Terraform (u OpenTofu) sigue siendo la elección más pragmática por su madurez, ecosistema de módulos y cantidad de recursos de aprendizaje disponibles.