Fa onze mòduls, MercadoFresco era una botiga en línia amb un servidor que queia els divendres, unes còpies de seguretat que ningú no havia restaurat mai i un desplegament que consistia a copiar fitxers per SSH un dimarts a la nit. Avui té una arquitectura elàstica, segura, observable, desplegable des d'un pipeline, descrita en codi, repartida en cinc comptes, auditada amb mètode i amb una factura que costa un 24,8 % menys del que costava fa dos mesos.

Aquesta lliçó no ensenya cap servei nou. Fa cinc coses: recorre l'arquitectura completa associant cada peça al mòdul on es va aprendre i tanca el balanç dels cinc problemes inicials; planteja el projecte final, que és un repte real amb deu lliurables; ofereix una solució de referència comentada amb les seves alternatives descartades; traça els camins per continuar aprenent, amb les certificacions, els recursos i allò que aquest curs no ha tocat; i tanca el curs amb la llista de neteja de tot el que s'ha creat, perquè ningú no continuï pagant per un laboratori acabat.

Avís de cost. Aquesta lliçó inclou la neteja final de tots els recursos del curs. Si has seguit les pràctiques en un compte real, aquesta secció no és opcional: un clúster d'EKS oblidat costa 73 USD al mes, un grup d'ElastiCache més de 100, i set endpoints de VPC uns 112. L'ordre d'esborrat importa, perquè hi ha dependències. Dades, comptes i identificadors ficticis.

1. L'arquitectura completa de MercadoFresco
2. Cada component i el mòdul on es va aprendre
3. Els cinc problemes i la seva mètrica
4. Errors comuns i consells
5. Exercicis: el projecte final
6. Solucions: l'arquitectura de referència comentada
7. Els camins de certificació d'AWS
8. Recursos oficials per continuar
9. Allò que aquest curs no ha tocat
10. Què saps fer ara
11. La neteja final, en l'ordre correcte
12. Conclusió

El curs va començar amb cinc problemes concrets. Aquest és el balanç, amb números i no amb adjectius:

Cinc problemes, cinc solucions, i en els cinc casos un número que es pot ensenyar. Aquesta és la diferència entre haver migrat al núvol i haver resolt alguna cosa.

Error: creure que l'arquitectura final era l'objectiu des del principi. Ningú no dissenya això d'una tirada. MercadoFresco hi va arribar en onze passos, cadascun resolent un problema concret que feia mal. Consell: quan dissenyis, comença pel problema, no pel diagrama.

Error: copiar aquesta arquitectura tal qual. Té sentit per a una botiga amb aquests volums, aquests problemes i aquest equip. Per a 200 comandes al mes és un disbarat, i per a 200.000 al dia es queda curta. Consell: copia el mètode de decisió, no les caixes del diagrama.

Error: lliurar un projecte d'arquitectura sense números. «Farem servir DynamoDB perquè escala» no és una justificació; «farem servir DynamoDB perquè són 400 escriptures per segon amb accés per clau i latència d'un dígit de mil·lisegons, i el cost estimat és de 22 USD al mes» sí que ho és. Consell: cada decisió, un número.

Error: no escriure les alternatives descartades. L'avaluador —i tu d'aquí a un any— necessita saber què vas considerar i per què ho vas deixar fora. Consell: per cada decisió important, una alternativa descartada amb el seu motiu.

Error: acabar el curs sense esborrar els recursos. És l'error més car de tots i li passa a molta gent. Consell: fes la neteja del final d'aquesta lliçó avui, no «quan tingui una estona».

Consell: el millor projecte no és el que fa servir més serveis, sinó el que justifica millor per què no en fa servir alguns. Descartar Shield Advanced, descartar EKS i descartar Beanstalk van ser tres de les decisions més valuoses d'aquest curs.

Consell: guarda la teva solució del projecte. D'aquí a sis mesos, rellegir-la et dirà més sobre el que has après que qualsevol examen.

L'encàrrec. MercadoFresco creix i el negoci planteja tres coses alhora per a l'any vinent:

