Infraestructura como código e infraestructura inmutable

Qué es la infraestructura como código

La infraestructura como código (IaC) consiste en definir las redes, las máquinas virtuales, los clústeres, las bases de datos, las colas, los registros DNS, los permisos y cualquier otra pieza de infraestructura en archivos de texto guardados en control de versiones, y dejar que las herramientas creen y modifiquen los recursos reales a partir de esos archivos. En lugar de que un ingeniero vaya haciendo clic en una consola de la nube, un cambio es un commit: revisado en un pull request, probado en un pipeline, aplicado automáticamente y registrado para siempre.

La idea es anterior a la nube pública. CFEngine (1993), de Mark Burgess, gestionaba máquinas Unix a partir de políticas declarativas; Puppet (2005), Chef (2009) y Ansible (2012) generalizaron la gestión de la configuración. La nube la hizo imprescindible, porque la propia infraestructura pasó a estar disponible mediante API: AWS CloudFormation (2011) y Terraform (2014), de HashiCorp, describen entornos completos, no solo el software de los servidores. El libro de Kief Morris Infrastructure as Code, ya en su tercera edición (2025), es la referencia estándar sobre la práctica y sus principios.

Los beneficios son los de la ingeniería de software aplicada a la infraestructura. Los entornos se vuelven reproducibles: staging puede construirse a partir de las mismas definiciones que producción, y una región puede reconstruirse tras un desastre a partir del código y no de la memoria. Los cambios se vuelven revisables y auditables, algo que valoran los reguladores y los equipos de seguridad. El conocimiento deja de vivir en la cabeza de un solo ingeniero. Y la velocidad aumenta, porque crear un entorno para un nuevo servicio de reparto de comida pasa a ser un pull request en lugar de una solicitud que espera dos semanas.

Declarativo frente a imperativo

Un enfoque imperativo enumera los pasos: crear una red, luego una subred, luego una base de datos y después abrir este puerto. Ejecutar el script dos veces intenta crearlo todo dos veces. Un enfoque declarativo describe el estado final, el estado deseado de la Sección 10.2: una red con estas subredes, una base de datos de este tamaño, un firewall que permite este puerto. La herramienta compara la descripción con lo que existe y deduce los pasos, de modo que aplicarla dos veces no cambia nada la segunda vez. Esa propiedad, la idempotencia, es lo que hace que el código de infraestructura pueda ejecutarse de forma segura una y otra vez, y de forma automatizada.

La mayoría de las herramientas maduras son declarativas en su núcleo, pero difieren en el lenguaje con el que se escribe la declaración y en quién lleva la cuenta de lo que existe. La tabla resume las principales familias.

Las herramientas y la bifurcación OpenTofu

Terraform se convirtió en la herramienta multinube más usada porque un solo lenguaje y un solo flujo de trabajo cubren miles de proveedores: AWS, Azure, Google Cloud, Cloudflare, Kubernetes, GitHub, servicios de monitorización y muchos más. El 10 de agosto de 2023, HashiCorp pasó Terraform de la licencia de código abierto Mozilla Public License 2.0 a la Business Source License 1.1, que permite el uso interno y comercial pero prohíbe ofrecerlo en productos que compitan con los de HashiCorp. La versión 1.5.7 fue la última lanzada con la licencia anterior.

La respuesta de la comunidad fue una bifurcación. A los pocos días apareció un manifiesto que pedía volver al código abierto; en septiembre de 2023, la Linux Foundation aceptó la bifurcación con el nombre de OpenTofu; su primera versión estable, la 1.6.0, llegó en enero de 2024; y en 2025 fue aceptada en la CNCF como proyecto sandbox. IBM completó la adquisición de HashiCorp en febrero de 2025. Las dos herramientas siguen siendo en gran medida compatibles en lenguaje y proveedores, pero sus funcionalidades divergen: OpenTofu añadió, por ejemplo, el cifrado del estado en el lado del cliente, mientras que la plataforma comercial de Terraform añadió capacidades propias. Para un arquitecto, el episodio recuerda que la licencia y la gobernanza de una herramienta forman parte de su perfil de riesgo, y que los estándares abiertos y una alternativa creíble mantienen ese riesgo bajo control.

Entre las herramientas para una sola nube, AWS CloudFormation (2011) y Bicep de Microsoft (presentado en 2020, que se compila a plantillas de Azure Resource Manager) los ejecuta el propio proveedor, que lleva la cuenta de lo que existe, así que no hay ningún archivo de estado que gestionar, a cambio de quedar atado a una sola nube. Pulumi (2018) y AWS CDK permiten a los desarrolladores escribir la infraestructura en lenguajes de propósito general; Crossplane amplía Kubernetes para gestionar recursos en la nube mediante reconciliación. La elección correcta depende de qué nubes uses, de las habilidades de tu equipo, de la madurez de los proveedores que necesites, de la política de licencias y de lo que ya utilice el resto de la organización; la coherencia entre equipos suele valer más que los méritos marginales de cualquier herramienta concreta.

terraform {
  required_version = ">= 1.6"
  backend "gcs" {                 # remote state; this backend locks natively
    bucket = "fd-infra-state"
    prefix = "orders/prod"
  }
}

