Durante décadas, montar un servidor consistió en seguir un documento de Word con cuarenta pasos manuales, clicar en consolas web y rezar para que el entorno de producción se pareciera al de pruebas. El resultado era el síndrome del «copo de nieve»: cada servidor único, irreproducible y aterrador de tocar. La infraestructura como código (IaC) rompe ese círculo al describir servidores, redes, balanceadores y bases de datos en ficheros de texto versionados que una herramienta aplica de forma automática y repetible. La infraestructura deja de ser un artesanado y pasa a ser software: revisable, testeable y reconstruible desde cero. Este artículo explica los conceptos que sostienen la IaC, compara las herramientas dominantes y aterriza las buenas prácticas que separan un proyecto sólido de un campo de minas.
Declarativo frente a imperativo: la distinción que lo cambia todo
Existen dos filosofías para automatizar infraestructura. El enfoque imperativo describe los pasos a ejecutar («crea una máquina, luego instala el paquete, luego abre el puerto»). El enfoque declarativo describe el estado final deseado («quiero tres servidores web con este paquete y este puerto abierto») y deja que la herramienta calcule qué acciones son necesarias para llegar ahí desde el estado actual. La mayoría de herramientas modernas son declarativas, y por una buena razón: si ejecutas el mismo fichero declarativo dos veces, el resultado es idéntico porque la herramienta solo aplica las diferencias. Esa propiedad se llama idempotencia y es el corazón de la IaC. Un script imperativo ejecutado dos veces puede crear recursos duplicados o fallar; un manifiesto declarativo idempotente converge siempre al mismo estado.
Las herramientas dominantes: Terraform, Ansible, CloudFormation y Pulumi
El ecosistema se reparte entre cuatro grandes nombres con propósitos distintos que conviene no confundir. Terraform (y su bifurcación de código abierto OpenTofu) es la herramienta de aprovisionamiento declarativo multinube por excelencia: usa el lenguaje HCL y un sistema de providers para gestionar recursos en AWS, Azure, Google Cloud y cientos de servicios más. AWS CloudFormation hace lo mismo pero atado exclusivamente al ecosistema de Amazon. Ansible brilla en la gestión de configuración y el aprovisionamiento de software dentro de los servidores ya creados, sin necesidad de agente. Pulumi permite escribir la infraestructura en lenguajes de programación reales (TypeScript, Python, Go) en lugar de un DSL específico. En la práctica, una arquitectura madura combina Terraform para crear la infraestructura base y Ansible para configurar lo que vive dentro de ella.
| Herramienta | Enfoque | Lenguaje | Mejor para |
|---|---|---|---|
| Terraform / OpenTofu | Declarativo | HCL | Aprovisionamiento multinube |
| AWS CloudFormation | Declarativo | YAML / JSON | Entornos 100 % AWS |
| Ansible | Procedimental idempotente | YAML (playbooks) | Configuración de servidores, sin agente |
| Pulumi | Declarativo | TypeScript, Python, Go | Equipos que prefieren lenguajes reales |
El estado: el concepto más delicado de Terraform
Para saber qué diferencias aplicar, Terraform mantiene un fichero de estado (terraform.tfstate) que registra el mapeo entre lo que has declarado y lo que existe de verdad en la nube. Aquí se concentran los problemas más graves de un proyecto IaC. Guardar el estado en el portátil de un ingeniero es una receta para el desastre: si dos personas aplican cambios a la vez, el estado se corrompe; si el portátil se pierde, Terraform pierde la noción de lo que gestiona. La buena práctica obligatoria es el estado remoto con bloqueo: almacenarlo en un backend compartido (por ejemplo un bucket S3 con bloqueo, o un backend gestionado) que impida ejecuciones simultáneas. Además, el fichero de estado suele contener secretos en claro (contraseñas de bases de datos, claves), por lo que debe cifrarse en reposo y nunca subirse a un repositorio Git.
Flujo de trabajo: plan, revisión y aplicación en CI/CD
La gran ventaja de tratar la infraestructura como código es que hereda el flujo del desarrollo de software. El ciclo recomendado es: escribir el cambio en una rama, abrir una pull request, ejecutar automáticamente terraform plan para que el equipo revise exactamente qué recursos se van a crear, modificar o destruir antes de aprobar, y solo tras la aprobación ejecutar terraform apply desde un pipeline de integración continua. Esta disciplina aporta tres garantías que el clic manual nunca dio: revisión por pares de cada cambio de infraestructura, trazabilidad completa (cada modificación tiene un autor, una fecha y un motivo en el historial de Git) y la capacidad de revertir un cambio dañino volviendo a una versión anterior del código.
Seguridad y cumplimiento como código
La IaC no solo automatiza; permite auditar la seguridad antes de desplegar. Las herramientas de policy as code y los escáneres de IaC analizan los manifiestos en busca de configuraciones peligrosas —un bucket de almacenamiento abierto a internet, un grupo de seguridad con el puerto 22 expuesto al mundo, cifrado desactivado— y bloquean el despliegue si infringen las reglas. Esto encaja directamente con marcos de cumplimiento: el control de cambios y la trazabilidad que exige la ISO/IEC 27001 para la gestión de la seguridad de la información se satisfacen de forma natural cuando cada cambio de infraestructura pasa por revisión en una pull request. Y cuando la infraestructura procesa datos personales, el principio de protección de datos desde el diseño del RGPD (artículo 25) se materializa codificando el cifrado, la segmentación de red y los controles de acceso directamente en los manifiestos, no añadiéndolos a posteriori.
Módulos, entornos y la lucha contra el drift
A medida que el proyecto crece, la organización del código se vuelve tan importante como la corrección de cada recurso. El patrón recomendado es encapsular la infraestructura repetitiva en módulos reutilizables: en lugar de copiar y pegar la definición de una red privada en cada proyecto, se define una vez como módulo parametrizado y se invoca con distintos valores. Esto aplica el principio «no te repitas» a la infraestructura y reduce drásticamente los errores por copia. Sobre los entornos, la buena práctica es mantener desarrollo, preproducción y producción con el mismo código pero distintos ficheros de variables, garantizando que lo que se prueba en preproducción es idéntico en estructura a lo que correrá en producción. Esa paridad de entornos elimina la clásica excusa del «en mi entorno funcionaba».
El enemigo silencioso de todo proyecto maduro es el drift: la divergencia entre lo que dice el código y lo que existe realmente en la nube, causada por cambios manuales hechos «solo esta vez» en una urgencia. El drift es peligroso porque el siguiente apply puede deshacer ese parche de emergencia sin avisar, o fallar de forma confusa. La defensa es doble: por un lado, ejecutar periódicamente una detección de drift automatizada que compare estado y realidad y alerte de las diferencias; por otro, una disciplina cultural innegociable de que todo cambio pasa por el código, sin excepciones. Cuando una urgencia obliga a tocar a mano, la regla es reflejar inmediatamente ese cambio en el código antes de cerrar el incidente, de modo que el repositorio siga siendo la única fuente de verdad de la infraestructura.
Errores comunes que arruinan un proyecto de IaC
- Estado local o sin bloqueo: el origen del 80 % de los desastres. El estado debe ser remoto, cifrado y con bloqueo de concurrencia.
- Cambios manuales fuera del código (drift): tocar un recurso a mano en la consola web rompe la correspondencia con el código; el siguiente
applypuede deshacer ese arreglo o fallar. - Secretos en el repositorio: meter contraseñas o claves en los ficheros
.tfo en el estado versionado. Hay que usar un gestor de secretos. - Un único estado monolítico: meter toda la infraestructura en un solo estado hace que cada cambio sea lento y arriesgado. Conviene segmentar por entorno y por dominio.
- Aplicar sin revisar el
plan: aprobar a ciegas equivale a clicar en producción sin mirar.
Preguntas frecuentes
¿Qué diferencia hay entre Terraform y Ansible?
Terraform aprovisiona la infraestructura (crea servidores, redes, bases de datos) de forma declarativa y multinube. Ansible configura lo que vive dentro de esos servidores (instala paquetes, ajusta servicios). Se complementan: Terraform construye la casa, Ansible la amuebla.
¿Qué es la idempotencia y por qué importa?
Es la propiedad por la que aplicar el mismo manifiesto varias veces produce siempre el mismo estado final, sin duplicar recursos ni romper nada. Es lo que hace la IaC predecible y segura de reejecutar.
¿Dónde debe guardarse el fichero de estado de Terraform?
En un backend remoto compartido con bloqueo de concurrencia y cifrado en reposo (por ejemplo un bucket con bloqueo o un backend gestionado). Nunca en el portátil de un ingeniero ni en el repositorio Git, porque suele contener secretos.
¿La IaC ayuda a cumplir ISO 27001 o el RGPD?
Sí. El control de cambios revisable y trazable que aporta encaja con los requisitos de ISO/IEC 27001, y codificar cifrado, segmentación y control de acceso en los manifiestos materializa el principio de protección de datos desde el diseño del artículo 25 del RGPD.
Conclusión: la infraestructura reconstruible es la infraestructura resiliente
La prueba de fuego de un proyecto de IaC bien hecho es brutalmente simple: si mañana se pierde una región entera de tu proveedor de nube, ¿puedes reconstruir todo tu entorno desde el código en cuestión de horas, sin que nadie recuerde de memoria qué había configurado a mano? Cuando la respuesta es sí, has eliminado el síndrome del copo de nieve y has convertido la recuperación ante desastres de una pesadilla improvisada en un procedimiento ejecutable. En Summum Sistemas defendemos la IaC no por modernidad, sino porque transforma la infraestructura en un activo que se revisa como código, se audita como código y se reconstruye como código. El estado remoto y bloqueado, el flujo de plan-revisión-aplicación en CI/CD y la seguridad codificada desde el diseño no son adornos: son lo que convierte un montón de servidores frágiles en una plataforma que tu equipo se atreve a cambiar sin miedo. Y un equipo que no teme a su propia infraestructura es un equipo que entrega más rápido y duerme mejor.