Benvingut a la Part III, on aprendràs Terraform i la Infraestructura com a Codi (IaC). Però abans de tocar Terraform, cal entendre quin problema resol. I per això, parlem del «proveïment manual»: la forma tradicional de crear infraestructura, amb tots els seus mals de cap. Quan entenguis aquests problemes, valoraras de veritat per què la IaC ha canviat les regles del joc.

Proveir infraestructura vol dir crear i configurar els recursos que necessita la teva aplicació: servidors, xarxes, bases de dades, permisos…

El proveïment manual és fer-ho a mà, fent clic a la consola web d’AWS. Entres al web, prems «crear instància», omples formularis, configures xarxes a mà, ajustes permisos un a un… És com has estat imaginant fer les coses als capítols anteriors.

Funciona per aprendre o per a una prova ràpida. Però per a projectes reals, té problemes greus.

Crear un entorn complet a mà (xarxa, subxarxes, servidors, base de dades, permisos…) pot portar hores de fer clic en desenes de pantalles. I si necessites un altre entorn igual (per exemple, un de proves idèntic al de producció), has de repetir tot el procés des de zero.

Exemple: El teu cap et demana muntar un entorn de proves idèntic al de producció. A mà, això vol dir recrear minuciosament cada recurs, intentant recordar exactament com vas configurar l’original fa tres mesos. Hores de feina tediosa i propensa a errors.

Quan configures desenes de recursos a mà, és fàcil equivocar-se: oblides marcar una casella, escrius malament un valor, configures un permís de més o de menys. I els errors en infraestructura poden causar caigudes o forats de seguretat.

Exemple real: Configures l’entorn de proves i, sense voler, obres el port SSH a tot internet (l’error del Capítol 4). En producció ho havies fet bé, però en proves t’ho vas oblidar. Ara tens una vulnerabilitat… i ni tan sols ho saps, perquè «creies» que ho havies fet igual.

Quan tot es fa a mà, és impossible garantir que dos entorns siguin idèntics. Amb el temps, algú fa un canvi ràpid en producció «per arreglar alguna cosa» i no el replica en proves. Els entorns divergeixen silenciosament.

Això causa el clàssic: «en proves funciona, però en producció falla» (o al revés). El motiu és que, en realitat, no eren iguals, encara que ningú ho sabés. A aquesta divergència se li diu drift (deriva de configuració).

Amb el proveïment manual, ningú sap amb certesa què hi ha desplegat, qui ho va crear, quan ni per què. El coneixement viu al cap de qui ho va muntar (o en notes disperses).

Exemple: Trobes un servidor encès que costa diners cada mes. Ningú recorda per a què és ni si es pot apagar. L’apagues i arrisques trencar alguna cosa, o el deixes pagant «per si de cas»? Sense documentació, vas a cegues.

• No hi ha revisió: un canvi fet a mà no passa per cap control. Una persona pot modificar producció sense que ningú ho revisi.
• No hi ha historial: no existeix un registre de «què va canviar i quan», com sí passa amb el codi.
• No hi ha marxa enrere fàcil: si un canvi trenca alguna cosa, no hi ha un botó de «desfer». Has de recordar i revertir cada pas a mà.

Quan sou diverses persones, el proveïment manual esdevé un caos:

• Dues persones poden canviar el mateix alhora i trepitjar-se.
• Ningú sap què ha tocat cadascú.
• L’«expert que ho va muntar» es converteix en un coll d’ampolla (i un risc si marxa de l’empresa).

Si t’hi fixes, tots aquests mals comparteixen una causa: la infraestructura no està escrita ni registrada en cap lloc fiable. Està «feta a mà» i existeix només a la consola d’AWS i a la memòria de les persones.

I si poguéssim descriure tota la nostra infraestructura en arxius de text, com si fos codi? Llavors podríem:

• Reutilitzar-la (crear entorns idèntics a l’instant).
• Versionar-la (historial de canvis, com a Git).
• Revisar-la (que una altra persona validi abans d’aplicar).
• Revertir-la (tornar a una versió anterior).
• Documentar-la automàticament (el codi ÉS la documentació).

Aquesta idea és exactament la Infraestructura com a Codi, i és el que veurem a la resta de la Part III.

• El proveïment manual (crear infraestructura fent clic a la consola) serveix per aprendre, però no per a projectes seriosos.
• Els seus problemes: és lent i repetitiu, propens a errors, provoca drift (entorns que divergeixen), no deixa registre de què existeix, i no escala en equip.
• La causa arrel: la infraestructura no està escrita en cap lloc fiable, només a la consola i a la memòria de les persones.
• La solució és descriure la infraestructura en arxius de text (codi): reutilitzable, versionable, revisable i reversible. Això és la Infraestructura com a Codi.

Al següent subcapítol veurem un matís clau de la IaC: la diferència entre l’enfocament declaratiu i l’imperatiu, i per què Terraform tria el declaratiu.