Había una forma estándar de manejar infraestructura que duró décadas: entrás al servidor por SSH, instalás lo que necesitás, ajustás la configuración, y rezás para que el próximo servidor quede igual.
El problema no era solo el tiempo que tomaba. Era que nunca quedaba igual. Un paso distinto, una versión diferente, una variable de entorno olvidada — y el servidor de staging se comportaba diferente al de producción. El bug que no podías reproducir localmente resultaba ser una diferencia de configuración entre ambientes.
Infrastructure as Code (IaC) es la respuesta a ese problema. Y es conceptualmente simple: la infraestructura se define en archivos de código, esos archivos se versionan en Git, y la infraestructura se crea o modifica ejecutando ese código — no clickeando en una consola ni escribiendo comandos a mano.
Qué cambia con IaC
Consistencia real entre ambientes. Si el mismo archivo define staging y producción, los ambientes son idénticos por construcción — no por disciplina. Las diferencias accidentales de configuración desaparecen porque no hay configuración manual.
Velocidad de deployment. Levantar un ambiente nuevo que antes tomaba días — instalar dependencias, configurar redes, ajustar permisos — pasa a ser cuestión de minutos. El código que define la infraestructura ya existe; solo hay que ejecutarlo.
Historial y rollback. Como cualquier cambio de infraestructura es un commit, tenés el historial completo: quién cambió qué, cuándo, y por qué. Si un cambio rompe algo en producción, revertir es hacer un git revert y volver a aplicar.
Revisión como código. Los cambios de infraestructura pasan por pull request antes de llegar a producción. El mismo proceso que usás para revisar código de aplicación aplica a cambios de red, de permisos, de recursos de cómputo.
Menos error humano. Una tarea automatizada que corre siempre igual es más confiable que una persona siguiendo un runbook, especialmente bajo presión o a las 2 de la mañana.
Las herramientas principales
El ecosistema de IaC tiene cuatro herramientas que dominan el mercado, cada una con un enfoque distinto.
Terraform es la más usada para infraestructura declarativa multi-cloud. Definís el estado final que querés — "quiero tres instancias EC2, una VPC con estas subnets, un load balancer" — y Terraform calcula qué crear, modificar o destruir para llegar ahí. Funciona con AWS, GCP, Azure, y docenas de providers más.
Ansible apunta más a la configuración de servidores que ya existen. En lugar de declarar estado final, escribís tareas en YAML que se ejecutan en orden. Es más imperativo que Terraform — "instalá nginx, habilitá este servicio, copiá este archivo de configuración".
- name: Configurar servidores web
hosts: webservers
tasks:
- name: Instalar nginx
apt:
name: nginx
state: present
- name: Habilitar y arrancar nginx
service:
name: nginx
state: started
enabled: yes
Sin SSH manual. Sin runbooks. Sin "acordate de hacer esto en cada servidor".
Pulumi toma el mismo concepto pero te deja escribir infraestructura en lenguajes de programación reales — TypeScript, Python, Go. Si tu equipo ya sabe programar, la curva de entrada es menor que aprender HCL (el lenguaje de Terraform).
AWS CloudFormation es la opción nativa de AWS — YAML o JSON que define recursos de AWS directamente. No requiere instalar nada extra, integra bien con IAM y otros servicios de AWS, pero está completamente atada al ecosistema de Amazon.
Declarativo vs. imperativo
La distinción más importante en IaC es entre el modelo declarativo y el imperativo.
En el modelo declarativo (Terraform, CloudFormation) describís el resultado que querés. La herramienta se encarga de calcular los pasos para llegar ahí. Si ya existe parte de la infraestructura, solo crea lo que falta.
En el modelo imperativo (Ansible, scripts de shell) describís los pasos que hay que ejecutar. Vos controlás el orden y la lógica. Es más flexible, pero también más frágil — si el estado actual del sistema es distinto al que esperabas, los pasos pueden fallar o producir resultados inesperados.
Para infraestructura de nube (crear y destruir recursos), declarativo es casi siempre mejor. Para configuración de sistemas operativos dentro de un servidor, imperativo tiene su lugar.
Por dónde empezar
Si nunca usaste IaC, el camino más directo es Terraform con AWS — tiene la comunidad más grande, la documentación más completa, y cubre el caso de uso más común.
El primer recurso que crear con Terraform no debería ser complejo. Una instancia EC2, un bucket de S3, o una tabla de DynamoDB — algo pequeño donde entiendas el ciclo completo: escribir la definición, hacer terraform plan para ver qué va a pasar, y terraform apply para crear el recurso.
Lo que importa en esa primera experiencia no es el recurso en sí — es internalizar el modelo mental: la infraestructura es código, el código se versiona, y los cambios se aplican de forma reproducible.
Ese modelo mental es lo que hace que escalar de diez servidores a mil sea un problema de código, no de operaciones manuales.