Quan crees un recurs a Google Cloud, gairebé sempre has de decidir on viu. Aquesta decisió, que la consola presenta com un simple desplegable, condiciona la latència que pateixen els teus clients, el preu que pagues, quins serveis tens disponibles, si compleixes la normativa de protecció de dades i què passa quan falla un centre de dades. No és un detall de configuració: és una decisió d'arquitectura que després costa molt de revertir.

En aquesta lliçó aprendrem la geografia de Google Cloud i què significa que un servei sigui zonal, regional, multiregional o global; per què la xarxa troncal privada de Google i els seus punts de presència importen per a la latència; quins criteris fer servir per triar regió, aplicats a la decisió real d'AlpinaShop entre europe-west1 i europe-southwest1; què protegeix desplegar en diverses zones i què exigeix el multiregió; i com es reparteix la responsabilitat entre Google i tu segons el tipus de servei, incloent-hi com es llegeixen els SLA i per què un SLA no promet que res falli mai.

1. La geografia de Google Cloud
2. Abast dels serveis: zonal, regional, multiregional i global
3. La xarxa troncal privada i els punts de presència
4. Com triar regió: els cinc criteris
5. La decisió d'AlpinaShop: europe-west1 davant d'europe-southwest1
6. Dominis de fallada i disponibilitat
7. El model de responsabilitat compartida
8. SLA i crèdits de servei

Google Cloud organitza la seva infraestructura física en tres nivells:

Detalls importants:

• Les zones d'una regió són molt a prop les unes de les altres, amb latències de xarxa típicament inferiors al mil·lisegon. Això permet replicació síncrona entre zones sense penalització perceptible: és la base de l'alta disponibilitat regional.
• Les lletres de zona no són estables entre projectes. La zona europe-west1-b del teu projecte i la d'un altre client poden correspondre a maquinari físic diferent. Google fa aquesta assignació deliberadament per repartir la càrrega.
• La latència entre regions sí que és significativa. Entre europe-west1 i europe-southwest1 hi ha de l'ordre d'una desena de mil·lisegons; entre Europa i els Estats Units, al voltant de 100 ms. Qualsevol arquitectura que creui regions al camí crític d'una petició ho notarà.

Noms de les regions europees més rellevants per a una empresa espanyola:

Cada servei de Google Cloud té un abast que determina on viu i a quines fallades sobreviu. Entendre-ho és imprescindible per dissenyar qualsevol arquitectura.

Classificació dels serveis concrets que apareixeran al curs:

Dos casos mereixen comentari a part:

• La VPC global és una diferència real respecte d'AWS i Azure, on la xarxa virtual és regional. A Google Cloud una mateixa VPC pot tenir subxarxes a Bèlgica, Madrid i Tòquio, i les màquines de totes elles es comuniquen per IP privada sense configurar peering. Ho estudiarem a la lliçó 03-01.
• La immutabilitat de la ubicació a Cloud Storage i BigQuery és un detall que atrapa molta gent: si crees el bucket alpinashop-catalogo a la regió equivocada, l'única solució és crear-ne un altre i copiar-hi les dades, pagant el trànsit corresponent.

Google opera una de les xarxes privades més grans del món: fibra pròpia i capacitat contractada que uneix els seus centres de dades entre si i amb més d'un centenar de punts de presència (PoP) repartits pel planeta, inclòs Madrid.

Per què això importa a la pràctica:

• El trànsit entra aviat a la xarxa de Google. Quan un client d'AlpinaShop a Sevilla demana una pàgina, la seva petició arriba al PoP de Google més proper (Madrid) després d'uns pocs salts per internet, i des d'allà viatja fins a europe-west1 per fibra de Google. La part «impredictible» del trajecte s'escurça.
• Menys latència i, sobretot, menys variabilitat. L'internet públic té pics de latència impredictibles; una xarxa privada gestionada d'extrem a extrem no.
• És la base del balancejador global. El balancejador HTTP(S) extern de Google fa servir una única adreça IP anycast anunciada des de tots els PoP. L'usuari es connecta automàticament al punt més proper i des d'allà el trànsit va per la xarxa de Google al backend adequat. S'estudia a la lliçó 03-02.
• És la base de Cloud CDN. Els continguts estàtics —les imatges de producte d'AlpinaShop, per exemple— es poden emmagatzemar en memòria cau en aquests PoP, servint-se des de a pocs mil·lisegons del client sense arribar a tocar el bucket. Lliçó 03-03.

