Al llarg d'aquest mòdul hem desplegat el catàleg d'AlpinaShop de quatre maneres diferents: en màquines virtuals amb un grup gestionat, a App Engine amb un app.yaml, en contenidors sobre GKE Autopilot, i hem esmentat Cloud Run i Cloud Functions com a opcions que s'estudien més endavant. Totes funcionen. Totes serveixen la mateixa pàgina. I totes tenen implicacions molt diferents en cost, en esforç operatiu, en velocitat de desplegament i en la llibertat que tindràs d'aquí a tres anys.

Aquesta lliçó és la síntesi del mòdul. No introdueix serveis nous: et dóna el criteri per triar entre els que ja coneixes, amb una taula comparativa completa, preguntes de decisió que pots aplicar demà a la teva feina, un càlcul de cost transparent sobre el mateix escenari de trànsit, els patrons de migració habituals i, al final, l'arquitectura definitiva d'AlpinaShop, documentada i raonada, que sostindrà la resta del curs.

1. El continu d'abstracció
2. Què guanyes i què perds en pujar de nivell
3. Taula comparativa completa
4. Les sis preguntes de decisió
5. Cost comparat sobre un mateix escenari
6. Patrons de migració: lift-and-shift, replatform, refactor
7. Arquitectures híbrides: gairebé ningú no en tria un de sol
8. L'arquitectura d'AlpinaShop en tancar el mòdul
9. El que falta: la xarxa

Els serveis de còmput de Google Cloud no són una llista d'opcions soltes: formen un continu. A cada esglaó cedeixes control a la plataforma i reps a canvi menys feina operativa.

Llegit d'esquerra a dreta:

• Compute Engine. Tu dónes una imatge de disc i Google et dóna una màquina. Tota la resta —sistema operatiu, pedaços, runtime, servidor web, escalat, desplegament— és teva.
• GKE Standard. Tu dónes contenidors i decideixes la mida i el nombre de nodes. Kubernetes col·loca els contenidors; tu mantens la flota de VM.
• GKE Autopilot. Tu dónes contenidors i declares quants recursos demanen. Els nodes desapareixen de la teva vista.
• App Engine. Tu dónes codi i un app.yaml. Desapareixen també els contenidors.
• Cloud Run. Tu dónes un contenidor i una configuració mínima. Escala a zero, es factura per ús i no hi ha infraestructura visible.
• Cloud Functions. Tu dónes una funció i un disparador. És la unitat de desplegament més petita possible.

Fixa't que hi ha dos camins cap a Cloud Run: des de contenidors (GKE) i des de codi (App Engine). Aquesta convergència no és casual, i explica per què Cloud Run s'ha convertit en el punt de trobada de tots dos mons.

Dos matisos que eviten conclusions simplistes:

Més abstracció no sempre és més barat. Una càrrega constant 24×7 surt més barata a Compute Engine amb descompte per ús compromès que en un servei serverless facturat per petició. El serverless guanya amb trànsit intermitent o molt variable, que és precisament el cas d'AlpinaShop.

Més abstracció no sempre és menys portable. Un contenidor a Cloud Run és tan portable com a GKE: la mateixa imatge corre a tots dos, al teu portàtil i en un altre núvol. El que lliga no és el nivell d'abstracció, sinó el format propietari: l'app.yaml d'App Engine o les signatures específiques de Cloud Functions.

Dues files mereixen un comentari addicional.

Concurrència per instància. És el paràmetre més mal interpretat i el que més diners mou. Cloud Run pot atendre fins a 1000 peticions simultànies en una mateixa instància; Cloud Functions n'atén una de sola per defecte. Per a una aplicació que passa el temps esperant la base de dades, una concurrència alta significa moltes menys instàncies i una factura molt menor. Per a una aplicació que consumeix CPU, pujar-la degrada la latència de tothom.

Arrencada en fred. Existeix sempre que es pugui escalar a zero. Es mitiga amb instàncies mínimes, però això elimina precisament l'avantatge de l'escalat a zero. És un compromís, no un problema amb solució.

A la pràctica, l'elecció es resol responent sis preguntes en ordre.

1. Necessites control del sistema operatiu o maquinari especial? Kernel concret, controladors, GPU, programari amb llicència lligada a maquinari, agents de seguretat corporatius, processos que han de veure l'amfitrió. Si la resposta és sí → Compute Engine (o GKE Standard si a més vols contenidors). Si no, continua.

