"¿Quién armó este servidor y por qué tiene esa configuración?" Es una de las preguntas más comunes —y más caras— en cualquier infraestructura que creció a fuerza de clics en una consola web y cambios manuales por SSH. Cada servidor termina siendo un poco distinto al resto, nadie se anima a tocarlo, y reconstruirlo desde cero ante una falla puede tardar días. La infraestructura como código (IaC) existe justamente para eliminar ese problema.
Qué es la infraestructura como código
En vez de crear servidores, redes y bases de datos a mano, se los describe en archivos de texto declarativos: "quiero 2 servidores con estas características, esta red, este balanceador". Una herramienta —en este caso Terraform— lee esa descripción y crea (o modifica) la infraestructura real para que coincida. El archivo queda versionado en git, igual que el código de una aplicación.
Por qué Terraform en particular
Terraform es la herramienta de IaC más usada porque es agnóstica de proveedor: el mismo lenguaje (HCL) sirve para describir infraestructura en AWS, Azure, servidores propios (bare metal), Proxmox, o una combinación de todo eso. Para una pyme con infraestructura híbrida —algo en la nube, algo on-premise— esto evita tener que aprender una herramienta distinta por cada plataforma.
Beneficios concretos, no solo teóricos
- Reproducibilidad: si un servidor se cae, se recrea idéntico en minutos ejecutando el mismo código, en lugar de reconstruir de memoria.
- Revisión antes de aplicar: Terraform muestra un "plan" —qué va a crear, modificar o borrar— antes de ejecutar nada, evitando sorpresas.
- Historial real de cambios: cada modificación de infraestructura queda en el historial de git, con quién la hizo y por qué.
- Entornos consistentes: desarrollo, staging y producción se crean desde el mismo código, con solo cambiar variables — se acaba el "en mi entorno funciona".
Terraform vs. hacerlo a mano
| Aspecto | Configuración manual | Terraform |
|---|---|---|
| Documentación | Desactualizada o inexistente | El código es la documentación |
| Recuperación ante falla | Horas o días, de memoria | Minutos, ejecutando el código |
| Cambios | Clic a clic, sin registro | Versionados en git, revisables |
| Multi-entorno | Cada uno se arma distinto | Mismo código, distintas variables |
Cómo empezar sin frenar la operación diaria
No hace falta migrar toda la infraestructura existente de golpe. El camino habitual en Intelix es: elegir un recurso nuevo (un servidor, una red) y crearlo con Terraform desde el principio, en paralelo a lo que ya existe. Con el tiempo, se van "importando" los recursos existentes al código, uno por uno, sin downtime. En seis a doce meses, la infraestructura crítica queda completamente versionada.
¿Tu infraestructura depende de que una sola persona sepa cómo está armada?
Te ayudamos a llevarla a infraestructura como código, de forma gradual y sin parar la operación.