Una conseqüència arquitectònica que convé retenir des d'ara: amb una CDN i un balancejador global ben configurats, la regió on viu el teu backend importa menys del que sembla per al contingut estàtic, però continua sent decisiva per a tot el que requereixi parlar amb la base de dades.

Hi ha a més dos nivells de servei de xarxa que afecten cost i rendiment:

Ampliem els dos que més se subestimen.

Una confusió molt estesa: el RGPD no obliga, amb caràcter general, que les dades de ciutadans europeus romanguin en un país concret ni tan sols dins de la UE. El que exigeix és que el tractament compleixi la normativa i que les transferències internacionals disposin de garanties adequades.

Dit això, a la pràctica hi ha raons sòlides per mantenir les dades a la UE:

• Evita per complet la complexitat jurídica de les transferències internacionals.
• Molts clients corporatius i del sector públic ho exigeixen contractualment, encara que la llei no ho imposi.
• Determinats sectors (sanitat, banca, administració pública) sí que tenen requisits específics més estrictes.

Google ofereix a més polítiques d'organització per restringir per política en quines regions es poden crear recursos (gcp.resourceLocations), cosa que converteix la residència de la dada en una cosa verificable i no només en una intenció. Es veu a la lliçó 07-07.

Per a AlpinaShop, que ven a consumidors a Espanya i Portugal i tracta dades personals de clients (nom, adreça, historial de comandes), la decisió és clara: tot dins de la UE. El dubte és entre Bèlgica i Madrid.

No totes les regions són iguals. Les regions més antigues i grans tenen catàleg complet; les més noves van incorporant serveis progressivament, i alguns tipus de màquina, acceleradors (GPU, TPU) o serveis de dades triguen a arribar.

La primera comanda llista les regions amb el seu estat. La segona fa servir --filter per quedar-se només amb les dues regions candidates i --format amb region.basename() per mostrar el nom curt de la regió en lloc de la seva URL completa. La tercera combina dues condicions amb AND i fa servir ~ per expressar «el nom coincideix amb l'expressió regular ^n2-», cosa que permet comprovar si una família de màquines concreta està disponible abans de comprometre's amb una regió.

Marta analitza les dues candidates amb dades reals de l'empresa: el 85 % de les comandes vénen d'Espanya, el 10 % de Portugal i el 5 % de la resta d'Europa.

AlpinaShop tria europe-west1 com a regió principal per a aquesta primera fase de la migració, amb la zona europe-west1-b com a zona per defecte. Les raons:

1. És una regió madura, amb tots els serveis que el curs i l'empresa necessitaran, inclosos els de dades i IA que arribaran més endavant. Començar una migració en una regió incompleta obliga a descobrir mancances en el pitjor moment.
2. El preu és menor en diversos dels serveis que més consumirà.
3. La penalització de latència és acceptable i mitigable: la diferència de 20-25 ms és perceptible en una mesura, però es neutralitza en gran mesura servint el contingut estàtic des de Cloud CDN al PoP de Madrid i aplicant memòria cau al dinàmic. El gruix d'una pàgina de catàleg són imatges.
4. La residència de la dada es compleix: Bèlgica és territori de la Unió Europea, i AlpinaShop no té requisits sectorials que exigeixin territori espanyol.

Quan revisaria Marta aquesta decisió. Si AlpinaShop signés un contracte amb una administració pública espanyola que exigís dades en territori nacional, o si l'anàlisi de conversió mostrés que la latència està costant vendes, la instància de Cloud SQL alpinashop-pedidos i el bucket alpinashop-catalogo es replantejarien cap a europe-southwest1. Per això europe-southwest1 apareixerà diverses vegades al curs: és l'alternativa sempre present quan parlem de latència o residència de la dada a Espanya.

Aquest parell de comandes és dels més rendibles del curs: sense elles, moltes comandes fan servir valors per defecte o pregunten interactivament, i és molt fàcil acabar amb recursos dispersos per mig món.

Un domini de fallada és el conjunt de recursos que poden caure junts per una mateixa causa. Dissenyar per a la disponibilitat consisteix a repartir els teus recursos entre dominis de fallada diferents.

Què implica cada salt:

• D'una zona a diverses zones és el salt amb millor relació cost/benefici, i el que cobreix la immensa majoria d'incidents reals. Sol requerir: replicació síncrona de la base de dades (Cloud SQL amb HA), diverses instàncies darrere d'un balancejador, i emmagatzematge regional en lloc de zonal. La latència entre zones és submil·lisegon, així que la replicació síncrona és viable.
• De diverses zones a diverses regions canvia la naturalesa del problema. La latència entre regions fa inviable la replicació síncrona sense penalitzar l'escriptura, així que cal triar entre replicació asíncrona (amb possible pèrdua de dades recents) o bases de dades dissenyades per a això, com Spanner. A més cal resoldre l'encaminament del trànsit i la commutació.

