Durant vuit mòduls has vist la plataforma de Contoso Airlines per parts. Cada lliçó va presentar una peça, la va justificar i la va deixar funcionant: una xarxa aquí, una base de dades allà, una canalització, una alerta, un pressupost. És l'única manera d'aprendre una plataforma —ningú no entén cinquanta serveis alhora—, però no és la manera en què la plataforma existeix. En producció tot està connectat amb tot, i el dia que alguna cosa falla ningú no té temps de reconstruir mentalment vuit mòduls: cal un plànol.

Aquesta lliçó dibuixa aquest plànol sencer i ensenya a llegir-lo. No torna a explicar què és App Service ni com funciona Cosmos DB: això ja ho saps. El que fa és mostrar el conjunt i el criteri: per on entra una petició i per on surt, què parla amb què i a través de què, per què cada peça és aquesta i no una altra, quant costa el resultat, quines tres versions diferents d'aquesta mateixa arquitectura tindrien sentit en altres contextos, i què faria l'equip diferent si comencés avui amb el que sap ara.

És la lliçó més important del mòdul, perquè llegir una arquitectura de conjunt —veure el punt únic de fallada, l'acoblament innecessari, la peça que sobra— és exactament el que separa qui coneix serveis de qui dissenya sistemes.

Recordatori: totes les xifres en euros són orientatives i fictícies, i els noms de recursos pertanyen a un cas d'estudi inventat. Els preus reals varien per regió i canvien amb freqüència.

1. Com es llegeix un plànol d'arquitectura
2. El plànol complet de Contoso Airlines
3. Lectura per zones
4. El recorregut d'una reserva, d'extrem a extrem
5. La taula mestra de decisions
6. Els números de la plataforma
7. Tres variants de la mateixa arquitectura
8. La retrospectiva honesta: què faríem diferent avui
9. Arquitectures de referència i l'Azure Architecture Center
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Un diagrama d'arquitectura útil no és un inventari d'icones: és un mapa de fluxos i fronteres. Es llegeix sempre en el mateix ordre, i val la pena interioritzar-lo perquè serveix per a qualsevol plataforma, no només per a aquesta:

1. Per on entra el trànsit? Tot el que ve d'internet té un únic punt d'entrada legítim. Si n'hi ha dos, un dels dos és un forat.
2. On són les fronteres de confiança? La vora pública, la xarxa privada, la subxarxa de dades. Cada creuament de frontera és un control: WAF, tallafoc, NSG, punt de connexió privat.
3. Què és síncron i què és asíncron? Una fletxa contínua significa que si el destí cau, l'origen falla. Una fletxa per cua o esdeveniment significa que si el destí cau, la feina espera. És la distinció que més determina la resiliència real.
4. On viu l'estat? El còmput es pot recrear en minuts; les dades no. Tot el que guarda estat necessita còpia, rèplica i pla de recuperació.
5. Qui observa el conjunt? La plataforma d'operació no participa en el flux, però el creua sencer.
6. Què impedeix crear el que no ha d'existir? La governança no és al flux: és per sobre, en la jerarquia de subscripcions.

El plànol de l'apartat següent està dibuixat exactament en aquest ordre, de dalt a baix.

Les fletxes contínues són flux de petició o de dades; les discontínues, dependències de plànol de control: identitat, secrets, telemetria, còpies. És una distinció deliberada: si kv-contoso-pro deixa de respondre, l'aplicació no cau a l'instant —els secrets són a la memòria cau—, però si cosmos-contoso-tarifas-pro deixa de respondre, la cerca de vols falla a l'acte.

I per sobre de tot el dibuix, sense aparèixer-hi, hi ha la jerarquia de governança, que no participa en cap flux però determina què es pot crear:

Un únic punt d'entrada: fd-contoso-global. Tota la resta està tancada a internet. Front Door acaba el TLS al punt de presència més proper al passatger, aplica el WAF wafcontosoglobal abans que la petició arribi a cap aplicació, guarda a la memòria cau el que és estàtic i encamina a la regió sana. Les aplicacions només accepten trànsit procedent de Front Door, cosa que converteix el WAF en obligatori i no en opcional. Mòdul 2 (lliurament global) i mòdul 4 (WAF).

Quatre models de còmput convivint, i això no és incoherència sinó adequació:

És la zona que fa que la plataforma no caigui sencera quan alguna cosa falla. sb-contoso-pro desacobla la confirmació de la reserva de tot el que passa després: el tema reservas-confirmadas reparteix a tarjetas, facturacion i fidelizacion, tres consumidors que no es coneixen entre ells i que poden estar caiguts sense impedir una venda. evgt-contoso-reservas-pro propaga esdeveniments discrets, logic-contoso-retrasos-pro orquestra l'avís als passatgers amb connectors en lloc de codi, i evhns-contoso-telemetria-pro absorbeix el raig de telemetria cap a analítica. Mòdul 6.

Cinc motors, un per forma de dada: SQL per a transaccions de reserva, Cosmos DB per a tarifes de lectura massiva i global, MySQL per al portal de continguts heretat, PostgreSQL per a tripulacions, i el llac amb Synapse per a analítica. Tots accessibles només per punt de connexió privat. És l'estat, i per això és on es concentren les còpies, les rèpliques i el pla de recuperació. Mòdul 3 i mòdul 7.

log-contoso-pro és una àrea única on conflueix tot: aplicacions, plataforma, seguretat i activitat. Sobre ella s'apuntalen les alertes, ag-guardia-contoso, els taulers i les consultes KQL. I per sobre, la iniciativa Base de gobernanza de Contoso impedeix crear un recurs sense etiquetes, fora de les regions permeses, amb blobs públics o sense HTTPS. Mòduls 4 i 7.

Aquest és el flux que justifica l'existència de tota la plataforma: una passatgera busca un vol Barcelona–Palma i acaba amb la seva targeta d'embarcament al correu.

L'important del diagrama és on acaba la resposta al passatger: al pas 13. Tot el que ve després passa per darrere, i aquesta frontera és la decisió d'arquitectura més valuosa de tota la plataforma. Si la generació de targetes falla, la venda ja està feta i el missatge es reintenta.

Tota arquitectura és una llista de decisions amb la seva alternativa descartada. Aquesta és la de Contoso, completa:

L'arquitectura de Contoso no és *l'*arquitectura correcta: és la correcta per a Contoso. Canvia el context i canvia el plànol.

Què es treu a la versió mínima: tallafoc, bastió, VMSS, AKS, Synapse, segona regió i la major part de la governança; es conserven MFA, còpies, HTTPS obligatori, secrets fora del codi i etiquetes, perquè això no és luxe, és higiene. Què s'afegeix a la de gran empresa: segona regió activa amb Cosmos DB d'escriptura múltiple, grups de commutació automàtica, aparellament global, equip de guàrdia continu i una factura tres o quatre vegades més gran; es compra latència baixa global i RTO de minuts, i es paga amb complexitat operativa, que és el cost que ningú no pressuposta. Què caracteritza la regulada: l'arquitectura amb prou feines canvia de forma, canvia en restriccions —on pot ser la dada, qui la pot veure, quant de temps es conserva l'evidència— i en el fet que cada decisió necessita justificació documental. En els tres casos el plànol és recognoscible: és la mateixa forma amb més o menys peces.

Cap plataforma real no surt bé a la primera. Aquestes són les coses que la Marta, en Diego i la Nuria farien d'una altra manera:

• Etiquetar des del minut u, amb directiva. Les etiquetes van arribar tard i es van haver de retroetiquetar desenes de recursos a mà per poder repartir la factura. La directiva hereda-centro-coste hauria d'haver existit abans que el primer grup de recursos.
• Començar per la zona d'aterratge, no per la primera màquina. La jerarquia de grups d'administració i la iniciativa de governança es van muntar quan ja hi havia recursos a dins. És molt més barat a l'inrevés.
• No crear vm-motor-disponibilidad-dev. Va néixer com a prova ràpida i va sobreviure un any sobredimensionada. Avui seria un contenidor des del primer dia.
• Bicep abans que el portal. Els primers recursos es van crear a mà i després es van haver d'escriure en plantilles a posteriori, amb les diferències subtils que això arrossega.
• Pressupost i alerta de cost el mateix dia que la primera subscripció. La factura duplicada del primer trimestre es va detectar tard només perquè ningú no ho mirava, i l'intent de separar Log Analytics per equip va costar dues setmanes de desfer.
• Menys serveis diferents. Conviuen MySQL i PostgreSQL per raons històriques; si es comencés avui, seria un sol motor relacional a més de SQL.

La conclusió que l'equip va escriure a la seva retrospectiva és la que convé endur-se: gairebé tots els errors van ser d'ordre, no d'elecció. Les peces eren les adequades; el que va costar diners va ser muntar-les en la seqüència equivocada.

No cal inventar cada plànol des de zero. L'Azure Architecture Center publica arquitectures de referència revisades, amb diagrama, components, consideracions per pilar del Well-Architected Framework i, en molts casos, plantilles desplegables:

