Tanquem el Capítol 30 ajuntant els dos grans fils del llibre: d’una banda, Terraform (la infraestructura com a codi, que dominem a les Parts II-V) i, de l’altra, l’estructura multi-compte que acabem de veure. La pregunta natural és: si gestionem tota la nostra infraestructura amb Terraform, i ara tenim molts comptes, com apliquem Terraform de manera ordenada a tota aquesta estructura? Aquí és on tot el que hem après convergeix en una pràctica de nivell expert.

Fins ara, implícitament, hem fet servir Terraform sobre un compte. Però una empresa amb l’estructura del subcapítol 30.1 té desenes de comptes (per entorn, equip, projecte). Gestionar la infraestructura de totes elles amb Terraform, de manera coherent i sense caos, requereix aplicar bé les tècniques que ja coneixes. La bona notícia: ja tens totes les peces, només cal combinar-les a escala.

El bonic d’aquest subcapítol és que no hi ha res nou per aprendre: és la culminació de tècniques que ja domines. Repassem-les en el context multi-compte:

Recorda els mòduls (Capítol 18): blocs reutilitzables d’infraestructura. En un entorn multi-compte són essencials: defineixes la teva infraestructura estàndard (una xarxa, una aplicació...) una vegada com a mòdul, i la reutilitzes a tots els comptes que la necessitin. Això garanteix consistència (tots els comptes fan servir la mateixa definició) i evita duplicar codi.

Recorda la importància de l’estat (Capítol 11) i els backends remots (Capítol 20). En multi-compte, cada compte (o cada combinació compte+entorn) ha de tenir el seu propi estat separat, igual que separàvem entorns (Capítol 19). Així, gestionar un compte no afecta els altres: l’aïllament de la infraestructura com a codi reflecteix l’aïllament dels comptes.

Recorda les tècniques per gestionar múltiples entorns (Capítol 19): directoris per entorn, variables per entorn (.tfvars), i eines com Terragrunt (subcapítol 19.3) per mantenir el codi DRY. Aquestes mateixes tècniques s’apliquen ara a múltiples comptes: cada compte és, en certa manera, un altre «entorn» que configurar amb els mateixos patrons de variables i estructura ordenada.

Recorda el CI/CD per a Terraform (Capítol 22): pipelines que apliquen els canvis de manera controlada, amb revisió i plan abans de apply. A escala multi-compte, els pipelines despleguen a cada compte de manera automatitzada i segura, amb els controls adequats (especialment estrictes per als comptes de producció).

El missatge central: gestionar Terraform en multi-compte no requereix màgia nova, sinó aplicar amb disciplina les bones pràctiques que ja coneixes, a més gran escala. Mòduls per reutilitzar, estats separats per aïllar, estructura d’entorns per organitzar, i CI/CD per desplegar amb control.

Analogia: gestionar Terraform en multi-compte és com dirigir una cadena de restaurants amb receptes estandarditzades. No reinventes la cuina a cada local: tens receptes úniques (mòduls) que cada restaurant (compte) segueix igual, garantint la mateixa qualitat a tots. Cada restaurant porta la seva pròpia caixa i cuina (estat separat), així que un problema en un no afecta un altre. Tens un manual d’operacions comú (estructura d’entorns) i un procés estàndard d’obertura de locals nous (CI/CD). El secret no és una tècnica nova, sinó aplicar les mateixes bones pràctiques amb disciplina a tots els locals.

Terraform i Control Tower (subcapítol 30.2) treballen junts, en nivells diferents:

• Control Tower governa l’estructura organitzativa: crea els comptes, aplica els guardrails, munta la landing zone (els «fonaments» i les «normes comunes»).
• Terraform desplega la infraestructura concreta dins de cada compte: les xarxes, els servidors, les aplicacions (el que «construeixes a sobre» dels fonaments).

Tots dos es complementen: un prepara el terreny multi-compte, l’altre construeix a sobre d’una manera reproduïble.

Exemple del món real: una empresa amb 30 comptes gestiona tota la seva infraestructura amb Terraform aplicant les pràctiques que coneix. Tenen una biblioteca de mòduls (xarxa estàndard, aplicació estàndard, base de dades estàndard) versionats (recorda el subcapítol 18.4), que tots els equips reutilitzen: així, la xarxa del compte d’un equip és idèntica en estructura a la d’un altre, sense duplicar codi. Cada compte+entorn té el seu estat separat en backends remots (Capítol 20), de manera que desplegar a dev-equipA mai pot afectar prod-equipB. Fan servir Terragrunt (subcapítol 19.3) per mantenir tot DRY entre comptes, i pipelines de CI/CD (Capítol 22) que apliquen els canvis amb revisió i plan previ, amb aprovacions extra per a producció. El resultat: gestionen 30 comptes amb la mateixa consistència, seguretat i control que tindrien amb un, perquè han aplicat les bones pràctiques amb disciplina a escala. Això és infraestructura com a codi de nivell expert.

• Gestionar Terraform sobre desenes de comptes (multi-compte) requereix aplicar amb disciplina les tècniques que ja coneixes, no aprendre màgia nova. Totes les peces ja les tens.
• Les peces que encaixen:
  • Mòduls (Cap. 18): defineix la infraestructura una vegada i reutilitza-la a tots els comptes → consistència sense duplicar codi.
  • Estat separat per compte (Caps. 11, 20): cada compte amb el seu propi estat → aïllament (canviar-ne un no afecta un altre).
  • Gestió d’entorns (Cap. 19): directoris, .tfvars, Terragrunt → organització ordenada de molts comptes.
  • CI/CD (Cap. 22): pipelines amb revisió i plan → desplegaments controlats a cada compte (estrictes en producció).
• Com una cadena de restaurants amb receptes estandarditzades: mateixes receptes (mòduls), cuina pròpia per local (estat separat), manual comú (entorns), procés d’obertura estàndard (CI/CD).
• Control Tower (governa els comptes/landing zone) i Terraform (construeix la infraestructura dins de cada compte) es complementen en nivells diferents.

Has completat el Capítol 30 i domines l’organització multi-compte i les landing zones! Al Capítol 31, que tanca la Part VII, veurem una disciplina molt actual que porta tot això un pas més enllà: el Platform Engineering i les plataformes internes per a desenvolupadors.