Un advertiment contra l'entusiasme: el multiregió no és «més disponibilitat» de franc. Multiplica cost, complexitat i superfície d'error, i hi ha incidents que replica en lloc de contenir (un desplegament defectuós o un esborrat accidental es propaguen a totes les regions). Per a AlpinaShop, la resposta correcta en aquesta fase és producció multizona dins d'europe-west1, amb còpies de seguretat en un bucket multiregió EU com a protecció addicional.

Els conceptes de SLO, RTO i RPO, i el disseny detallat d'arquitectures d'alta disponibilitat i recuperació davant de desastres, s'estudien a la lliçó 07-06.

La seguretat al núvol sempre es comparteix. Google respon de la seguretat del núvol; tu respons de la seguretat al núvol. On cau exactament la línia depèn del tipus de servei.

El que mai deixa de ser teu, en cap model de servei:

1. Les teves dades: què reculls, quant de temps ho guardes, com ho classifiques, si està xifrat amb claus gestionades per tu.
2. Qui hi accedeix: les polítiques d'IAM, la gestió d'identitats, la rotació de credencials.
3. La teva configuració: un bucket públic, una regla de tallafoc que obre el 0.0.0.0/0 al port 22 o una base de dades amb IP pública són responsabilitat exclusivament teva, i són la causa de la immensa majoria de bretxes reals al núvol.
4. El teu codi: les vulnerabilitats de la teva aplicació i de les teves dependències.

Aplicat a AlpinaShop:

Una nota que sorprèn molta gent: el xifratge en repòs està activat per defecte a tots els serveis d'emmagatzematge de Google Cloud, sense que hagis de fer res. Google gestiona les claus. Si necessites gestionar-les tu (per requisit normatiu o per política interna), existeixen les claus gestionades pel client amb Cloud KMS, tema de la lliçó 03-06.

Un SLA (Service Level Agreement) és el compromís contractual de disponibilitat d'un servei. Llegir-los bé evita tant la ingenuïtat com el cinisme.

Ordres de magnitud típics (verifica sempre les xifres vigents als termes oficials de cada servei, perquè canvien):

Com llegir un SLA de debò:

• El SLA depèn de la teva arquitectura, no només del servei. Fixa't en la taula: la mateixa VM té un compromís molt diferent segons estigui sola en una zona o repartida entre diverses. Google no et garanteix 99,99 % si tu desplegues en una sola zona.
• Un SLA no és una promesa que no fallarà. És un compromís econòmic: si Google l'incompleix, tu tens dret a un crèdit de servei, és a dir, un descompte a la factura de mesos posteriors.
• Els crèdits són ridículs comparats amb el dany real. Un incompliment típic dona lloc a un crèdit del 10-25 % de la factura del servei afectat durant aquest període. Si AlpinaShop perd una tarda de campanya de tardor, el crèdit no cobrirà ni de bon tros les vendes perdudes. El SLA no substitueix dissenyar per a la resiliència.
• Els crèdits s'han de reclamar. No s'apliquen sols: cal presentar una sol·licitud dins d'un termini, aportant registres que documentin la indisponibilitat. Una altra raó per tenir Cloud Monitoring ben configurat (lliçó 06-04).
• Hi ha exclusions. El SLA no cobreix el que hagi causat la teva pròpia configuració, ni el programari de tercers, ni l'incompliment de les quotes, ni els serveis en fase preliminar.

La conclusió pràctica: fes servir el SLA com un senyal del nivell de fiabilitat que Google s'atreveix a comprometre per a una arquitectura donada, i com a criteri per triar configuració, no com a xarxa de seguretat del teu negoci.