Com fer-les servir bé: comença per la referència, treu-li el que no necessites i anota per què. La referència està dissenyada per al cas exigent; copiar-la sencera en una organització petita produeix una plataforma cara i inoperable. El valor no és al dibuix, és a la llista de consideracions que l'acompanya.

• Confondre un diagrama amb documentació. Un plànol sense la taula de decisions no explica res: d'aquí a un any ningú no recordarà per què Cosmos i no SQL.
• Dibuixar el diagrama una vegada. Un plànol desactualitzat és pitjor que cap, perquè indueix a error durant un incident. Viu a contoso-infra, al costat de les plantilles.
• Dibuixar-ho tot en un únic diagrama il·legible. Un de general i uns quants de detall: xarxa, flux de reserva, governança. Cadascun respon a una pregunta.
• No distingir fletxes síncrones d'asíncrones. És la informació més important del plànol i la que més s'omet.
• Copiar una arquitectura de referència sencera. Està pensada per al cas més exigent; adapta i documenta el que treus. I recorda que més serveis no és millor arquitectura: cadascun afegeix cost d'operació, no només factura.
• Consell: mantén una taula de decisions d'arquitectura amb data, alternativa descartada i motiu. És el document més valuós d'una plataforma i el que ningú no escriu.
• Consell: revisa el plànol després de cada incident, i tingue'l a mà a les guàrdies. Els incidents ensenyen on estava mal dibuixat.

Exercici 1. Mirant el plànol general i el diagrama de seqüència, identifica els tres punts de fallada més greus de la plataforma de Contoso: per a cadascun, què deixa de funcionar exactament, si la fallada és total o parcial, i què caldria per mitigar-la amb el seu cost aproximat. Ordena'ls per impacte en el negoci, no per gravetat tècnica.

Exercici 2. Una cadena hotelera de 40 empleats vol un portal de reserves amb cerca, pagament i confirmació per correu, amb unes 8.000 reserves al mes i pressupost màxim de 1.200 €/mes. Dissenya la seva arquitectura partint del plànol de Contoso: què conserves, què elimines i què substitueixes per una alternativa més barata. Justifica quines tres coses no eliminaries mai encara que el pressupost baixés a 600 €.

Exercici 3. Contoso vol vendre a Llatinoamèrica i l'equip proposa actiu-actiu amb Cosmos DB d'escriptura múltiple. Analitza la proposta: quin problema resol realment, quins problemes nous crea —especialment amb db-reservas—, quina alternativa més barata cobriria el 80 % del benefici, i quines preguntes de negoci faries abans de decidir.

Solució 1: ordenats per impacte en el negoci. (1) sql-contoso-reservas-pro / db-reservas: és l'únic punt on la venda és síncrona i insubstituïble; si cau, no es pot confirmar cap reserva —aturada total d'ingressos—, encara que la cerca continuï funcionant perquè les tarifes són a Cosmos. Ja està mitigat parcialment amb redundància de zona i fg-contoso-reservas a North Europe, amb RTO de 4 h; reduir-lo a minuts exigiria commutació automàtica i proves freqüents, amb un cost addicional de l'ordre de 1.200-1.500 €/mes. (2) fd-contoso-global: és l'únic punt d'entrada; si falla el perfil o una regla del WAF bloqueja trànsit legítim, la caiguda és total i instantània encara que tota la resta estigui sana —la fallada més probable no és d'Azure, és una regla mal desplegada, i per això la mitigació real és barata: mode de detecció primer, desplegament per canalització i capacitat de revertir en minuts—. (3) cosmos-contoso-tarifas-pro: si cau, no hi ha cerca de vols, que és el 90 % del trànsit; la fallada és parcial —qui ja té un vol triat podria reservar— però comercialment devastadora; la mitigació és lectura des d'una segona regió, relativament barata, més una memòria cau de tarifes de la ruta popular a la vora. Nota de criteri: la fallada de func-contoso-tarjetas-pro no entra a la llista tot i ser visible per al client, perquè el missatge espera a Service Bus i la venda ja està cobrada: exactament el que es buscava en desacoblar.