2. Tens contenidors, o estàs disposat a tenir-ne? Si no i no vols aprendre'n ara → App Engine estàndard o Compute Engine. Si sí → continua, s'obre tota la resta. Val la pena insistir-hi: contenidoritzar és la inversió amb millor retorn de tot el mòdul, perquè la mateixa imatge funciona a Cloud Run, a GKE, al teu portàtil i en un altre núvol.

3. Necessites estat local persistent o processos molt llargs? Sessions en memòria, disc local amb dades, processos d'hores, servidors amb connexions de llarga durada. Si sí → Compute Engine o GKE. Si no → continua.

4. El trànsit és intermitent o molt variable? Si el trànsit cau a gairebé zero de nit o té pics estacionals de deu a un → Cloud Run (escala a zero, es paga per ús). Si és constant i elevat 24×7 → Compute Engine o GKE amb descomptes per ús compromès surten millor.

5. És una unitat de treball petita disparada per un esdeveniment? Un fitxer que arriba a un bucket, un missatge a Pub/Sub, un webhook, una tasca programada → Cloud Functions. Si és un servei amb diverses rutes i una API → Cloud Run.

6. Et preocupa la dependència del proveïdor? Si és un criteri real de la teva organització → contenidors (Cloud Run o GKE), que s'executen a qualsevol lloc. Evita app.yaml i les signatures propietàries de funcions.

I una regla transversal que resumeix l'estat de l'art el 2026: si tens una aplicació web o una API contenidoritzable i cap de les restriccions anteriors no s'aplica, Cloud Run és la resposta per defecte. És el consell que dóna el mateix Google, i aquest curs el subscriu.

Comparar preus de catàleg no serveix de res; cal comparar el cost d'una càrrega concreta. Fem servir la d'AlpinaShop:

Escenari. El catàleg d'AlpinaShop rep:

• 500.000 peticions al mes en un mes normal (unes 0,2 peticions/segon de mitjana).
• Distribució molt desigual: 80 % del trànsit entre les 9:00 i les 23:00; pràcticament res de matinada.
• Pics de campanya: fins a 20 peticions/segon durant unes 40 hores repartides a la tardor.
• Cada petició consumeix uns 150 ms de CPU i 300 MiB de memòria.
• L'aplicació necessita ~0,25 vCPU i 512 MiB per instància.

Xifres orientatives per a europe-west1 a 2026, arrodonides, amb l'únic fi de mostrar l'ordre de magnitud i la manera de raonar. No inclouen Cloud SQL, Cloud Storage, egress ni CDN, que són comuns a totes les opcions i que en aquest escenari superen el mateix còmput. Verifica sempre a la calculadora oficial de Google Cloud abans de prendre una decisió.

Les conclusions que cal extreure'n, que valen més que els números:

• L'escalat a zero importa quan el trànsit és desigual. AlpinaShop no té trànsit vuit hores al dia; pagar per capacitat encesa durant aquest temps és pur malbaratament.
• El pla de control de GKE és un cost fix rellevant a escala petita. No el posis per desplegar un sol servei; sí quan hi hagi deu serveis compartint-lo, moment en què aquest cost es dilueix.
• La concurrència mana a Cloud Run. Amb concurrència 80, un pic de 20 peticions per segon s'atén amb molt poques instàncies. Si la baixessis a 1, en necessitaries vint vegades més i el cost es multiplicaria.
• El còmput no sol ser la partida més gran. En aquest escenari, Cloud SQL amb alta disponibilitat costa força més que qualsevol de les opcions de còmput. Optimitzar el còmput abans que la base de dades i l'egress és començar pel lloc equivocat. La disciplina completa d'optimització de costos és a 07-05.

Quan una empresa mou una aplicació existent al núvol, hi ha tres estratègies, i la majoria de migracions reeixides les recorren en ordre.

Per què l'ordre importa. Intentar refactoritzar i migrar alhora és la recepta clàssica del projecte que no s'acaba: quan alguna cosa falla, no saps si és pel canvi d'arquitectura o pel canvi de plataforma. Separar les variables redueix el risc dràsticament.

El recorregut d'AlpinaShop en aquest mòdul ha estat exactament aquest:

1. Lift-and-shift (02-01): el catàleg Flask a una VM alpinashop-web-1 amb un startup script, i després a un grup gestionat amb escalat automàtic. L'aplicació no va canviar ni una línia.
2. Replatform (02-02, 02-03, 02-06): les imatges van sortir del disc local al bucket alpinashop-catalogo; la base de dades tienda va passar a la instància gestionada alpinashop-pedidos amb alta disponibilitat i còpies; la cistella i les sessions es van moure a Firestore. La lògica de negoci continua sent la mateixa; el que va canviar és on viu cada cosa.
3. Refactor (en curs): contenidoritzar l'aplicació, que ja vam fer per a GKE a 02-05, i desacoblar la feina asíncrona amb cues i esdeveniments, que vam començar a veure amb Cloud Tasks a 02-04 i completarem amb Pub/Sub a 04-04.

Per què AlpinaShop comença a Compute Engine però es dirigeix cap a contenidors. Començar en VM va ser el correcte: va permetre migrar en un cap de setmana sense reescriure res, amb un risc mínim i amb la possibilitat de tornar enrere. Però el destí són els contenidors, per tres raons que ja hem comprovat al llarg del mòdul:

• La imatge de contenidor és portable. La mateixa que corre a GKE corre a Cloud Run, al portàtil del Dani i, si algun dia calgués, en un altre proveïdor.
• El desplegament es torna trivial i reversible. Davant de plantilles d'instància versionades, startup scripts i imatges de disc, un contenidor es desplega i es reverteix amb una comanda.
• La inversió s'acumula. Aprendre contenidors serveix a tots els serveis i a tota la indústria; aprendre app.yaml serveix a App Engine.

La pregunta "quin servei de còmput utilitzo?" està mal plantejada si es fa una sola vegada per a tot el sistema. Es fa per càrrega de treball, i el normal és acabar amb uns quants.

Una arquitectura completa i realista per a AlpinaShop en combina quatre:

Repartiment i motiu:

Aquesta barreja no és indecisió: és utilitzar l'eina adequada per a cada feina. El cost de la varietat és haver de conèixer diversos serveis; el benefici és no forçar cap càrrega a un model que no li encaixa.

Aquesta és la decisió documentada que tanca el mòdul 2 i que servirà de base per a la resta del curs.