1. Obertura a Portugal i França. Lisboa i Porto primer, París i Lió després. Els clients portuguesos i francesos han de tenir una experiència equivalent a l'espanyola.
2. Aplicació mòbil per a iOS i Android, amb dues funcions noves: seguiment del repartiment en temps real —el client veu el vehicle moure's al mapa— i recomanacions de productes personalitzades segons el seu historial de compra.
3. Mantenir el cost per comanda. El gerent ha estat explícit: pot pujar la factura, però el cost per comanda no ha de pujar.

Els requisits, escrits:

El que cal lliurar. Deu apartats:

(a) Diagrama d'arquitectura. Un diagrama —mermaid, draw.io o paper fotografiat— amb les regions, els comptes, els components i els fluxos principals. Ha de distingir el que ja existeix del que s'afegeix.

(b) Regió o regions i estratègia multiregió. Una regió o diverses? Quines? Actiu-actiu, actiu-passiu, o una sola regió amb distribució a la vora? Justifica-ho amb els requisits de latència, residència i disponibilitat, i digues explícitament què descartes i per què.

(c) Motors de dades per a les dues funcions noves. Què faries servir per al seguiment en temps real i què per a les recomanacions, amb el patró d'accés, el volum estimat i el cost aproximat de cadascun.

(d) Pla de seguretat i compliment. Identitats, xifratge, secrets, protecció perimetral, auditoria, i específicament com tractes les dades de geolocalització de repartidors i clients sota el RGPD.

(e) Pla d'observabilitat amb SLI i SLO. Almenys tres indicadors amb el seu objectiu, la seva finestra i el seu pressupost d'error; quina alarma dispara què, i quins taulers necessita cada perfil.

(f) Pipeline i estratègia de desplegament per al nou àmbit multiregió i per a l'aplicació mòbil, que té un cicle de publicació diferent del de la web.

(g) Infraestructura com a codi i estructura de comptes. Què canvia a l'organització actual de sis comptes i com es desplega el mateix en diverses regions sense duplicar codi.

(h) Pressupost mensual estimat amb desglossament per servei i el cost per comanda resultant, comparat amb l'objectiu de 0,00934 USD.

(i) Revisió Well-Architected de la teva pròpia proposta: els tres riscos principals que introdueixes, el seu pilar i la seva mitigació.

(j) Pla de migració per fases, amb fites, criteris d'avanç i què fas si una fase falla.

Rúbrica d'avaluació:

Criteri general: un lliurament que justifiqui bé tres alternatives descartades val més que un que enumeri quinze serveis. I qualsevol apartat sense un número és un apartat incomplet.

Un company proposa la solució més simple possible per al requisit de latència: quedar-se només a eu-west-1 i resoldre Portugal i França amb CloudFront i AWS Global Accelerator, sense desplegar res a una altra regió.

1. Quins requisits de l'enunciat sí que resol aquesta proposta i quins no?
2. Estima la latència de xarxa des de Lisboa i des de París fins a Irlanda, i digues si el requisit de 200 ms és assolible.
3. Què li respondries sobre disponibilitat del 99,95 %?

Amb la factura actual de 1.681,60 USD i 180.000 comandes, el cost per comanda és de 0,00934 USD. El volum es multiplica per quatre fins a 720.000 comandes.

1. Si la factura creixés linealment, quant costaria i quin seria el cost per comanda?
2. Identifica quatre partides de la factura que no creixen amb el volum i estima quant pesen.
3. Estima la factura real amb ×4 de comandes i calcula el cost per comanda. Es compleix l'objectiu?

Solució a l'exercici 1: arquitectura de referència comentada

Aquesta és una solució vàlida, no l'única. El seu valor és a les raons, no a les caixes.

(a) i (b) Regions i estratègia multiregió.

La proposta: eu-west-1 (Irlanda) continua sent la regió principal i única per a l'estat transaccional, reforçada amb CloudFront a tota la vora europea i AWS Global Accelerator per al trànsit de l'aplicació mòbil. S'afegeix eu-west-3 (París) únicament per a dues coses: el destí de la recuperació davant de desastres i, si els mesuraments ho justifiquen, una rèplica de lectura del catàleg.

