Bienvenido a la Parte III, donde aprenderás Terraform y la Infraestructura como Código (IaC). Pero antes de tocar Terraform, hay que entender qué problema resuelve. Y para eso, hablemos del «aprovisionamiento manual»: la forma tradicional de crear infraestructura, con todos sus dolores. Cuando entiendas estos problemas, valorarás de verdad por qué la IaC ha cambiado las reglas del juego.

Aprovisionar infraestructura significa crear y configurar los recursos que necesita tu aplicación: servidores, redes, bases de datos, permisos…

El aprovisionamiento manual es hacerlo a mano, haciendo clic en la consola web de AWS. Entras en la web, pulsas «crear instancia», rellenas formularios, configuras redes a mano, ajustas permisos uno a uno… Es como has estado imaginando hacer las cosas en los capítulos anteriores.

Funciona para aprender o para una prueba rápida. Pero para proyectos reales, tiene problemas graves.

Crear un entorno completo a mano (red, subredes, servidores, base de datos, permisos…) puede llevar horas de hacer clic en decenas de pantallas. Y si necesitas otro entorno igual (por ejemplo, uno de pruebas idéntico al de producción), tienes que repetir todo el proceso desde cero.

Ejemplo: Tu jefe te pide montar un entorno de pruebas idéntico al de producción. A mano, eso significa recrear minuciosamente cada recurso, intentando recordar exactamente cómo configuraste el original hace tres meses. Horas de trabajo tedioso y propenso a errores.

Cuando configuras decenas de recursos a mano, es fácil equivocarse: olvidas marcar una casilla, escribes mal un valor, configuras un permiso de más o de menos. Y los errores en infraestructura pueden causar caídas o agujeros de seguridad.

Ejemplo real: Configuras el entorno de pruebas y, sin querer, abres el puerto SSH a todo internet (el error del Capítulo 4). En producción lo habías hecho bien, pero en pruebas se te olvidó. Ahora tienes una vulnerabilidad… y ni siquiera lo sabes, porque «creías» que lo habías hecho igual.

Cuando todo se hace a mano, es imposible garantizar que dos entornos sean idénticos. Con el tiempo, alguien hace un cambio rápido en producción «para arreglar algo» y no lo replica en pruebas. Los entornos divergen silenciosamente.

Esto causa el clásico: «en pruebas funciona, pero en producción falla» (o al revés). El motivo es que, en realidad, no eran iguales, aunque nadie lo supiera. A esta divergencia se le llama drift (deriva de configuración).

Con el aprovisionamiento manual, nadie sabe con certeza qué hay desplegado, quién lo creó, cuándo ni por qué. El conocimiento vive en la cabeza de quien lo montó (o en notas dispersas).

Ejemplo: Encuentras un servidor encendido que cuesta dinero cada mes. Nadie recuerda para qué es ni si se puede apagar. ¿Lo apagas y arriesgas romper algo, o lo dejas pagando «por si acaso»? Sin documentación, vas a ciegas.

• No hay revisión: un cambio hecho a mano no pasa por ningún control. Una persona puede modificar producción sin que nadie lo revise.
• No hay historial: no existe un registro de «qué cambió y cuándo», como sí ocurre con el código.
• No hay vuelta atrás fácil: si un cambio rompe algo, no hay un botón de «deshacer». Tienes que recordar y revertir cada paso a mano.

Cuando sois varias personas, el aprovisionamiento manual se vuelve un caos:

• Dos personas pueden cambiar lo mismo a la vez y pisarse.
• Nadie sabe qué tocó cada uno.
• El «experto que lo montó» se convierte en un cuello de botella (y un riesgo si se va de la empresa).

Si te fijas, todos estos dolores comparten una causa: la infraestructura no está escrita ni registrada en ningún sitio fiable. Está «hecha a mano» y existe solo en la consola de AWS y en la memoria de las personas.

¿Y si pudiéramos describir toda nuestra infraestructura en archivos de texto, como si fuera código? Entonces podríamos:

• Reutilizarla (crear entornos idénticos al instante).
• Versionarla (historial de cambios, como en Git).
• Revisarla (que otra persona valide antes de aplicar).
• Revertirla (volver a una versión anterior).
• Documentarla automáticamente (el código ES la documentación).

Esa idea es exactamente la Infraestructura como Código, y es lo que veremos en el resto de la Parte III.

• El aprovisionamiento manual (crear infraestructura haciendo clic en la consola) sirve para aprender, pero no para proyectos serios.
• Sus problemas: es lento y repetitivo, propenso a errores, provoca drift (entornos que divergen), no deja registro de qué existe, y no escala en equipo.
• La causa raíz: la infraestructura no está escrita en ningún sitio fiable, solo en la consola y en la memoria de las personas.
• La solución es describir la infraestructura en archivos de texto (código): reutilizable, versionable, revisable y reversible. Eso es la Infraestructura como Código.

En el siguiente subcapítulo veremos un matiz clave de la IaC: la diferencia entre el enfoque declarativo y el imperativo, y por qué Terraform elige el declarativo.