Estat actual (el que s'ha construït en aquest mòdul):

Decisió d'arquitectura objectiu:

1. El catàleg web (alpinashop-web) anirà a Cloud Run. Trànsit intermitent amb pics estacionals, contenidor ja construït, escala a zero, cost molt inferior a les alternatives i sense acoblament al proveïdor. Es configurarà amb min-instances: 1 en producció per evitar arrencades en fred a la primera visita, i concurrència alta perquè l'aplicació passa la major part del temps esperant la base de dades. Cloud Run s'estudia a 07-02.

2. El clúster alpinashop-cluster es conserva com a plataforma per als serveis interns que vagin apareixent (tauler d'administració, integració amb l'ERP, processos de sincronització d'estoc). Quan n'hi hagi tres o més, el cost del pla de control quedarà amortitzat. Mentrestant, es manté apagat o reduït al mínim.

3. Compute Engine es conserva per a feina per lots amb VM Spot: reprocessament d'imatges, proves de càrrega, tasques puntuals de CPU intensiva.

4. App Engine queda descartat, de manera raonada: funciona bé, però el seu format propi no és portable i la inversió no s'acumula. Es coneix, s'ha provat i es descarta.

5. Cloud Functions es reserva per a la feina dirigida per esdeveniments: correu de confirmació de comanda, generació de miniatures en pujar una imatge al bucket, webhooks de la passarel·la de pagament (06-03).

6. Les dades queden com es va decidir a 02-06: Cloud SQL per a productes, comandes i clients; Firestore per a cistella i sessions; Cloud Storage per a imatges; Memorystore com a memòria cau de portada; Pub/Sub i BigQuery per a la telemetria, amb Bigtable descartat per ara.

Ruta de migració acordada amb la Marta, el Dani i la Lucía:

Repassa el que s'ha construït en aquest mòdul amb ull crític i hi trobaràs un problema seriós.

La VM alpinashop-web-1 té una IP pública i el port 80 obert a tot internet. Les instàncies del grup gestionat, també. El Service de tipus LoadBalancer de GKE va exposar una IP pública directa, sense HTTPS. La instància de Cloud SQL, si es va crear amb IP pública i xarxes autoritzades, és abastable des de fora. Els buckets estan ben protegits, però les URL signades viatgen per HTTP si algú les utilitza malament. No hi ha cap nom de domini propi, cap certificat TLS, cap protecció davant d'atacs de denegació de servei ni davant d'injecció SQL, i cap separació de xarxa entre el que ha de ser públic (el catàleg) i el que mai no hauria de ser-ho (la base de dades).

Dit sense embuts: hem construït una botiga funcional i l'hem deixada amb la porta oberta i sense rètol a la façana. Tot el d'aquest mòdul estava bé per aprendre i per provar; res d'això no és publicable tal qual.

Això és exactament el que resol el mòdul 3.

• Triar el servei abans d'entendre la càrrega. El patró de trànsit, la durada de les peticions i la necessitat d'estat determinen la resposta; el gust personal, no.
• Triar Kubernetes per defecte. És una eina excel·lent per a molts serveis i equips amb capacitat de plataforma. Per a un servei i una persona, és sobrecàrrega pura.
• Comparar preus de catàleg en lloc de cost de la càrrega. El preu per vCPU-hora no diu res si no saps quantes hores necessitaràs.
• Oblidar el cost del pla de control de GKE en comparar amb alternatives serverless a escala petita.
• Deixar la concurrència de Cloud Run a 1 "per seguretat". Multiplica el nombre d'instàncies i el cost.
• Refactoritzar i migrar alhora. Quan falli alguna cosa, no sabràs quin canvi ho ha causat.
• Quedar-se per sempre al lift-and-shift. És un punt de partida legítim i un destí dolent: continues mantenint servidors.
• Acceptar acoblament al proveïdor sense decidir-ho. Si l'has d'assumir, que sigui una decisió conscient i anotada, no un accident.
• Consell: contenidoritza encara que no hagis d'utilitzar Kubernetes. És el que més opcions t'obre per menys esforç.
• Consell: decideix per càrrega de treball, no per sistema. Una arquitectura amb Cloud Run, funcions i VM Spot no és incoherent: és apropiada.
• Consell: documenta i data cada decisió d'arquitectura, amb les alternatives descartades i el motiu. És el que permet revisar-la amb criteri d'aquí a un any.
• Consell: mesura abans d'optimitzar. Gairebé sempre la despesa és on no l'esperes, i poques vegades al còmput.

Per a cada càrrega d'AlpinaShop, tria el servei de còmput, indica una alternativa raonable i justifica la decisió aplicant les sis preguntes de l'apartat 4:

1. Una API REST d'estoc que consulten els proveïdors, amb trànsit irregular i molt baix de nit.
2. Un procés que, cada vegada que es puja una imatge al bucket, genera la miniatura i la versió web.
3. Un servidor de sincronització amb l'ERP local que manté una connexió permanent i desa estat al disc.
4. El tauler intern d'administració, utilitzat per 8 persones en horari d'oficina.
5. Un reprocessament puntual de les 60.000 imatges que triga 3 hores i es pot reintentar.

Un servei intern d'AlpinaShop rep 100.000 peticions al mes, cadascuna de 200 ms de CPU, necessita 0,5 vCPU i 1 GiB de memòria, i el seu trànsit es concentra en horari d'oficina (unes 9 hores al dia, 22 dies al mes).

1. Estima el cost a Compute Engine amb una VM encesa 24×7.
2. Estima el cost si s'apaga fora d'horari.
3. Estima el cost a Cloud Run amb escalat a zero.
4. Indica a partir de quin volum de trànsit Compute Engine començaria a ser competitiu.
5. Enumera quins costos has deixat fora del càlcul i per què poden invertir la conclusió.

Redacta el document de decisió d'arquitectura del catàleg d'AlpinaShop, amb aquesta estructura:

1. Context: situació de partida i restriccions.
2. Opcions considerades: almenys quatre, amb un avantatge i un inconvenient de cadascuna.
3. Decisió: què es tria i amb quina configuració concreta.
4. Conseqüències: què millora, què empitjora i què queda pendent.
5. Criteris de revisió: què hauria de passar per reconsiderar-la.

Solució 1

Solució 2

1. Compute Engine 24×7. Una e2-small (2 vCPU compartides, 2 GiB) volta els 13–15 €/mes, més uns 2 € del disc balancejat de 20 GB: ≈ 16 €/mes. Es paga la màquina les 730 hores del mes, encara que només s'utilitzi durant 198.

2. Compute Engine apagada fora d'horari. Amb 198 hores encesa de 730, el cost de còmput baixa a un 27 %: uns 4 €. El disc es continua pagant sencer (≈2 €), perquè els discos facturen estiguin o no enceses les màquines. Total: ≈ 6 €/mes, més la feina d'automatitzar l'encesa i l'apagada amb Cloud Scheduler i una funció.

3. Cloud Run amb escalat a zero. Facturació aproximada:

Als preus orientatius d'europe-west1, tot això queda a l'entorn d'1–2 €/mes, i una part important pot caure dins del nivell gratuït mensual de Cloud Run. És entre 3 i 10 vegades més barat que les opcions anteriors, sense cap feina d'automatització.

4. Quan comença a compensar Compute Engine? Quan la màquina estigui ocupada de manera sostinguda. El punt d'equilibri arriba aproximadament quan l'ús de CPU facturat a Cloud Run s'acosta a tenir una vCPU ocupada de manera contínua: de l'ordre de diversos milions de peticions al mes amb aquest perfil, o qualsevol càrrega que mantingui la CPU treballant 24 hores al dia. Afegint-hi un descompte per ús compromès a un o tres anys, aquest llindar baixa força. La regla mental és clara: el serverless guanya amb trànsit intermitent; les VM guanyen amb càrrega constant i alta.

5. Costos deixats fora, i per què poden canviar la conclusió:

• Balancejador de càrrega i IP estàtica (~18–20 €/mes a Compute Engine). Cloud Run inclou endpoint HTTPS gestionat, cosa que amplia encara més el seu avantatge.
• Egress i CDN, comuns a totes les opcions, però que en una botiga amb imatges superen el còmput.
• Cloud SQL, que en aquest escenari costa més que qualsevol de les opcions de còmput comparades.
• El temps de les persones. Mantenir una VM (pedaços, monitoratge, automatització d'encesa) són hores de la Marta. Si es valoren a preu de mercat, l'estalvi de 10 €/mes de l'opció 2 desapareix amb la primera hora de feina al mes.
• Descomptes per ús compromès i per ús sostingut, que només s'apliquen a Compute Engine i GKE i poden reduir el seu cost entre un 20 i un 55 %.

Aquest últim punt és el més important i el que més s'oblida: el cost d'una arquitectura no és només la seva factura.

Solució 3

DA-001 — Servei de còmput del catàleg web d'AlpinaShop Data: 2026-08-05 · Autors: Marta (infraestructura), Dani (backend) · Estat: acceptada

1. Context. El catàleg web és una aplicació Flask en Python amb PostgreSQL, actualment desplegada en un grup d'instàncies gestionat de Compute Engine després del lift-and-shift. El trànsit és intermitent: pràcticament nul de matinada, amb pics de fins a 20 peticions per segon a les campanyes de tardor. L'equip d'infraestructura és d'una persona. L'aplicació ja està contenidoritzada i la seva imatge publicada a Artifact Registry. No requereix estat al disc local ni accés al sistema operatiu. Restriccions: minimitzar la feina operativa, evitar l'acoblament al proveïdor i contenir el cost fora de campanya.

2. Opcions considerades.

3. Decisió. Desplegar alpinashop-web a Cloud Run, a europe-west1, amb la imatge europe-west1-docker.pkg.dev/alpinashop-prod/alpinashop/catalogo, etiquetada amb el hash del commit. Configuració: min-instances: 1 i max-instances: 50 en producció; min-instances: 0 en desenvolupament; concurrència 80; 1 vCPU i 512 MiB per instància; connexió a Cloud SQL mitjançant el connector; credencials resoltes pel compte de servei adjunt; secrets a Secret Manager. El clúster alpinashop-cluster es conserva per a futurs serveis interns. Compute Engine es manté únicament per a feina per lots amb VM Spot.

4. Conseqüències. Millora: desapareixen el manteniment del sistema operatiu, les plantilles d'instància i els startup scripts; el cost de còmput baixa aproximadament un ordre de magnitud fora de campanya; els desplegaments i els rollbacks passen a ser immediats amb divisió de trànsit entre revisions; s'obté HTTPS gestionat sense configurar res. Empitjora: es perd el control del sistema operatiu i la capacitat de diagnòstic a baix nivell; apareix la possibilitat d'arrencades en fred en desenvolupament; les tasques de més de 60 minuts s'han d'executar fora de Cloud Run. Pendent: balancejador HTTPS global amb domini propi, Cloud CDN, Cloud Armor i xarxa privada cap a Cloud SQL (mòdul 3); pipeline de desplegament automatitzat (mòdul 6).

5. Criteris de revisió. Es reconsiderarà aquesta decisió si: el nombre de serveis interns supera tres, cas en què GKE Autopilot amortitza el seu pla de control i podria absorbir també el catàleg; el trànsit passa a ser constant i elevat 24×7, escenari en què Compute Engine o GKE amb descomptes per ús compromès resultarien més econòmics; apareix un requisit d'estat local o de processos de més de 60 minuts; o l'arrencada en fred afecta mètriques de negoci malgrat min-instances: 1. Revisió programada: agost de 2027, o abans si es compleix algun dels criteris anteriors.

Tanquem el mòdul 2 amb criteri, que és el que distingeix conèixer una plataforma de saber-la utilitzar. Has vist que els serveis de còmput de Google Cloud formen un continu d'abstracció —de la màquina virtual a la funció— i que a cada esglaó cedeixes control a canvi de feina operativa. Saps què es guanya i què es perd en pujar de nivell, i també els dos matisos que eviten les conclusions fàcils: més abstracció no sempre és més barat, perquè una càrrega constant 24×7 surt millor en VM amb compromís d'ús, i més abstracció no sempre és menys portable, perquè el que lliga no és el nivell sinó el format propietari.

Tens una taula comparativa completa de set opcions amb criteris que es poden mesurar —unitat de desplegament, escalat a zero, arrencada en fred, facturació, portabilitat, temps màxim, esforç operatiu, concurrència— i sis preguntes de decisió que pots aplicar demà a qualsevol càrrega: control del sistema operatiu, contenidors, estat i durada, patró de trànsit, dispar per esdeveniments i dependència del proveïdor. Has fet un càlcul de cost transparent sobre l'escenari real d'AlpinaShop i n'has extret les lliçons que importen més que els números: l'escalat a zero mana quan el trànsit és desigual, el pla de control de GKE és un cost fix rellevant a escala petita, la concurrència governa el cost a Cloud Run, i el còmput poques vegades és la partida més gran de la factura. Has recorregut els tres patrons de migració i has entès per què separar la migració del redisseny redueix el risc, i per què AlpinaShop va començar a Compute Engine però es dirigeix cap a contenidors. I has vist que la pregunta correcta no es fa una vegada per a tot el sistema, sinó una vegada per càrrega de treball: l'arquitectura objectiu combina Cloud Run, Cloud Functions, Cloud Run Jobs, VM Spot i un clúster de GKE en reserva.

Repassant el mòdul sencer: vam crear màquines virtuals amb plantilles, grups gestionats regionals, escalat automàtic i reparació automàtica; vam moure els 60 GB d'imatges al bucket alpinashop-catalogo amb classes d'emmagatzematge, cicle de vida, versionatge i URL signades; vam migrar la base de dades tienda a alpinashop-pedidos amb alta disponibilitat regional, PITR i rèplica de lectura; vam provar App Engine amb el seu app.yaml, la seva divisió de trànsit i el seu cron, i el vam descartar amb arguments; vam contenidoritzar l'aplicació, la vam publicar a Artifact Registry i la vam desplegar a alpinashop-cluster sobre GKE Autopilot amb HPA, sondes, secrets i actualitzacions sense tall; vam repartir les dades entre Cloud SQL, Firestore, Memorystore, Cloud Storage i BigQuery amb un arbre de decisió; i hem acabat documentant i datant l'arquitectura completa. La migració d'AlpinaShop ja no és un pla: és infraestructura que funciona.

I acaba amb un problema evident. Tot el que hem construït està exposat: la VM té el port 80 obert a internet, el Service de GKE va publicar una IP sense HTTPS, la base de dades és abastable des de fora, no hi ha domini propi ni certificat, no hi ha protecció davant d'atacs i no existeix separació de xarxa entre el que ha de ser públic i el que mai no hauria de ser-ho. Al mòdul 3, Xarxes i seguretat, ho arreglem d'arrel: dissenyarem la xarxa VPC d'AlpinaShop amb subxarxes i regles de tallafoc, posarem un balancejador de càrrega HTTPS global davant del catàleg, accelerarem les imatges amb Cloud CDN, repartirem permisos amb IAM aplicant el mínim privilegi a la Marta, el Dani i la Lucía, protegirem la botiga amb Cloud Armor, desarem les credencials a Secret Manager amb xifratge gestionat per Cloud KMS, i publicarem alpinashop.example amb Cloud DNS i certificats TLS gestionats. El que avui funciona passarà a ser, a més, publicable.