Per què:

• La latència es resol a la vora, no movent la base de dades. El requisit és de primer byte, i el 90 % del contingut d'una botiga és estàtic o cacheable: fotos, catàleg, JavaScript. CloudFront ja el serveix des de punts de presència a Lisboa, Madrid, París i Marsella. Per a les crides dinàmiques de l'API, Global Accelerator fica el trànsit a la xarxa troncal d'AWS al punt de presència més proper, cosa que retalla entre un 20 i un 40 % de la latència respecte d'internet públic.
• La residència de la dada ja es compleix: Irlanda és la UE. El RGPD exigeix que les dades romanguin a la UE o a països amb decisió d'adequació, no que estiguin al país del client. Aquest és el malentès més freqüent en aquest tipus de projectes.
• Una segona regió activa multiplicaria per dos la complexitat i per gairebé dos la factura, i el requisit del 99,95 % no la necessita: 99,95 % mensual són 21,9 minuts d'indisponibilitat al mes, perfectament assolibles amb Multi-AZ ben fet dins d'una sola regió.

Alternatives descartades i per què:

(c) Motors de dades per a les funcions noves.

Seguiment del repartiment en temps real. Dos problemes diferents que la gent sol barrejar:

• Ingerir la posició: 200 repartidors enviant la seva posició cada 5 segons són 40 missatges/segon, 3,5 milions al dia. És un volum petit i constant.
• Lliurar-la al client: cada client amb una comanda en curs vol veure el vehicle moure's amb menys de 3 segons de retard.

La proposta:

Cost estimat: uns 95 USD al mes amb aquest volum, dominat per les connexions WebSocket i les escriptures de DynamoDB.

Alternativa descartada: fer que l'aplicació pregunti per HTTP cada 3 segons. Amb 3.000 comandes en curs serien 1.000 peticions per segon contra l'API, és a dir, més trànsit que tota la botiga, i una bateria del mòbil esgotada en dues hores.

Recomanacions de productes. Aquí la clau és en un requisit que l'enunciat dona i que molta gent passa per alt: «actualitzades diàriament; no en temps real». Això canvia tota la solució.

Cost estimat: uns 40 USD al mes.

Alternativa descartada: Amazon Personalize. És el servei específic per a això i probablement donaria millors recomanacions. Es descarta en la primera versió per tres raons: costa força més, afegeix un servei nou per mantenir a un equip de cinc persones, i encara no hi ha una mesura de si les recomanacions funcionen. La decisió escrita: començar amb regles senzilles —«també van comprar això», «tornes a necessitar això»— sobre dades que ja hi són, mesurar la conversió durant tres mesos, i aleshores decidir si Personalize compensa. Introduir aprenentatge automàtic abans de tenir una mètrica d'èxit és la manera més cara de no saber si alguna cosa serveix.

(d) Seguretat i compliment.

L'existent es manté i s'estén: Identity Center, alias/mercadofresco-datos per a tot el que és nou, secrets a Secrets Manager, WAF a CloudFront i a l'ALB, Shield Standard, CloudTrail i Config centralitzats a 444455556666.

El que s'afegeix per l'aplicació mòbil:

• Amazon Cognito per a la identitat dels clients, amb inici de sessió federat. Els tokens caduquen; res de claus a l'aplicació.
• Certificats per dispositiu a IoT Core per als repartidors, amb política que només permet publicar al seu propi tema. Un repartidor no pot publicar la posició d'un altre.
• Limitació de velocitat i protecció de bots al WAF de l'API mòbil, que és el nou objectiu obvi.

I la part delicada, la geolocalització:

I l'advertiment que ha de figurar al lliurament i que forma part de la nota: això és un disseny tècnic, no un dictamen jurídic. El tractament de geolocalització de treballadors és un dels punts més sensibles del RGPD i de la normativa laboral, exigeix avaluació d'impacte i l'ha de revisar un professional de protecció de dades abans de posar-se en producció. Una proposta que resol la geolocalització sense esmentar això és incompleta per molt bona que sigui tècnicament.

