Infraestructura como Código: por qué tu equipo no puede seguir aprovisionando a mano

Imagina que un nuevo miembro se une a tu equipo. Le preguntas cómo reproducir el entorno de producción y te dice: "Tienes que entrar a la consola de AWS, ir a EC2, crear una instancia con esta AMI, luego ir a RDS, crear una base de datos con estas opciones... hay unos 40 pasos, te lo escribo en un Notion."

Ese Notion va a estar desactualizado en tres semanas. Y cuando alguien lo siga, el entorno no va a ser idéntico al original. Y cuando haya un fallo en producción a las 2 de la mañana, nadie va a poder reproducir el entorno en tiempo récord.

Eso es la deuda técnica silenciosa de aprovisionar infraestructura a mano. No explota hoy. Explota en el peor momento posible.

¿Qué es Infraestructura como Código?

La Infraestructura como Código (IaC) es la práctica de definir y gestionar toda tu infraestructura —servidores, redes, bases de datos, permisos, balanceadores— mediante archivos de código que viven en un repositorio Git, igual que el código de tu aplicación.

En lugar de hacer clic en una consola o ejecutar comandos ad-hoc en terminales, describes el estado deseado de tu infraestructura en un fichero declarativo. La herramienta se encarga de hacer que la realidad coincida con ese estado.

Por qué tu equipo necesita IaC ahora

Estos son los síntomas más comunes de equipos que todavía aprovisionan a mano:

• Snowflake servers: cada servidor es ligeramente diferente. Nadie sabe exactamente qué tiene instalado ni por qué.
• Configuration drift: producción y staging divergen con el tiempo. Los bugs que no se reproducen en staging son un clásico.
• Bus factor 1: solo una persona sabe cómo está montada la infraestructura. Si se va de vacaciones, rezan.
• Auditorías imposibles: nadie puede responder "¿qué cambió en la infraestructura la semana pasada?"
• Escalado manual: levantar un nuevo entorno lleva días en lugar de minutos.

Las principales herramientas de IaC

No existe una única herramienta de IaC. La elección depende de tu stack, tu equipo y tu proveedor cloud. Estas son las más relevantes:

Terraform

El estándar de facto para IaC multi-cloud. Usa HCL (HashiCorp Configuration Language), tiene un ecosistema de providers enorme y es agnóstico de proveedor. Es la opción más segura si trabajas con AWS, Azure y GCP simultáneamente.

Su gran ventaja es el state management: Terraform guarda el estado actual de tu infraestructura y calcula el diff entre lo que hay y lo que quieres. Su gran riesgo también: si el state se corrompe o se pierde, tienes un problema serio.

Pulumi

Si tu equipo ya domina TypeScript, Python o Go, Pulumi es una alternativa muy atractiva. En lugar de aprender HCL, escribes infraestructura en el lenguaje que ya conoces, con loops reales, funciones, tests unitarios y todas las abstracciones de un lenguaje de programación.

Ideal para equipos de desarrollo que quieren gestionar su propia infraestructura sin aprender otro DSL.

Ansible

Ansible no es exactamente IaC en el sentido clásico —es más una herramienta de gestión de configuración— pero complementa muy bien a Terraform. Terraform crea los recursos, Ansible los configura. Son complementarios, no competidores.

AWS CDK / CloudFormation

Si estás 100% en AWS, CloudFormation es la opción nativa y el CDK permite definir stacks en TypeScript, Python o Java. La ventaja es la integración total con el ecosistema AWS. La desventaja es el lock-in total a un único proveedor.

Cómo adoptar IaC sin parar el mundo

El error más común al adoptar IaC es intentar migrar todo a la vez. La estrategia que funciona:

1. Empieza por los nuevos recursos. No toques lo que funciona. Cualquier recurso nuevo que crees, créalo con Terraform desde el primer día.
2. Importa lo existente de forma gradual. Terraform tiene el comando terraform import para importar recursos existentes al state sin recrearlos.
3. Establece el remote state desde el principio. Nunca guardes el state en local. Usa S3 + DynamoDB en AWS o Terraform Cloud.
4. Añade IaC al pipeline de CI/CD. Cada PR que toque infraestructura debe ejecutar terraform plan y mostrar el diff como comentario.
5. Prohíbe los cambios manuales. Una vez que un recurso está en Terraform, nadie toca la consola. Los cambios manuales crean configuration drift.

Errores frecuentes que vas a cometer (y cómo evitarlos)

• Guardar el state en local: el state de Terraform es el mapa de tu infraestructura. Si lo tienes solo en tu máquina y se pierde, tienes un problema crítico. Usa siempre remote state.
• No versionar los módulos: si usas módulos de Terraform sin versión fija, una actualización upstream puede romper tu infraestructura silenciosamente.
• Secrets en el código: nunca pongas contraseñas, API keys o tokens en tus ficheros de Terraform. Usa AWS Secrets Manager, HashiCorp Vault o variables de entorno.
• No hacer terraform plan antes del apply: el plan te muestra exactamente qué va a cambiar. Leerlo antes de aplicar debería ser un hábito no negociable.

Conclusión

La infraestructura manual no es un problema de velocidad, es un problema de confianza. Confianza en que el entorno es reproducible, en que los cambios son auditables, en que cualquier miembro del equipo puede entender y modificar la infraestructura.

IaC no es una herramienta, es una cultura. Y como toda cultura, el momento ideal para adoptarla fue ayer. El segundo mejor momento es hoy.