variable "environment" { type = string }

module "orders_db" {
  source      = "git::https://git.example.com/modules/postgres.git?ref=v3.2.0"
  name        = "orders-${var.environment}"
  size        = var.environment == "prod" ? "large" : "small"
  high_avail  = var.environment == "prod"   # standby in a second zone
  backup_days = 14
}

output "orders_db_host" {
  value = module.orders_db.host
}

Ejecutar tofu plan (o terraform plan) muestra qué cambiaría antes de que ocurra nada. El plan es el artefacto más importante del flujo de trabajo: los revisores lo leen en el pull request, junto al código, y es lo que se aplica.

  # module.orders_db.google_sql_database_instance.this will be updated in-place
  ~ resource "google_sql_database_instance" "this" {
      ~ settings {
          ~ tier = "db-custom-2-8192" -> "db-custom-4-16384"
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Estado, bloqueo y deriva

Las herramientas declarativas necesitan saber qué recursos reales corresponden a qué definiciones. Terraform y OpenTofu guardan esto en el estado: un archivo que asocia cada recurso del código con el identificador del objeto real, junto con sus últimos atributos conocidos. Planificar compara tres cosas: el código (lo que debería existir), el estado (lo que creó la herramienta) y la infraestructura real, leída de la API del proveedor (lo que existe de verdad).

El estado requiere cuidado porque es crítico y sensible. Debe guardarse en remoto (en almacenamiento de objetos o en un servicio gestionado), no en una computadora portátil, para que todo el equipo y el pipeline compartan una única versión. Debe estar bloqueado durante los cambios, para que dos aplicaciones no se intercalen y lo corrompan. Debe tener copias de seguridad y versiones, porque un archivo de estado perdido deja a la herramienta sin saber qué recursos creó. Y es un secreto: el estado contiene a menudo contraseñas de bases de datos y claves en texto plano, así que el acceso a él debe restringirse y debe cifrarse en reposo (OpenTofu también puede cifrarlo en el lado del cliente).

La deriva es cualquier diferencia entre el código y la realidad, normalmente por cambios manuales hechos con prisas, por otra herramienta que modifica el mismo recurso o por un fallo parcial durante la aplicación. La deriva es peligrosa porque la siguiente aplicación puede revertir en silencio un cambio del que alguien dependía, o fallar en producción por una diferencia cuya existencia nadie conocía. Los equipos la detectan ejecutando un plan de forma programada (por ejemplo, cada noche) y alertando ante cualquier cambio propuesto, y la previenen restringiendo el acceso de escritura a la consola a un procedimiento de emergencia (break-glass) registrado.

El estado también define el radio de impacto. Un único estado gigante para toda una empresa significa que cada plan es lento, cada aplicación lo arriesga todo y un solo bloqueo frena a todos los equipos. Dividir el estado por componente y entorno (la red, el clúster compartido, los recursos de cada servicio; producción separada de staging) mantiene los planes rápidos y los fallos contenidos, a cambio de tener que pasar salidas, como los identificadores de red, entre estados. La refactorización está soportada: los bloques moved renombran recursos sin destruirlos, e import pone bajo gestión los recursos existentes creados a mano.

Módulos y entornos

Un módulo es una unidad reutilizable de código de infraestructura con entradas y salidas: una base de datos PostgreSQL con copias de seguridad y monitorización, la red y el balanceador de carga de un servicio, un namespace estándar de Kubernetes con sus cuotas y políticas. Un buen módulo aplica la ocultación de información del Capítulo 3: una interfaz pequeña (nombre, tamaño, alta disponibilidad o no) delante de los muchos detalles específicos del proveedor que un equipo de servicio no debería tener que conocer. Los módulos se versionan y se lanzan como bibliotecas, y los entornos hacen referencia a una versión concreta, como hace el ref=v3.2.0 del ejemplo, para que un cambio en un módulo llegue a producción solo cuando alguien lo actualice deliberadamente.

Los entornos deben construirse a partir de los mismos módulos con entradas diferentes, no a partir de código copiado. Una organización habitual es un directorio (o repositorio) por entorno y componente, cada uno con su propio estado, que llama a módulos compartidos y versionados; un cambio se promueve actualizando la versión o las entradas del módulo en staging y después en producción. Los entornos hechos a base de copiar y pegar divergen en cuestión de meses, hasta que staging deja de predecir lo que pasará en producción. Los workspaces, que dan a una configuración varios estados, encajan mejor con copias de corta duración, como los entornos de prueba por rama, que con producción y staging, que duran mucho.

Cuidado con el exceso de abstracción. Un módulo con cuarenta entradas booleanas que intenta servir a todos los equipos es tan difícil de cambiar como el código al que sustituyó. Es preferible tener unos pocos módulos con criterio propio que plasmen los estándares de la organización, que es exactamente lo que un equipo de plataforma ofrece como camino dorado en la Sección 10.7.

Infraestructura inmutable frente a gestión de la configuración

Las herramientas de gestión de la configuración mantienen servidores de larga duración en un estado descrito: Ansible se conecta por SSH y aplica los cambios sin agente; Chef y Puppet ejecutan agentes que obtienen su configuración y convergen hacia ella periódicamente. Funcionan, pero cada servidor acumula historia: paquetes instalados durante un incidente, archivos editados a mano, actualizaciones aplicadas a medias. Martin Fowler llamó al resultado servidor copo de nieve (snowflake server), único e imposible de reproducir, y propuso como remedio el servidor fénix (phoenix server), que se quema y se reconstruye desde cero con regularidad.

La infraestructura inmutable, un término popularizado por Chad Fowler en 2013, lleva el remedio hasta sus últimas consecuencias: no modificar nunca un servidor en ejecución. Cada cambio, ya sea un lanzamiento de la aplicación o un parche del sistema operativo, se hace construyendo una imagen nueva (una imagen de contenedor, o una imagen de máquina con una herramienta como Packer), probándola y sustituyendo las instancias antiguas, normalmente mediante un despliegue gradual o azul-verde. Los contenedores en Kubernetes son inmutables por defecto. Los beneficios son la ausencia de deriva, instancias idénticas, entornos trivialmente repetibles y el rollback mediante el redespliegue de la imagen anterior; los costos son un pipeline de imágenes, la necesidad de procesos desechables y sin estado (Sección 10.3) y una respuesta más lenta para un único cambio urgente.

La gestión de la configuración no ha desaparecido. Sigue siendo la herramienta adecuada para los parques de sistemas que no pueden sustituirse en bloque: servidores locales (on-premises), equipos de red, bases de datos en hardware dedicado y las propias imágenes base, que a menudo se construyen ejecutando Ansible dentro de la compilación de la imagen. La regla arquitectónica es llevar la mutabilidad lo más abajo y lo antes posible: configurar al construir las imágenes y después tratar lo que se ejecuta como de solo lectura.

GitOps

GitOps aplica el bucle de reconciliación de la Sección 10.2 a entornos completos. El término lo acuñó en 2017 Alexis Richardson, de Weaveworks, la empresa que creó la herramienta Flux. El proyecto OpenGitOps, un grupo de trabajo de la CNCF, define cuatro principios: el estado deseado es declarativo; está versionado y es inmutable, con un historial completo; lo obtienen automáticamente agentes de software; y se reconcilia continuamente, con agentes que observan el estado real y aplican el deseado. Los dos agentes principales, Argo CD y Flux, son proyectos graduados de la CNCF; Flux continuó como proyecto comunitario después de que Weaveworks cerrara en 2024.

El modelo pull tiene una ventaja de seguridad frente a un pipeline que empuja los cambios al clúster: el sistema de CI no necesita credenciales de producción, porque el agente dentro del clúster va a buscar lo que debe ejecutar. Git se convierte en el registro de auditoría y en la interfaz para los cambios, también para las operaciones: escalar un servicio o hacer rollback es un commit revisado o un revert. La deriva se corrige automáticamente, así que un kubectl edit manual dura solo hasta la siguiente sincronización.

GitOps trae sus propias preguntas de diseño. Los secretos no deben estar en Git en texto plano; los equipos los cifran (SOPS, Sealed Secrets) o guardan referencias que External Secrets Operator resuelve a partir de un gestor de secretos. La promoción entre entornos necesita una convención, como un directorio por entorno con pull requests que copian un nuevo digest de imagen de staging a producción. La corrección automática de la deriva debe pausarse deliberadamente durante algunas emergencias, y la estructura del repositorio debe reflejar la propiedad para que los equipos puedan cambiar sus propios servicios sin tocar los de otros. GitOps es lo más natural para Kubernetes, pero los mismos principios se aplican a la infraestructura en la nube mediante Crossplane o mediante pipelines que planifican y aplican el código de infraestructura a partir de los commits fusionados.

Política como código

La política como código expresa las reglas sobre la infraestructura como código comprobable por máquina en lugar de como una página de wiki: los buckets de almacenamiento no deben ser públicos, las bases de datos deben estar cifradas y tener copias de seguridad, todo recurso debe llevar una etiqueta de propietario y de centro de costos, solo pueden usarse regiones aprobadas, los contenedores no deben ejecutarse como root, las imágenes de producción deben venir del registro de la empresa. Las comprobaciones se ejecutan en varios puntos: sobre el plan en el pull request (Open Policy Agent con Conftest, Checkov, HashiCorp Sentinel en sus productos comerciales), en la admisión en un clúster de Kubernetes (OPA Gatekeeper, Kyverno) y de forma continua sobre los recursos en ejecución (los servicios de políticas de los proveedores de nube).

La política como código convierte la gobernanza, que deja de ser una reunión de revisión, en una salvaguarda rápida y coherente que se explica a sí misma en el pull request. Funciona mejor cuando las políticas son pocas, están claramente justificadas, versionadas y probadas como cualquier código, cuando empiezan en modo de advertencia antes de bloquear y cuando existe un proceso de excepciones registrado. El Capítulo 11 trata cómo encajan estas comprobaciones automatizadas en la gobernanza de la arquitectura (gobernanza en organizaciones ágiles).