(e) Observabilitat amb SLI i SLO.

Amb tres decisions importants: les alarmes es posen sobre la taxa de consum del pressupost d'error, no sobre llindars instantanis, per no despertar ningú per un pic de 30 segons; els taulers se separen per perfil —mercadofresco-produccion per al torn de guàrdia, mercadofresco-negocio per a la Sara i gerència, i un de nou mercadofresco-movil—; i el cost per comanda continua al tauler de negoci, al costat de les comandes, tal com es va establir a 11-02.

(f) Pipeline i desplegament. Es manté pipeline-mercadofresco-tienda amb blue/green i reversió, i s'hi afegeixen tres coses: una etapa per regió per al que es desplegui a eu-west-3, sempre desplegant primer a la regió secundària i només després a la principal; un pipeline propi per a l'API mòbil, que es versiona de manera independent perquè les aplicacions publicades a les botigues no es poden revertir —una versió antiga pot quedar instal·lada mesos, així que l'API ha de mantenir compatibilitat cap enrere durant almenys dues versions—; i banderes de funcionalitat per activar el seguiment en temps real per ciutat, cosa que permet obrir Lisboa sense tocar el codi.

(g) IaC i estructura de comptes. L'organització de sis comptes no canvia: continua sent l'adequada, i l'Entorno continua sent la millor dimensió de separació. El que canvia és la parametrització: les plantilles red-mercadofresco.yaml i aplicacion-mercadofresco.yaml i les piles del CDK reben la regió com a paràmetre, amb ss-mercadofresco-linea-base estès a la nova regió. Un sol repositori, una sola definició, dos destins.

L'únic compte que es planteja afegir és un de dades per a l'analítica i les recomanacions, i es descarta de moment: amb cinc persones, un compte més és més govern del que aporta. Es revisarà si l'equip de dades creix.

(h) Pressupost estimat.

L'objectiu es compleix amb escreix, i la raó és exactament la que 11-02 anticipava: hi ha una part important de la factura —NAT, ALB, endpoints, govern, observabilitat base— que no creix amb el volum, i en repartir-se entre quatre vegades més comandes fa baixar el cost unitari. Multiplicar el negoci per quatre multiplica la factura per 2,7.

(i) Els tres riscos principals d'aquesta proposta:

(j) Pla de migració per fases:

Dos principis que governen el pla: cada fase és reversible sense afectar el que ja funciona —banderes de funcionalitat, no desplegaments irreversibles— i la prova de càrrega és requisit per obrir el segon país, no una tasca que es fa si sobra temps. És exactament la troballa de risc alt que 11-01 va deixar oberta.

Solució a l'exercici 2

(1) Què resol i què no. La proposta d'una sola regió resol: la residència de la dada, perquè Irlanda és la UE; el cost, perquè és de bon tros l'opció més barata; la simplicitat operativa, decisiva amb cinc persones; i la latència del contingut estàtic, que és el gruix d'una botiga. No resol per si sola: la latència de les peticions dinàmiques si no s'hi afegeix Global Accelerator o algun mecanisme d'acceleració; i no aporta res davant d'una caiguda regional completa, que continua sent el risc número u de la proposta.

(2) Latència estimada. L'anada i tornada de xarxa des de Lisboa fins a eu-west-1 ronda els 40-55 ms, i des de París els 25-35 ms. A sobre d'això cal sumar l'establiment de TLS —que amb reutilització de connexió i TLS 1.3 s'amortitza— i el temps de procés al servidor, que a MercadoFresco és per sota de 900 ms al p99 però molt més baix a la mediana. El requisit de 200 ms de primer byte és perfectament assolible per a contingut servit des de CloudFront —on la latència és la del punt de presència local, de l'ordre de 10-20 ms— i assolible per a l'API dinàmica amb Global Accelerator i connexions reutilitzades. El que no seria assolible és servir cada petició dinàmica des d'Irlanda sense memòria cau ni acceleració i amb una consulta lenta al darrere.