• Deixar la regió per defecte. Molts tutorials i alguns valors per defecte apunten a us-central1. Per a AlpinaShop això voldria dir 100 ms de latència extra i dades fora de la UE. Fixa regió i zona amb gcloud config set des del primer dia.
• Confondre regió amb zona. Crear una VM «a europe-west1» no és possible: les VMs són zonals i viuen a europe-west1-b, -c o -d.
• Creure que multizona i multiregió són el mateix. Multizona protegeix contra la caiguda d'un centre de dades i és assequible; multiregió protegeix contra la pèrdua d'una regió sencera i és car i complex.
• Crear un bucket o un dataset a la ubicació equivocada. La ubicació de Cloud Storage i BigQuery és immutable: l'única sortida és crear-ne un altre i copiar-hi les dades, pagant el trasllat.
• Suposar que totes les regions tenen tots els serveis. Comprova la disponibilitat abans de comprometre-t'hi, especialment amb GPUs, TPUs i serveis recents.
• Pensar que «gestionat» significa «segur per defecte». La configuració és teva en tots els models. Un bucket públic és un bucket públic encara que el servei sigui serverless.
• Confiar en el SLA com a pla de continuïtat. El crèdit de servei no paga les vendes perdudes.
• Consell: mesura, no suposis. Abans de decidir regió per latència, mesura des d'on són els teus usuaris reals.
• Consell: separa la decisió de regió de la d'arquitectura. Primer decideix on han de viure les dades (normativa, latència) i després com es desplega el còmput.
• Consell: fes servir una política d'organització per restringir regions. És l'única manera de garantir que ningú crea un recurs a Iowa per descuit.

Per a cada recurs d'AlpinaShop, indica el seu abast (zonal, regional, multiregional o global) i què passa si cau completament la zona europe-west1-b:

1. Una instància de Compute Engine que serveix l'Nginx heretat, creada a europe-west1-b.
2. La instància Cloud SQL alpinashop-pedidos configurada amb alta disponibilitat a europe-west1.
3. El bucket alpinashop-catalogo creat com a multiregió EU.
4. La política d'IAM que dona a Lucía permís de lectura sobre BigQuery.
5. Un clúster GKE alpinashop-cluster creat com a zonal a europe-west1-b.
6. El balancejador HTTP(S) extern que publica la botiga.

AlpinaShop signa un acord amb una cadena de botigues d'esport a Alemanya: la nova plataforma B2B servirà comandes majoristes des d'Alemanya, tractarà dades d'empreses alemanyes i el contracte exigeix que les dades romanguin en territori alemany. El volum previst és petit i no requereix GPUs ni serveis exòtics.

1. Quina regió triaries i per què?
2. Haurien de conviure les dades B2B a la mateixa base de dades tienda que la resta? Justifica-ho.
3. Quin mecanisme faries servir per garantir tècnicament que ningú crea per error recursos d'aquest projecte fora d'Alemanya?

Analitza aquests cinc incidents reals i determina, en cada cas, si la responsabilitat és de Google o d'AlpinaShop, i quina mesura concreta ho hauria evitat:

1. El bucket alpinashop-catalogo va quedar configurat amb accés públic i un cercador va indexar factures que s'hi havien pujat per error.
2. Una zona d'europe-west1 va patir un tall elèctric de 40 minuts i la VM que servia la botiga va quedar inaccessible.
3. Un atacant va entrar per SSH a la VM heretada fent servir una contrasenya feble d'un usuari del sistema.
4. Una vulnerabilitat crítica a la versió de PostgreSQL que fa servir Cloud SQL va ser apedaçada sense intervenció de ningú d'AlpinaShop.
5. L'aplicació Flask tenia una vulnerabilitat d'injecció SQL al cercador de productes.

Solució 1

