Tanquem el Capítol 31 (i la Part VII) amb la idea que lliga tot el Platform Engineering: tractar els mòduls de Terraform com un producte intern. Al llarg del llibre hem vist els mòduls com a blocs tècnics reutilitzables (Capítol 18). Ara fem el salt de mentalitat que distingeix les organitzacions més madures: deixar de veure els mòduls com a «codi que comparteixo» i començar a veure'ls com un producte amb clients (els altres desenvolupadors), que es dissenya, es cuida i es millora pensant en ells. Aquest canvi de mentalitat és l'essència del Platform Engineering.

Recorda els mòduls de Terraform (Capítol 18): paquets reutilitzables d'infraestructura que defineixes una vegada i utilitzes moltes. Vam veure la seva anatomia (subcapítol 18.1), les seves variables i outputs (subcapítol 18.2), el seu versionat amb Git tags (subcapítol 18.4)... Tècnicament, ja saps crear-los. El que afegeix aquest subcapítol no és tècnica, sinó mentalitat: com pensar en aquests mòduls quan són la base d'una plataforma que utilitzen molts equips.

La diferència clau entre una organització immadura i una de madura està en com tracta els seus mòduls:

Tractar els mòduls com un producte intern significa aplicar-los la mateixa mentalitat que s'aplica a un producte que vens a clients: pensar en l'experiència de qui l'utilitza, cuidar la qualitat, documentar-lo bé, donar-li suport i millorar-lo contínuament. Els teus «clients» són els altres desenvolupadors de l'empresa.

Analogia: la diferència és com entre deixar eines tirades en un cobert comú i gestionar una bona ferreteria. Al cobert, cadascú tira les seves eines; les trobes com pots, no saps si funcionen, ningú les manté. En una ferreteria ben gestionada, els productes estan organitzats, etiquetats, amb instruccions, algú s'assegura que funcionin i de tenir el que la gent necessita, i t'atenen si tens dubtes. Tractar els mòduls com a producte és passar del cobert a la ferreteria: pensar de veritat en qui els farà servir.

El mòdul ha de ser fàcil d'utilitzar per a algú que no és expert: paràmetres clars, valors per defecte sensats, una interfície senzilla. Et poses a la pell de qui el farà servir i li facilites la vida. Un bon golden path (subcapítol 31.1) neix d'un mòdul dissenyat pensant en el seu usuari.

El mòdul ve amb documentació clara: què fa, com s'utilitza, exemples. Sense bona documentació, un mòdul és difícil d'adoptar (recorda com n'és d'important la documentació, ja ho vam veure amb els mòduls a la Part IV). Un producte sense manual no es ven.

Recorda el versionat (subcapítol 18.4): els mòduls-producte es versionen amb cura, de manera que els canvis no trenquin a qui els utilitza per sorpresa. Si has de fer un canvi important, ho comuniques i ho gestiones com una nova versió, igual que un producte seriós gestiona les seves actualitzacions. Això dóna confiança als equips per dependre dels teus mòduls.

Els mòduls-producte es proven (recorda el testing d'infraestructura, Capítol 21, i el contract testing de mòduls, subcapítol 21.4) per garantir que funcionen bé. Un producte de qualitat és fiable; si els teus mòduls fallen, els equips perden la confiança i tornen a fer-ho tot pel seu compte.

Hi ha algú (l'equip de plataforma) que dona suport als usuaris del mòdul i recull el seu feedback per millorar-lo. Com un producte, evoluciona escoltant els seus usuaris: què els falta, què els costa, què necessiten.

Aquest canvi de mentalitat és, en realitat, el cor de tot el Platform Engineering (Capítol 31). Una Internal Developer Platform no és només «eines»; és un producte intern que l'equip de plataforma ofereix als desenvolupadors com si fossin els seus clients. Els golden paths (subcapítol 31.1), el Service Catalog (subcapítol 31.2) i Backstage (subcapítol 31.3) només funcionen de veritat si al darrere hi ha aquesta mentalitat de producte: cuidar l'experiència, la qualitat i la millora contínua.

Sense aquesta mentalitat, una plataforma interna es converteix en un altre munt d'eines que ningú vol utilitzar. Amb ella, es converteix en quelcom que els equips adopten encantats perquè de veritat els facilita la feina.

Exemple del món real: dues empreses creen mòduls de Terraform per als seus equips. La primera els tracta com a «codi compartit»: els puja a un repositori sense documentació, els canvia sense avisar (trencant altres equips) i ningú dona suport. Resultat: els equips no es refien d'aquests mòduls, prefereixen fer la seva pròpia infraestructura, i la plataforma fracassa. La segona empresa els tracta com a producte intern: cada mòdul està ben documentat amb exemples, versionat amb cura (els canvis mai trenquen per sorpresa), provat, i l'equip de plataforma dona suport i recull feedback per millorar-los. Resultat: els equips adopten els mòduls encantats perquè els estalvien feina i són fiables; la plataforma triomfa, i l'empresa guanya velocitat i consistència. La mateixa tècnica (mòduls), però la mentalitat de producte va marcar la diferència entre l'èxit i el fracàs.

• El salt de les organitzacions madures no és tècnic, sinó de mentalitat: tractar els mòduls de Terraform com un producte intern, no com a simple «codi compartit». Els teus clients són els altres desenvolupadors.
• És la diferència entre eines tirades en un cobert i una ferreteria ben gestionada (organitzada, amb instruccions, mantinguda, amb atenció al client).
• Tractar els mòduls com a producte implica: pensar en l'experiència de l'usuari (fàcils d'utilitzar), documentació de qualitat (amb exemples), versionat acurat (canvis sense trencar, amb confiança, Cap. 18.4), qualitat i testing (fiables, Cap. 21), i suport + feedback (millora contínua escoltant l'usuari).
• Aquesta mentalitat de producte és el cor del Platform Engineering: una Internal Developer Platform (amb els seus golden paths, Service Catalog i Backstage) només triomfa si es tracta com un producte cuidat per als seus clients. Sense ella, la plataforma fracassa; amb ella, els equips l'adopten encantats.

Has completat el Capítol 31 i, amb ell, tota la Part VII (Arquitectures de referència i patrons experts)! Has assolit un nivell de maduresa que pocs dominen: Well-Architected, serverless a escala, plataformes de dades, multi-compte i Platform Engineering. Ja només queda la Part VIII: El camí després del llibre, que et guiarà en el teu desenvolupament professional. Comencem al Capítol 32 amb les certificacions d'AWS.