(3) Sobre el 99,95 %. Aquí cal ser precís amb els números, perquè és on la conversa se sol tòrcer. 99,95 % mensual són 21,9 minuts d'indisponibilitat al mes. Això és perfectament assolible en una sola regió amb Multi-AZ ben fet: ALB en dues zones, Aurora amb commutació per sota de 30 segons, tasques repartides i desplegaments sense tall. El que una sola regió no cobreix és una caiguda regional completa, que és un succés rar però real.

La resposta honesta al company és que té raó en la proposta i li falta una frase: l'arquitectura d'una sola regió compleix el SLO compromès, i el risc residual —una caiguda regional— ha d'estar escrit, quantificat i acceptat per qui signa el contracte del 99,95 %, exactament com es va fer a 11-01 amb el RPO regional de 6 hores. Si el negoci no accepta aquest risc residual ara que hi ha tres països en joc, aleshores la conversa canvia i cal pressupostar llum pilot a eu-west-3: +12 % de factura, uns 550 USD al mes amb la nova mida.

Solució a l'exercici 3

(1) Creixement lineal. Seria 1.681,60 × 4 = 6.726,40 USD, i el cost per comanda es mantindria exactament igual en 0,00934 USD, perquè el creixement lineal és la definició de cost unitari constant.

(2) Quatre partides que no creixen amb el volum:

A aquestes quatre caldria afegir-hi la base fixa de CloudWatch —taulers, alarmes, mètriques personalitzades— i la part de Redshift que depèn del nombre d'informes i no del volum de comandes.

(3) Estimació realista.

Cosa que coincideix, dins del marge d'una estimació, amb els 4.600 USD de l'apartat (h) de la solució de referència.

Es compleix l'objectiu amb un 31,6 % de marge. I la conclusió de fons és la que dona sentit a tot el mòdul 11: el cost per comanda baixa en créixer perquè el 37 % de la factura és infraestructura fixa que es reparteix entre més comandes. És la raó per la qual presentar el cost absolut a la reunió mensual porta a decisions equivocades, i per la qual la mètrica unitària d'11-02 és la que cal ensenyar al gerent. Amb un advertiment: aquest avantatge només existeix si la part fixa es manté sota control. Si en créixer s'afegeixen comptes, regions, clústers i eines sense criteri, la part fixa creix amb ells i l'economia d'escala desapareix.

Aquest curs no prepara per a cap certificació en concret, però cobreix bona part del temari de diverses. El mapa:

Tres consells sobre certificacions, dits sense embuts:

1. L'Associate d'arquitecte és la que té millor relació entre esforç i utilitat si ja has fet aquest curs. Amb dues o tres setmanes de repàs enfocat i exàmens de pràctica, és assolible.
2. Una certificació no substitueix haver construït alguna cosa. Obre portes en processos de selecció i no ensenya a decidir. Les decisions difícils d'aquest curs —descartar EKS, descartar Shield Advanced, triar un any en lloc de tres— no surten a cap examen.
3. Si et vols certificar, fes-ho pel temari, no pel segell. El valor real és a les àrees que l'examen t'obliga a estudiar i que tu mai no hauries tocat pel teu compte.

I un consell sobre com llegir-los: la documentació d'AWS és enorme i està pensada per consultar-la, no per llegir-la. La manera productiva de fer-la servir és tenir un problema concret, buscar la pàgina exacta i llegir-la sencera, inclosa la secció de quotes i la de preus, que són les dues que més disgustos eviten.

Onze mòduls i unes dues-centes hores d'AWS després, això és el que queda fora i és el pas següent natural:

I l'ordre que té més sentit després d'aquest curs: primer Resiliència, perquè tanca el risc obert més greu; després Analítica, perquè és on hi ha el valor de negoci immediat; i llavors el que demani el problema que tinguis al davant.

En començar aquest curs probablement sabies que AWS existia i que «té molts serveis». Ara saps fer coses concretes:

• Dissenyar una arquitectura de tres capes al núvol, amb xarxa aïllada, computació elàstica i dades gestionades, i explicar cada decisió.
• Triar el motor de dades adequat a partir del patró d'accés en lloc de per costum: relacional, clau-valor, en memòria, columnar.
• Posar una aplicació en contenidors sense gestionar servidors, amb autoescalat, desplegament progressiu i reversió automàtica.
• Aïllar i protegir: identitats sense credencials permanents, xifratge amb claus pròpies, secrets rotats, WAF i grups de seguretat amb mínim privilegi.
• Saber què està passant: mètriques, registres, traces, alarmes i taulers que responen a preguntes de negoci i no només d'infraestructura.
• Desacoblar amb cues, temes, busos i màquines d'estats, i fer-ho bé: idempotència, reintents, cues de missatges fallits i compensació.
• Construir un pipeline que porti un commit a producció sense intervenció manual i que sàpiga tornar enrere sol.
• Descriure tota la infraestructura en codi i desplegar-la en diversos comptes i regions sense copiar i enganxar.
• Governar una organització multicompte amb unitats organitzatives, polítiques de control i una línia base comuna.
• Auditar el que s'ha construït amb mètode —sis pilars, troballes, riscos i pla prioritzat— i documentar decisions amb les seves alternatives descartades.
• Llegir una factura d'AWS, repartir-la per entorn i component, trobar el que sobra i posar-hi límits.
• I sobretot: dir que no. Descartar Shield Advanced amb criteri, descartar EKS amb sis condicions escrites, descartar Beanstalk, descartar Personalize fins a tenir una mètrica. Un arquitecte es reconeix pel que deixa fora.

Si has seguit les pràctiques en un compte real, això no és opcional. L'ordre importa, perquè molts recursos no es poden esborrar mentre altres en depenguin.

Abans de començar, dues comprovacions: revisa Cost Explorer amb granularitat diària per saber què està costant de debò, i filtra per l'etiqueta Proyecto=mercadofresco a Tag Editor per tenir l'inventari complet. Canvia de regió i repeteix: allò oblidat sol ser a us-east-1.

Fase 1 — Aturar el que consumeix ara (minuts).

Fase 2 — Computació i contenidors. Serveis d'ECS, després el clúster; funcions Lambda; instàncies EC2 —acabar-les, no aturar-les, perquè una instància aturada continua pagant el seu volum EBS—; grups d'Auto Scaling; i les imatges d'ECR, que es cobren per GB emmagatzemat.

Fase 3 — Balanceig i lliurament. Oients de l'ALB, després l'ALB, després els grups de destí. La distribució de CloudFront s'ha de deshabilitar primer i esperar que es propagui abans d'esborrar-la, cosa que triga de l'ordre de 15 minuts. Les adreces IP elàstiques s'alliberen a part: una IP sense associar costa més que una d'associada.

Fase 4 — Dades. Aquí convé aturar-se a pensar, perquè és irreversible. Clústers d'Aurora i RDS amb --skip-final-snapshot només si de debò no vols conservar res; grups de rèplica d'ElastiCache; taules de DynamoDB; i els buckets de S3, que s'han de buidar abans d'esborrar, incloses les versions antigues i els marcadors d'esborrat si el versionat està actiu, que és la causa número u de «no puc esborrar aquest bucket».

Fase 5 — Xarxa. L'ordre és estricte i no admet dreceres:

Els endpoints d'interfície són la fuita més silenciosa: costen uns 0,011 USD per hora, per AZ i per endpoint, encara que no hi passi ni un sol byte. Set endpoints en dues AZ són 112 USD al mes per res.

Fase 6 — Observabilitat i govern. Alarmes i taulers de CloudWatch; grups de registres, que continuen costant emmagatzematge indefinidament; canaris de Synthetics; l'enregistrador de Config, que cobra per element de configuració; els trails de CloudTrail més enllà del primer, que és gratuït; i les regles d'EventBridge.

Fase 7 — Seguretat i gestió. Programar l'esborrat de les claus de KMS, amb un període d'espera d'entre 7 i 30 dies —costen 1 USD al mes mentrestant—; secrets de Secrets Manager, també amb període de recuperació; paràmetres avançats de Parameter Store, que són els únics que cobren; i les Web ACL de WAF, que costen 5 USD al mes més 1 per regla encara que no estiguin associades a res.