1. Zonal. Es perd la instància i amb ella el servei, fins que es recreï en una altra zona. El disc persistent zonal associat també queda inaccessible.
2. Regional. Cloud SQL amb HA manté una rèplica en espera en una altra zona de la regió i commuta automàticament. Hi ha un breu tall durant la commutació (de l'ordre de desenes de segons), però el servei es restableix sol.
3. Multiregional. No l'afecta gens: les dades estan replicades entre diverses regions de la UE. És el nivell de resiliència més alt dels que apareixen aquí.
4. Global. IAM no té ubicació; la política continua vigent i Lucía conserva el seu accés.
5. Zonal. Es perd el pla de control del clúster i tots els seus nodes. Un clúster regional hauria replicat el pla de control en tres zones i hauria mantingut els nodes de les zones supervivents.
6. Global. El balancejador no es veu afectat, però deixarà d'enviar trànsit als backends de la zona caiguda. Si tots els backends eren en aquella zona, no té on enviar el trànsit: el balancejador global no crea disponibilitat per si sol, la reparteix.

Solució 2

1. europe-west3 (Frankfurt), per ser una regió en territori alemany amb catàleg complet i madura. europe-west10 (Berlín) seria una altra opció vàlida en territori alemany; entre totes dues, Frankfurt ofereix més disponibilitat de serveis i millor preu, mentre que Berlín podria interessar per latència si els clients es concentressin allà. Atès que el volum és petit i no hi ha requisits exòtics, la maduresa pesa més.
2. No. Les dades B2B alemanyes han de viure a la seva pròpia instància i el seu propi projecte, a europe-west3. Barrejar-les amb la base de dades tienda d'europe-west1 incompliria directament el requisit contractual de residència, i separar-les després seria molt més costós. L'estructura natural és un projecte nou, per exemple alpinashop-de-prod, dins de la carpeta produccion.
3. Una política d'organització de restricció d'ubicacions (constraints/gcp.resourceLocations) aplicada al projecte o a una carpeta que el contingui, permetent únicament in:eu-west3-locations. A diferència d'una norma escrita en un document, aquesta política impedeix tècnicament la creació de recursos fora de la ubicació permesa, fins i tot per a usuaris amb permisos amplis. S'estudia a la lliçó 07-07.

Solució 3

1. Responsabilitat d'AlpinaShop. La configuració d'accés d'un bucket és sempre del client. Google proporciona els controls; fer-los servir és tasca teva. Ho hauria evitat: activar la prevenció d'accés públic a nivell d'organització, fer servir accés uniforme a nivell de bucket, i no pujar documents amb dades personals a un bucket destinat a imatges públiques de catàleg.
2. Responsabilitat de Google pel que fa a la infraestructura: un tall d'energia en una zona és una fallada del núvol. Però la indisponibilitat del servei és responsabilitat d'AlpinaShop, perquè va desplegar una única VM en una única zona. Google compleix el seu SLA zonal; AlpinaShop no va dissenyar per a la fallada. Ho hauria evitat: un grup d'instàncies gestionat regional darrere d'un balancejador, amb la base de dades a Cloud SQL amb HA.
3. Responsabilitat d'AlpinaShop. El sistema operatiu i els seus usuaris són seus en IaaS. Ho hauria evitat: deshabilitar l'autenticació per contrasenya a SSH, fer servir l'accés mitjançant OS Login amb identitats de Google, no exposar el port 22 a internet i accedir-hi mitjançant Identity-Aware Proxy.
4. Responsabilitat de Google, i és exactament el valor que es compra en fer servir un servei gestionat: l'apedaçament del motor de base de dades és seu. AlpinaShop només s'ha d'encarregar que la finestra de manteniment estigui configurada en un horari acceptable i d'estar al corrent dels canvis de versió major.
5. Responsabilitat d'AlpinaShop. El codi de l'aplicació és sempre del client, en tots els models de servei, inclòs serverless. Ho hauria evitat: consultes parametritzades, revisió de codi, anàlisi estàtica al pipeline de CI/CD i, com a capa addicional, regles de Cloud Armor contra patrons d'injecció (lliçó 03-05).

Ja sabem on viuran els recursos d'AlpinaShop i qui respon de què. Hem recorregut la geografia de Google Cloud —zona, regió i multiregió— i hem classificat els serveis del curs segons siguin zonals, regionals, multiregionals o globals, amb la particularitat que a Google Cloud la VPC és global i la ubicació d'un bucket o un dataset és immutable. Hem vist per què la xarxa troncal privada de Google i els seus punts de presència redueixen latència i fan possibles el balancejador global amb IP anycast i Cloud CDN. Hem aplicat els cinc criteris d'elecció de regió al cas real d'AlpinaShop i hem decidit europe-west1 amb zona europe-west1-b, deixant europe-southwest1 com a alternativa si apareixen requisits de residència en territori espanyol o si la latència comença a costar vendes. Hem entès què protegeix desplegar en diverses zones enfront del que exigeix el multiregió, i hem repartit la seguretat entre Google i nosaltres amb la regla que mai canvia: les dades, els accessos, la configuració i el codi són sempre teus. I hem après a llegir un SLA com el que és: un compromís econòmic que depèn de la teva arquitectura, no una garantia que res fallarà.

Ens queda una última peça del mòdul, i és la que converteix tot l'anterior en feina real. A la lliçó següent, Cloud Shell i la CLI de gcloud, deixarem la teoria i ens posarem a teclejar: veurem què és Cloud Shell i quins límits té, com instal·lar el CLI en local, com s'estructura una comanda gcloud i com dominar --format i --filter, com funcionen l'autenticació i les configuracions anomenades per alternar entre alpinashop-dev i alpinashop-prod, i tancarem el mòdul amb el primer desplegament real del curs: Dani publicarà una pàgina de «pròximament» d'AlpinaShop a internet, d'extrem a extrem, des del navegador.