Solució 2: es conserva la forma, no la mida. Conservar: App Service —un pla Standard o Premium v1 petit, no Premium v3—, SQL Database sense servidor amb pausa automàtica (8.000 reserves al mes és càrrega baixa i molt irregular), Blob Storage per a justificants, Application Insights, MFA obligatori, HTTPS obligatori, còpies amb retenció raonable, etiquetes i un pressupost amb alertes. Eliminar: Front Door i WAF —se substitueix pel domini propi amb certificat gestionat i, si preocupa l'abús, límit de peticions a l'aplicació—, tallafoc, bastió, VMSS, AKS, Container Apps, Synapse, llac, Event Hubs, segona regió, PIM i la major part de la iniciativa de directives, que es redueix a tres regles —regions permeses, sense blobs públics, només HTTPS—. Substituir: Service Bus per una cua de Storage o directament per Event Grid amb una Function en consum, molt més barat a aquest volum; Cosmos DB no aplica —el catàleg cap a SQL—. Total plausible: 700-900 €/mes, dins del pressupost. Les tres coses que no s'eliminen mai, ni amb 600 €: els secrets fora del codi amb identitat administrada o Key Vault (una filtració no té relació amb la mida de l'empresa), les còpies de seguretat provades (una eliminació accidental tanca una empresa petita, no la incomoda), i MFA amb cap port d'administració obert a internet (l'atac automatitzat no distingeix entre una pime i una aerolínia). Són les tres coses el cost d'omissió de les quals és catastròfic i independent del volum.

Solució 3: què resol realment: latència de lectura per a usuaris llunyans —una cerca des de Bogotà contra West Europe afegeix centenars de mil·lisegons— i, secundàriament, tolerància a la caiguda d'una regió. Quins problemes crea: l'escriptura múltiple a Cosmos obliga a resoldre conflictes, cosa que un catàleg de tarifes tolera però que exigeix una política explícita; i sobretot db-reservas no hi acompanya: SQL Database no és d'escriptura múltiple, així que les reserves continuarien escrivint-se a West Europe i l'usuari de Bogotà tindria cerca ràpida i confirmació lenta, amb el risc afegit d'incoherència entre el que veu i el que pot comprar. Es multipliquen a més el cost de RU/s, la sortida de dades entre regions, la complexitat de desplegament —dos de tot, en dues canalitzacions— i la superfície d'incidents. Alternativa que cobreix el 80 %: afegir una regió de només lectura a Cosmos DB amb lectura des de la regió més propera i consistència Sessió, mantenir l'escriptura a Europa i recolzar-se en Front Door per acostar el que és estàtic i posar a la memòria cau les rutes populars; es guanya gairebé tota la latència percebuda per una fracció del cost i sense conflictes. Preguntes de negoci prèvies: quin volum real s'espera a Llatinoamèrica i en quin termini? Existeix requisit legal de residència de la dada en algun país destí? Quanta pèrdua de conversió atribuïm avui a la latència, mesurada i no suposada? Hi ha equip per operar dues regions actives 24×7? La resposta a l'última sol decidir la discussió.

Ja tens el plànol complet de Contoso Airlines i, més important, el mètode per llegir qualsevol altre: per on entra el trànsit, on són les fronteres de confiança, què és síncron i què asíncron, on viu l'estat, qui observa i què impedeix crear el que no ha d'existir. Has vist les sis zones —vora i lliurament global, aplicació, integració, dades, operació i governança— amb les seves connexions reals, i la distinció entre flux de petició i dependència de plànol de control, que és la que explica per què unes caigudes es noten a l'instant i altres no es noten en absolut.

Has recorregut una reserva d'extrem a extrem, de la cerca a la targeta d'embarcament, travessant Front Door, el WAF, App Service, l'API, Cosmos DB, SQL Database, Service Bus, la funció i l'emmagatzematge, amb la frontera clau ben assenyalada: la resposta al passatger acaba abans que comenci la feina asíncrona. I saps en quin mòdul es va construir cada peça, que és la manera de convertir vuit mòduls solts en un sistema.

Tens la taula mestra de decisions —cada elecció amb la seva alternativa descartada i el seu motiu—, els números de la plataforma —12.550 €/mes, 0,136 € per reserva, 99,9 %, RPO 15 min i RTO 4 h—, tres variants de la mateixa arquitectura per a contextos diferents amb el que es treu i el que s'afegeix en cadascuna, la retrospectiva honesta amb la seva lliçó central —gairebé tots els errors van ser d'ordre, no d'elecció— i l'Azure Architecture Center com a punt de partida per no dibuixar des de zero.

Amb el plànol al davant, la pregunta natural és si està ben dibuixat. La lliçó següent respon a això amb el marc que Microsoft fa servir exactament per a això: l'Azure Well-Architected Framework, els seus cinc pilars —fiabilitat, seguretat, cost, excel·lència operativa i rendiment—, els seus compromisos entre pilars, i una auditoria pilar per pilar d'aquesta mateixa plataforma que dirà què compleix, què no compleix i què es va decidir conscientment no fer.