Fase 8 — Comprovació final. Quatre passos que ningú no fa i que eviten la sorpresa del mes següent:

1. Espera 48 hores i torna a mirar Cost Explorer amb granularitat diària. El que continuï apareixent és el que se t'ha oblidat.
2. Recorre les regions, especialment us-east-1, on acaben les Web ACL de CloudFront i moltes proves.
3. Revisa Trusted Advisor, que llista recursos orfes.
4. Deixa un pressupost d'1 USD actiu amb avís al 100 %. És la teva xarxa de seguretat permanent i costa zero.

I el que no s'ha d'esborrar: el compte en si, si vols continuar practicant; el trail de gestió, que és gratuït; i el pressupost de vigilància. Tancar el compte és l'opció nuclear i només té sentit si no hi penses tornar.

Aquí s'acaba el curs, i val la pena mirar el camí complet abans de tancar.

Vas començar amb un compte buit i una botiga que queia els divendres. Acabes amb una arquitectura que serveix quatre ciutats amb 900 comandes per hora al pic, que es desplega gairebé cinc vegades per setmana en horari laboral, que es restaura en quatre minuts, que està descrita íntegrament en codi, governada en sis comptes, auditada amb els sis pilars del marc Well-Architected i pressupostada fins al cèntim per comanda. Els cinc problemes que van obrir el curs estan resolts i cadascun té un número al costat.

Però el que t'endús no són els serveis. Els serveis canvien: la meitat de les pantalles d'aquest curs seran diferents d'aquí a tres anys i hi haurà noms nous que avui no existeixen. El que no canvia és el mètode, i això és el que has practicat onze mòduls seguits: començar pel problema i no per la tecnologia; triar el motor de dades pel seu patró d'accés; mesurar abans d'optimitzar i optimitzar abans de comprometre; provar la recuperació en lloc de suposar-la; automatitzar el que es fa dues vegades; escriure les decisions amb les seves alternatives descartades; i posar un número al costat de cada afirmació.

I amb aquest mètode ve la seva part menys vistosa i més valuosa: la capacitat de dir que no. Aquest curs va descartar Shield Advanced amb criteri, va descartar EKS amb sis condicions escrites que el canviarien, va descartar Elastic Beanstalk, va descartar una segona regió activa, va descartar Personalize fins a tenir una mètrica d'èxit i va descartar un compromís a tres anys que hauria condicionat l'arquitectura. Cap d'aquestes decisions no surt en un diagrama i totes elles són la feina real d'un arquitecte. Se't reconeixerà abans pel que deixis fora amb arguments que pel que aconsegueixis encabir.

Queda un últim consell, i és l'únic que de debò importa a partir d'aquí: munta't alguna cosa teva. No un altre laboratori guiat, ni un altre tutorial. Alguna cosa petita i real, que resolgui un problema que t'importi: el web d'un club, un servei per automatitzar alguna cosa tediosa, un tauler amb dades que t'interessin. Posa-ho en un compte propi amb MFA i un pressupost de cinc dòlars. Trenca-ho. Arregla-ho a les onze de la nit. Descobreix per tu mateix que les còpies no funcionaven, que aquell grup de seguretat estava obert i que l'endpoint que vas deixar encès t'ha costat catorze dòlars. Aquell dia hauràs après més que en qualsevol mòdul d'aquest curs, perquè l'error propi es recorda i l'aliè s'oblida.

MercadoFresco, mentrestant, continua repartint producte fresc en vint-i-quatre hores. Els divendres a la tarda, quan entren nou-centes comandes per hora, les tasques ja són amunt des de les 16:45 perquè algú va programar aquest escalat. Ningú no se n'assabenta. I aquest és exactament el senyal que la feina està ben feta: la millor arquitectura és la que ningú no nota.

Gràcies per arribar fins aquí. Ara esborra els recursos i ves a construir alguna cosa.