Infraestructura como código

Hay dos estilos. En el imperativo escribes los pasos («crea una VPC, luego una subred…»), como en un script de la CLI. En el declarativo describes el resultado («quiero una VPC con dos subredes») y la herramienta calcula qué crear, cambiar o borrar para llegar ahí. Casi todas las herramientas de IaC actuales son declarativas.

Lo declarativo da idempotencia: aplicar dos veces el mismo archivo deja el mismo resultado, sin duplicar nada. También permite detectar la deriva (drift): cuando alguien cambia algo a mano en la consola, la herramienta ve la diferencia entre el código y la realidad.

Y como es código, sigue el mismo flujo que tu aplicación: un pull request muestra qué recursos se van a crear o destruir, alguien lo revisa y el pipeline lo aplica. Lo verás en el módulo de CI/CD.

Terraform, de HashiCorp, describe la infraestructura en HCL, un lenguaje de configuración legible. Cada servicio se gestiona a través de un provider, un plugin que traduce tus recursos a llamadas a su API. Hay providers para AWS, Google Cloud, Azure, Cloudflare, GitHub, Vercel y cientos más, así que un mismo proyecto puede crear un bucket en AWS y su registro DNS en Cloudflare.

El flujo es siempre el mismo: terraform init descarga los providers, terraform plan compara tu código con lo que existe y muestra qué va a crear (+), cambiar (~) o destruir (-), y terraform apply lo ejecuta tras tu confirmación.

En 2023, HashiCorp cambió la licencia de Terraform por una que ya no se considera de código abierto. En respuesta, parte de la comunidad creó OpenTofu, un fork abierto bajo el paraguas de la Linux Foundation que usa el mismo lenguaje y es compatible en gran medida, aunque con el tiempo cada proyecto va añadiendo funciones propias.

Terraform guarda en el estado (terraform.tfstate) la correspondencia entre tus recursos y los reales: «aws_s3_bucket.fotos es el bucket fotos-tienda-2026», con todos sus atributos. Sin él no sabría si algo ya existe ni podría calcular el plan.

En equipo, el estado no puede vivir en el portátil de nadie: se guarda en un backend remoto, como un bucket de S3 o HCP Terraform. El backend debe ofrecer bloqueo (locking): mientras alguien ejecuta apply, nadie más puede modificar el estado, porque dos ejecuciones simultáneas lo corromperían. Con S3, las versiones recientes de Terraform bloquean con un archivo en el propio bucket; antes hacía falta una tabla de DynamoDB.

En CloudFormation escribes una plantilla en YAML o JSON con los recursos (Resources), los parámetros de entrada (Parameters) y los valores de salida (Outputs). Al desplegarla creas una pila (stack): el conjunto de recursos que CloudFormation gestiona como una unidad. El estado lo guarda AWS, no tú.

Antes de modificar una pila puedes crear un conjunto de cambios (change set), el equivalente al plan de Terraform: muestra qué se añadirá, modificará o reemplazará. Si algo falla a mitad del despliegue, CloudFormation hace rollback automático y deja la pila como estaba.

El CDK (Cloud Development Kit) te permite definir la infraestructura con un lenguaje de programación: TypeScript, Python, Java, C# o Go. Al ejecutar cdk synth, tu programa genera (sintetiza) una plantilla de CloudFormation, y cdk deploy la despliega. Por debajo sigue siendo CloudFormation, con sus pilas y sus rollbacks.

Las piezas se llaman constructs y tienen tres niveles. Los L1 son la traducción literal de cada recurso de CloudFormation (CfnBucket). Los L2 añaden valores por defecto sensatos y métodos útiles: bucket.grantRead(funcion) genera la política de IAM por ti. Los L3 son patrones completos, como «un servicio en Fargate con su balanceador».