AlpinaShop ja es construeix, es desplega i s'observa tota sola. El mòdul 7 comença per la part que el curs ha anat esquivant: hi ha sistemes d'AlpinaShop que no són a Google Cloud i no hi seran. A la botiga física de Sabadell hi ha un servidor amb un ERP en MySQL que gestiona l'inventari, la caixa i les factures; i al magatzem hi ha un terminal de radiofreqüència que parla amb aquest ERP per la xarxa local. Ningú no els ha migrat, ningú no té previst migrar-los enguany, i tanmateix la botiga en línia necessita saber l'estoc real.

Això és una arquitectura híbrida, encara que ningú no l'hagi anomenada així. I no és un cas rar: és la situació normal de gairebé qualsevol empresa amb més de cinc anys d'història. Aquesta lliçó tracta de com Google Cloud aborda aquest escenari, i del producte que durant anys el va representar: Anthos.

Amb un advertiment d'honestedat per endavant, perquè marca el to de tot el mòdul: al final de la lliçó, AlpinaShop no adoptarà Anthos. I entendre per què és tan valuós com saber configurar-lo, perquè l'habilitat que separa un bon arquitecte de núvol d'un bon recitador de serveis és saber quan no cal l'eina gran. Aprendràs què és, com funciona, quins problemes resol de debò i quant costa —i amb aquestes tres dades podràs prendre la decisió tu mateix, a la teva empresa, amb criteri propi.

Una nota prèvia sobre noms, perquè aquest és el producte de Google Cloud que més vegades ha canviat de nom i la documentació que trobaràs està repartida entre tots ells. Es detalla a l'apartat 5.

1. Què signifiquen exactament «híbrid» i «multinúvol»
2. Els motius reals per no ser només en un núvol
3. Els costos ocults que el fullet no esmenta
4. El cas d'AlpinaShop: Sabadell, l'ERP i el terminal del magatzem
5. Què és Anthos i en què s'ha convertit
6. La flota (fleet): la unitat de gestió
7. Els components, un a un
8. Config Sync: la configuració com a codi amb GitOps
9. Policy Controller: les polítiques com a codi
10. Exemple pràctic: registrar alpinashop-cluster i aplicar una política
11. El mallat de serveis explicat sense fum
12. Binary Authorization i la cadena de confiança
13. Observabilitat unificada de la flota
14. Model de llicència i cost: el que decideix a la pràctica
15. Alternatives més lleugeres a l'híbrid complet
16. Quan sí i quan no: la taula de decisió
17. DA-004: la decisió honesta d'AlpinaShop

Els dos termes es fan servir com a sinònims i no ho són. La diferència importa perquè els problemes que plantegen són diferents.

I una quarta categoria que gairebé ningú no anomena però que és la més freqüent:

• Multinúvol accidental: l'empresa és a GCP, però a més té un CRM a Salesforce, el correu a Microsoft 365, la facturació en un SaaS i un parell de màquines en un proveïdor barat que algú va contractar el 2019. Ningú no ho va decidir; va passar. I tanmateix cal integrar-ho, protegir-ho i pagar-ho.

AlpinaShop, sense haver-ho decidit mai, ja és híbrida i ja és multinúvol accidental. La feina d'arquitectura no consisteix a evitar-ho, sinó a gestionar-ho amb intenció.

Les presentacions comercials donen sempre els mateixos cinc motius. Són certs, però cadascun té una versió honesta que convé conèixer.

El motiu de fullet: «aprofita la teva inversió existent».

La versió real: si fa divuit mesos l'empresa va comprar servidors amb una amortització a cinc anys, el director financer no signarà llençar-los a les escombraries, i té raó. El cost d'aquests servidors ja està pagat: apagar-los no torna els diners, només estalvia l'electricitat i el manteniment. Migrar abans que s'amortitzin significa pagar dues vegades la mateixa capacitat.

És el motiu més comú i el més legítim, i també el que caduca sol: d'aquí a tres anys aquella inversió ja no existeix i la conversa és una altra. Per això moltes arquitectures híbrides són en realitat migracions lentes disfressades d'estratègia permanent.

El motiu de fullet: «processa les dades on es generen».

La versió real: hi ha processos on 30 mil·lisegons importen i d'altres on no. Un terminal de magatzem escanejant codis de barres contra un servidor local respon en 2 ms; contra europe-west1 respondrà en 15-25 ms des de Sabadell. Per escanejar un paquet, cap de les dues no molesta. Per al braç robòtic d'una línia de producció que ajusta la seva posició mil vegades per segon, el núvol no és una opció a cap latència.

La pregunta correcta no és «hi ha latència?» —sempre n'hi ha— sinó «què passa si l'enllaç cau durant dues hores?». Si la resposta és «la botiga no pot cobrar», el sistema ha de poder funcionar sense connexió, i això obliga a tenir còmput local. Aquest, i no els mil·lisegons, és l'argument fort.

El motiu de fullet: «compleix la normativa».

La versió real: hi ha tres nivells molt diferents que es confonen constantment:

La immensa majoria de les empreses espanyoles que diuen «no podem anar al núvol per la llei» són al nivell 1, que es resol triant regió. L'RGPD no prohibeix el núvol públic: exigeix un tractament adequat, un encarregat del tractament amb contracte, mesures tècniques i control de les transferències internacionals. Només sectors concrets —defensa, certes administracions, sanitat en alguns supòsits— arriben al nivell 3.

Avís. La interpretació dels requisits regulatoris que apliquin a les teves dades no és una decisió tècnica. Qualsevol disseny que tracti dades personals, sanitàries o financeres ha de ser revisat per un professional de seguretat i de compliment normatiu abans d'anar a producció.

El motiu de fullet: «no et lliguis a un fabricant».

La versió real, i és la més mal interpretada de les cinc: la dependència no és binària, té graus, i evitar-la del tot costa més del que estalvia.

L'estratègia sensata no és «fer servir només el que és portable», perquè això significa renunciar a BigQuery, que és probablement el millor motiu per ser a Google Cloud. L'estratègia sensata és saber en quin nivell ets a cada peça i que sigui una decisió conscient. AlpinaShop està molt acoblada en analítica (BigQuery) i molt poc en l'aplicació (contenidors). Està bé: l'analítica es refaria en sis mesos si calgués, la botiga es mouria en dues setmanes.

I una dada incòmoda: la majoria d'empreses que munten una arquitectura multinúvol «per no dependre de ningú» acaben depenent de la capa que unifica tots dos núvols —que sol ser un altre proveïdor— i afegint una dependència en lloc de treure-la.

El motiu de fullet: «si un núvol cau, continues funcionant».

La versió real: les caigudes totals d'un proveïdor són extraordinàriament rares; les caigudes d'una regió són molt més freqüents, i per a això no cal un altre núvol: n'hi ha prou amb una altra regió. Muntar multinúvol actiu-actiu per resistir una caiguda global de Google és pagar el doble de complexitat tot l'any per cobrir un esdeveniment que potser no passarà mai. Es tracta amb detall a 07-06, amb RTO i RPO.

Cada model té un cost que no apareix a la comparativa de preus.

El cost ocult més car de tots és humà. AlpinaShop té una persona d'infraestructura. Un model híbrid gestionat de debò —amb la seva malla de serveis, les seves polítiques replicades i el seu enllaç redundant— requereix que aquesta persona sigui experta en Kubernetes, en xarxes empresarials, en el maquinari local i en Google Cloud, i que a més estigui disponible quan falli a les tres de la matinada. Aquest és el motiu pel qual la majoria d'arquitectures híbrides de pime fracassen, i no té res a veure amb la tecnologia.

Posem el cas concret sobre la taula, amb les dades que la Marta va reunir.

El que la botiga en línia necessita de tot això és molt menys del que sembla:

1. L'estoc real cada pocs minuts, per no vendre el que ja no hi ha.
2. Les comandes web abocades a l'ERP, perquè la comptabilitat quadri.
3. Res més. Ni el catàleg de proveïdors, ni les nòmines, ni l'històric del 2012.

I aquesta és l'observació que decideix la lliçó sencera: no cal unificar dues plataformes per moure dos fluxos de dades. Si el requisit fos «executar les mateixes aplicacions contenidoritzades a la botiga i al núvol, amb les mateixes polítiques i la mateixa malla», Anthos seria la resposta. El requisit real és «sincronitzar dues taules i enviar unes comandes», i això es resol amb un túnel i un procés programat.

Tot i així, estudiarem Anthos a fons. Perquè la decisió de no fer-lo servir només val si es pren sabent el que es descarta.

Anthos es va presentar el 2019 com la plataforma d'aplicacions de Google per a entorns híbrids i multinúvol. La seva idea central era potent i ho continua sent:

Si les teves aplicacions s'executen a Kubernetes, el lloc físic on s'executa aquest Kubernetes deixa d'importar. Google et dona un pla de control únic per gestionar-los tots —a GCP, al teu centre de dades, a AWS o a Azure— amb la mateixa configuració, les mateixes polítiques i la mateixa observabilitat.

Kubernetes com a denominador comú. Aquesta és tota la tesi.

Aquí hi ha la part que confon tothom. El nom «Anthos» s'ha anat retirant i l'oferta s'ha reorganitzat en dues famílies:

La manera pràctica de recordar-ho:

• Si parles de gestionar clústers de manera unificada, el nom actual és GKE Enterprise.
• Si parles de maquinari o programari de Google corrent fora de Google, el nom actual és Google Distributed Cloud.
• Si algú diu «Anthos», es refereix a alguna de les dues i probablement va aprendre el tema abans del 2023.

En aquesta lliçó farem servir la nomenclatura actual, assenyalant el nom antic quan ajudi a buscar documentació.

El concepte que cal entendre abans que cap altre és la flota.

Una flota és un grup lògic de clústers de Kubernetes que es gestionen junts i que confien entre si.

Una flota:

• Pertany a un projecte, anomenat projecte amfitrió de la flota (fleet host project).
• Pot contenir clústers de GKE, de GKE on-prem, de GKE Multi-Cloud, d'EKS, d'AKS, o qualsevol clúster de Kubernetes conforme registrat amb l'agent gke-connect.
• És la frontera d'aplicació de les polítiques, de la identitat i de la configuració.

La conseqüència més important i menys evident és la dels espais de noms de flota (fleet namespaces):

En una flota, l'espai de noms tienda significa el mateix a tots els clústers. És «l'equip de la botiga», no «una carpeta dins d'un clúster concret».

Això s'anomena igualtat d'espais de noms (namespace sameness) i té efectes pràctics enormes:

• Un permís concedit sobre l'espai tienda a nivell de flota aplica als deu clústers.
• Un servei catalogo a l'espai tienda pot ser descobert des de qualsevol clúster de la flota.
• Ningú no pot crear un espai tienda en un altre clúster per a «una altra cosa»: el nom està reservat a aquell equip a tota la flota.

Sense flota, cada clúster és una illa amb el seu propi RBAC, les seves pròpies polítiques i el seu propi criteri. Amb flota, hi ha un model mental compartit. Aquest és el valor real del producte, més que qualsevol característica concreta.

GKE Enterprise no és un servei: és un conjunt de peces que s'activen per separat. Aquestes són, amb la seva funció exacta.

De tots ells, els dos que la gent adopta primer —i amb raó— són Config Sync i Policy Controller. I són també els dos que es poden aprofitar en un sol clúster, sense híbrid pel mig.

Config Sync és un agent que corre dins del clúster i fa una sola cosa, molt bé:

Vigila un repositori Git i garanteix que l'estat del clúster coincideix amb el que hi ha en aquell repositori. Si algú canvia alguna cosa a mà, ho reverteix.

Això és GitOps, i val la pena entendre per què és diferent d'un pipeline de desplegament com el que AlpinaShop va muntar a 06-01.

L'avantatge decisiu en un escenari híbrid és la tercera columna de la primera fila: el clúster de la botiga de Sabadell no necessita ser accessible des d'internet. Surt ell cap a Google, llegeix la seva configuració i s'aplica. No cal obrir ports entrants cap a la botiga, que és exactament el que un no vol fer.

L'estructura típica del repositori, que a AlpinaShop viuria a alpinashop-infra:

Dues carpetes clau: cluster/ per al que aplica a tots, i namespaces/<nom>/ per al que aplica a un espai de noms concret a tots els clústers de la flota. La igualtat d'espais de noms de l'apartat 6 es materialitza aquí.

Policy Controller és la implementació gestionada de Gatekeeper, que al seu torn es recolza en OPA (Open Policy Agent). Funciona com un webhook d'admissió: cada vegada que algú intenta crear o modificar un recurs al clúster, la petició hi passa i pot ser rebutjada.

Té dos objectes:

• ConstraintTemplate: la plantilla de la regla, escrita en un llenguatge anomenat Rego. Defineix el tipus de comprovació.
• Constraint: la instància d'aquesta plantilla amb paràmetres concrets i el seu àmbit.

Google publica una biblioteca de plantilles amb més de cent regles llestes, així que a la pràctica gairebé mai no cal escriure Rego. Exemples de la biblioteca:

I té un mecanisme que cal fer servir sempre al principi:

El patró correcte és el mateix que ja es va fer servir amb Cloud Armor a 03-05: dryrun primer, es mesura una setmana, i només llavors deny. Activar una política en deny sense mesurar és la manera més ràpida que l'equip de desenvolupament no pugui desplegar un divendres a la tarda i que Policy Controller es desinstal·li el dilluns.

Ho farem de debò sobre el clúster que AlpinaShop ja té des de 02-05. És un exercici útil fins i tot si mai no adoptes GKE Enterprise, perquè Config Sync i Policy Controller funcionen en un únic clúster de GKE Autopilot i aporten valor per si sols.

• gkehub.googleapis.com és l'API de flotes. «Hub» era el nom intern original i ha quedat a l'API.
• anthosconfigmanagement.googleapis.com gestiona Config Sync i Policy Controller (fixa't en el nom antic, que sobreviu a l'API encara que el producte es digui d'una altra manera).
• gkeconnect.googleapis.com és el canal de connexió sortint dels clústers registrats.

Un clúster de GKE al mateix projecte que la flota es registra amb una sola ordre:

Explicat peça a peça:

• memberships register crea una pertinença (membership): l'objecte que representa aquell clúster dins de la flota.
• alpinashop-cluster és el nom de la pertinença. Convé que coincideixi amb el del clúster per no tornar-se boig.
• --gke-cluster=REGIO/NOM identifica un clúster de GKE. Per a un clúster extern es faria servir --kubeconfig i --context.
• --enable-workload-identity és el que permet que els pods obtinguin credencials de Google sense fitxers de clau, exactament igual que a 03-04. En un clúster d'Autopilot ja està actiu; el registre l'integra amb la flota.

Comprovació:

La configuració de la característica es declara en un fitxer i s'aplica a la flota:

Camp per camp:

• sourceFormat: unstructured permet organitzar el repositori com vulguis. L'alternativa, hierarchy, imposa l'estructura estricta que es va veure a l'apartat 8. Per començar, unstructured dona menys disgustos.
• syncRepo / syncBranch / policyDir: repositori, branca i subdirectori a partir del qual se sincronitza. Tot el que quedi fora de config-flota s'ignora.
• secretType: token indica com s'autentica contra GitHub. En producció es faria servir una app de GitHub o, millor, gcpserviceaccount contra un repositori allotjat a GCP.
• syncWait: 30 són els segons entre comprovacions. Trenta segons és un bon equilibri; abaixar-ho molt només genera crides a l'API.
• templateLibraryInstalled: true instal·la les més de cent plantilles de la biblioteca de Google. Sense això, cal escriure el Rego a mà.
• auditIntervalSeconds: 60 és cada quant Policy Controller revisa els recursos que ja existien abans de la política. Això importa: el webhook només veu el que és nou; l'auditoria periòdica és la que descobreix el que és vell i incompleix.

S'aplica així:

I l'estat es consulta amb:

Last_Synced_Token és el hash del commit aplicat. Aquesta dada respon en un segon a la pregunta «quina versió de la configuració està corrent en aquest clúster?», que en un model d'empenta sol requerir arqueologia als registres del pipeline.

AlpinaShop vol garantir una cosa que fins ara depenia de la bona voluntat: al clúster només s'executen imatges del seu Artifact Registry. Res de docker.io/elquesigui:latest.

El fitxer s'afegeix al repositori alpinashop-infra, a config-flota/cluster/politicas/:

Els detalls que importen:

• enforcementAction: dryrun: durant una setmana registra violacions sense bloquejar res.
• excludedNamespaces: els espais de noms del sistema fan servir imatges de Google. Si no els exclous, trenques el clúster. Aquest és l'error número u amb Policy Controller.
• parameters.repos accepta prefixos. La barra final importa: sense ella, .../alpinashop-malicioso també passaria.

I una segona política, aquesta de les etiquetes que AlpinaShop fa servir des de 01-04:

Observa que allowedRegex no només exigeix l'etiqueta: exigeix que el seu valor sigui un dels vàlids. Sense això, algú posa equipo: varios i l'assignació de costos de 07-05 torna a ser inútil.

Al cap d'una setmana, es consulten les violacions registrades:

Dues troballes reals, i cap no és un atac: són dues imatges públiques legítimes que algú va desplegar sense pensar-hi. La resposta correcta no és rendir-se i treure la política, sinó:

1. Copiar aquestes dues imatges a l'Artifact Registry propi (que a més és el correcte per disponibilitat i per escaneig de vulnerabilitats, com es veurà a 07-04).
2. Actualitzar els desplegaments.
3. Ara sí, canviar dryrun per deny, fer commit i deixar que Config Sync ho propagui.

En menys d'un minut, el clúster rebutja qualsevol pod amb una imatge aliena. I el més important: el canvi és en un pull request revisat, no a la memòria de ningú.

La malla de serveis (service mesh) és la part de GKE Enterprise que més es ven i pitjor s'entén. Anem amb l'explicació honesta.

S'injecta un proxy (Envoy) al costat de cada contenidor de l'aplicació —el patró sidecar— o a cada node (ambient, el mode més recent que evita el sidecar). Tot el trànsit entre serveis passa per aquests proxies. Com que el proxy veu tot el trànsit i el controla un pla de control central, es poden fer coses que l'aplicació no sap fer.

Els dos valors realment difícils de replicar són el mTLS automàtic amb identitats per servei i la telemetria uniforme sense tocar el codi. La resta s'aconsegueix d'altres maneres, sovint més simples.

I aquí la part que les presentacions ometen:

• Dupliques els contenidors. Cada pod passa a tenir dos processos. Consum de CPU i memòria addicional del 10-30 %, i a Autopilot això és factura directa.
• Afegeixes un salt de xarxa a cada crida. Latència addicional d'entre 0,5 i 3 ms per salt, que es multiplica per la profunditat de la cadena de crides.
• Depures el doble. Quan alguna cosa falla, la pregunta passa a ser «és l'aplicació o és el proxy?». Els codis d'error d'Envoy (UF, UO, NR, URX) cal aprendre-se'ls.
• Introdueixes conceptes nous: VirtualService, DestinationRule, PeerAuthentication, AuthorizationPolicy, Gateway, Sidecar. Són sis objectes més per dominar, i la seva interacció no és òbvia.
• L'ordre d'arrencada importa. Un contenidor que crida la xarxa abans que el seu proxy estigui llest falla de maneres desconcertants.
• Actualitzar-la és una operació delicada, perquè toca el camí del trànsit de tot el que corre al clúster.

La regla honesta: una malla de serveis comença a compensar a partir de, aproximadament, vint serveis que es criden entre si, mantinguts per més de tres equips, en més d'un llenguatge. Per sota d'això, el cost d'operar-la supera el que aporta.

AlpinaShop té un servei de catàleg, una funció d'imatges i uns quants processos per lots. Posar-hi una malla és com muntar un aeroport per a un carril bici. No és que sigui mala tecnologia: és que no hi ha problema a resoldre.

Binary Authorization respon a una altra pregunta: aquesta imatge concreta té permís per executar-se en aquest entorn? Funciona també com a control d'admissió, però en lloc de mirar la forma del recurs, comprova signatures criptogràfiques.

El flux és:

1. Cloud Build construeix la imatge i la publica a Artifact Registry (06-01).
2. Un procés de verificació —l'escaneig de vulnerabilitats, o el pas manual d'aprovació de la Marta— crea un atestat (attestation): una signatura que diu «aquesta imatge, identificada pel seu digest, ha passat aquest control».
3. En desplegar, Binary Authorization comprova que existeixen els atestats exigits per la política. Si no, rebutja el pod.

Detalls importants:

• ENFORCED_BLOCK_AND_AUDIT_LOG bloqueja i registra. Existeix DRYRUN_AUDIT_LOG_ONLY, que és per on cal començar, igual que amb Policy Controller.
• admissionWhitelistPatterns és una llista d'excepcions per patró de nom. Fes-la servir amb compte: cada excepció és un forat permanent.
• Binary Authorization no està limitat a GKE Enterprise: funciona a GKE estàndard i també a Cloud Run, cosa que el fa rellevant per a AlpinaShop encara que descarti la flota. Es reprèn a 07-04 com a peça de la cadena de subministrament.

Els clústers registrats envien les seves mètriques i registres a Cloud Monitoring i Cloud Logging del projecte de la flota, inclosos els que són fora de Google Cloud. Això significa que el tauler de campanya que AlpinaShop va construir a 06-04 podria mostrar, a la mateixa pantalla, la latència del catàleg a europe-west1 i la del procés que corre a la rebotiga de Sabadell.

És un avantatge real i sovint subestimat: en un híbrid mal muntat, el 80 % del temps d'un incident se'n va a obrir tres eines diferents i comparar rellotges que no estan sincronitzats.

La consola de GKE Enterprise afegeix a més una vista de flota amb:

• Estat de sincronització de cada clúster (el Last_Synced_Token de l'apartat 10).
• Percentatge de compliment de polítiques i llista de violacions.
• Versions de Kubernetes i avisos de fi de suport per clúster.
• Cost estimat agrupat per equip, si les etiquetes estan ben posades.

Aquí és on es prenen les decisions reals, i on convé ser molt clar.

GKE Enterprise no es factura per consum puntual com una VM: es factura com una edició de GKE, amb un preu per vCPU dels nodes dels clústers inclosos a la flota, mensual o amb compromís anual. Google publica els preus i canvien; l'ordre de magnitud que cal tenir al cap és:

Verifica sempre els preus a la documentació oficial i amb la calculadora de preus. Les xifres de dalt són ordres de magnitud per raonar, no cotitzacions.

Fem el càlcul per a AlpinaShop, que és el que decideix:

• El clúster alpinashop-cluster és Autopilot i sosté el catàleg amb l'equivalent a unes 8 vCPU en horari normal.
• Un recàrrec de l'ordre de 5 € per vCPU i mes són uns 40 € al mes només de llicència, sense comptar el còmput.
• A això caldria sumar-hi el consum extra dels sidecars de la malla (10-30 % més de CPU i memòria) i, si de debò es volgués híbrid, un clúster a Sabadell amb el seu maquinari, la seva subscripció i el seu manteniment.

Quaranta euros al mes no arruïnen ningú. El problema no són els diners: és que es paga per capacitats que no es faran servir. I hi ha un cost molt més gran amagat al darrere: les hores de la Marta aprenent, operant i depurant sis objectes nous d'Istio per a un únic servei.

Entre «no fer res» i «adoptar GKE Enterprise» hi ha un espectre. Aquestes són les opcions intermèdies, ordenades de menor a major compromís.

Dos apunts:

• «Cloud Run for Anthos», que apareix en documentació i exàmens antics, permetia executar l'API de Cloud Run sobre un clúster propi mitjançant Knative. Ha quedat en desús a favor de Cloud Run sense més (07-02) i de la malla gestionada. Si el veus en un temari de certificació, ja saps de què es parlava.
• Config Connector mereix una consideració honesta: és una alternativa real a Terraform si —i només si— el teu equip ja treballa íntegrament a Kubernetes. Per a AlpinaShop, que acaba d'invertir el mòdul 6 en Terraform, afegir un segon sistema per al mateix seria un retrocés.

Aquesta és la taula que un s'emporta de la lliçó.

I la pregunta única que resol la majoria dels casos:

Tinc càrregues de treball executant-se fora de Google Cloud que necessiten la mateixa gestió que les de dins?

Si la resposta és «no, només necessito parlar amb un sistema de fora», no necessites Anthos: necessites xarxa.

La Marta, el Dani i la Lucía es van asseure amb aquesta informació i van escriure la decisió, seguint el mateix format que DA-001, DA-002 i DA-003. És al README d'alpinashop-infra, com mana la disciplina de 06-02.

DA-004 — Estratègia híbrida i integració amb la botiga de Sabadell Data: 2026-08-05 · Autors: Marta (infraestructura), Dani (backend) · Estat: acceptada

1. Context. La botiga física de Sabadell executa un ERP amb MySQL 5.7 en un servidor local, amb un terminal de radiofreqüència i un TPV lligats a ell per la xarxa local. L'ERP no pot migrar enguany per llicenciament del fabricant i pressupost. La botiga en línia necessita de l'ERP dues coses: llegir l'estoc cada pocs minuts i abocar les comandes web. L'equip d'infraestructura és d'una persona.

2. Opcions considerades.

3. Decisió. AlpinaShop no adopta GKE Enterprise ni Google Distributed Cloud. S'estableix connectivitat privada amb la botiga mitjançant Cloud VPN HA (dos túnels amb BGP sobre Cloud Router, detallat a 07-03) i la integració es resol així:

• Estoc: un treball programat amb Cloud Scheduler + Workflows (04-06) llegeix cada 10 minuts les taules d'existències del MySQL de Sabadell a través del túnel i actualitza el catàleg.
• Comandes: cada comanda web publica al topic pedidos-nuevos (04-04); un consumidor les insereix a l'ERP. Si l'enllaç està caigut, els missatges esperen a la subscripció i es processen en tornar — la botiga en línia no s'atura perquè Sabadell no estigui disponible.
• Sense connexió: el TPV i el terminal continuen funcionant contra l'ERP local exactament igual que avui. No s'introdueix cap dependència nova del núvol en l'operació de la botiga física.

4. Conseqüències.

• Positives: cost marginal (el de dos túnels VPN); cap tecnologia nova per aprendre; el desacoblament per Pub/Sub fa que un tall de l'enllaç sigui un retard, no una caiguda.
• Negatives: la gestió continua sent doble —l'ERP s'apedaça a mà a Sabadell— i no hi ha polítiques uniformes entre les dues bandes. S'accepta: és un servidor, no una flota.
• S'adopta parcialment una peça: Policy Controller en mode dryrun sobre alpinashop-cluster mentre el catàleg hi continuï, perquè aporta valor amb un sol clúster i sense llicència Enterprise en el seu nivell bàsic. Es revisarà quan el catàleg es mogui a Cloud Run a 07-02.

5. Revisió. Aquesta decisió es revisa si passa qualsevol d'aquestes tres coses: s'obren dues botigues físiques més, l'ERP migra al núvol, o el nombre de serveis que es criden entre si supera la desena.

• Confondre «híbrid» amb «tenir una VPN». Tenir connectivitat privada amb un sistema local no et converteix en una arquitectura híbrida gestionada. És bo saber-ho: probablement no necessites la plataforma gran.
• Adoptar la malla de serveis «perquè és la bona pràctica». És una bona pràctica a partir de certa escala. Per sota, és sobrecàrrega operativa pura.
• Activar Policy Controller directament en deny. Bloquejaràs desplegaments legítims el primer dia. dryrun una setmana, mesures, corregeixes, i llavors deny.
• Oblidar excludedNamespaces a les polítiques. Si la política aplica a kube-system, el clúster deixa de funcionar. Exclou sempre kube-system, gke-system, gatekeeper-system i config-management-system.
• Buscar documentació pel nom antic i quedar-se amb instruccions obsoletes. «Anthos Service Mesh» i «Cloud Service Mesh» són el mateix producte en dues èpoques, i les comandes han canviat. Comprova sempre la data de la pàgina.
• Creure que multinúvol redueix el bloqueig per proveïdor. Sovint l'augmenta: afegeix una capa d'abstracció que també és d'algú, i obliga a fer servir el mínim comú denominador de tots dos núvols.
• Ignorar l'egress entre núvols. Moure dades de GCP a AWS i viceversa es paga per gigabyte en totes dues direccions. Una arquitectura multinúvol «elegant» que creui dades constantment pot duplicar la factura. Es tracta a 07-05.
• Registrar clústers a la flota sense --enable-workload-identity. Acabaràs repartint claus JSON, exactament el que 03-04 va ensenyar a evitar.
• Consell: fes servir Config Sync encara que no vagis a ser híbrid. GitOps sobre un sol clúster ja elimina la deriva de configuració, i és de les millores amb millor relació valor/esforç del catàleg.
• Consell: si dubtes entre híbrid i migrar, calcula la data d'amortització del maquinari. Moltes vegades la resposta correcta és «híbrid durant 18 mesos i després núvol», i això canvia per complet quanta plataforma val la pena muntar.
• Consell: escriu la decisió. DA-004 existeix perquè d'aquí a dos anys ningú no hagi de reconstruir per què no es va adoptar. I perquè, quan es compleixin les condicions de revisió, es revisi de debò.

Per a cadascun d'aquests casos, decideix si convé GKE Enterprise / Google Distributed Cloud, una altra alternativa més lleugera, o res, i justifica-ho en tres o quatre línies.

(a) Una cadena de 60 supermercats. Cada botiga té caixes que han de cobrar encara que internet caigui, i un sistema d'etiquetatge electrònic que s'actualitza cada hora. Central amb equip de 8 persones de sistemes.

(b) Una startup de 12 persones amb un backend de 4 microserveis a GKE Autopilot, tot a europe-west1. El CTO vol «estar preparats per a multinúvol».

(c) Una asseguradora que acaba de comprar una empresa més petita. La compradora és a Google Cloud; la comprada té 40 aplicacions en un centre de dades propi amb contracte d'allotjament vigent fins d'aquí a 3 anys. Tots dos equips es mantenen.

(d) Un fabricant amb una planta a Saragossa. Un sistema de visió artificial inspecciona peces a 30 imatges per segon i ha de decidir en menys de 50 ms si rebutja la peça. Volen a més entrenar models amb les imatges històriques.

AlpinaShop vol garantir dues coses més a alpinashop-cluster:

1. Cap contenidor no pot executar-se com a root.
2. Tot contenidor ha de declarar límits de CPU i memòria (perquè Autopilot no facturi sorpreses i perquè un pod desbocat no ofegui els altres).

Escriu els dos Constraint fent servir la biblioteca de plantilles (K8sPSPAllowPrivilegeEscalationContainer i K8sContainerLimits), indica on col·locar-los al repositori alpinashop-infra, i descriu el procediment complet de desplegament segur. Explica a més què comprovaries abans de passar a deny.

Un integrador presenta a la direcció d'AlpinaShop aquesta proposta:

«Recomanem desplegar Google Distributed Cloud a la botiga de Sabadell i adoptar GKE Enterprise amb Cloud Service Mesh. Així unificareu la gestió, tindreu mTLS extrem a extrem entre la botiga i el núvol, polítiques homogènies i observabilitat centralitzada, quedant preparats per al creixement multinúvol. Inversió: 18.000 € el primer any més 900 €/mes.»

Escriu la resposta tècnica de la Marta a la direcció: quines parts de la proposta són certes, quines són irrellevants per a AlpinaShop, quines preguntes cal fer a l'integrador, i quina contraproposta es planteja amb el seu cost aproximat.

Solució 1 — Decidir amb criteri en quatre escenaris

(a) Cadena de 60 supermercats: SÍ, i és el cas de manual.

Hi concorren els tres factors decisius alhora. Funcionament sense connexió: les caixes han de cobrar amb l'enllaç caigut, per tant hi ha d'haver còmput local per obligació, no per preferència. Escala: 60 emplaçaments són 60 clústers, i gestionar-los un a un és inviable — aquí la flota deixa de ser un luxe i passa a ser l'única manera de mantenir el seny. Equip: 8 persones poden sostenir la plataforma.

La solució és Google Distributed Cloud a cada botiga, totes registrades en una flota, amb Config Sync distribuint la configuració des de Git. Fixa't en l'avantatge del model d'estirada: les 60 botigues no necessiten ser accessibles des de fora; surten elles a buscar la seva configuració. Actualitzar el programari d'etiquetatge electrònic a 60 botigues passa a ser un commit.

La malla de serveis, en canvi, s'avaluaria a part i probablement més tard: el valor aquí és a la gestió de flota, no al mTLS entre serveis.

(b) Startup de 12 persones: NO, amb claredat.

«Estar preparats per a multinúvol» amb 4 microserveis en un sol clúster no és una arquitectura: és una preocupació sense cas d'ús. El cost de la preparació es paga avui, tots els mesos, i el benefici potser no arribarà mai.

El que sí que convé fer, i és gratis:

• Mantenir les aplicacions contenidoritzades i sense dependències propietàries al camí crític, que ja ho estan.
• Gestionar la infraestructura amb Terraform, que és multiproveïdor per disseny.
• Que les dades siguin exportables (formats estàndard, pg_dump, Parquet).
• Escriure al README en quins serveis s'està acoblat a propòsit i per què.

Amb això, el dia que hi hagi un motiu real per moure's, la sortida és de setmanes. I mentrestant s'aprofita el que és bo de GCP en lloc de renunciar-hi. Si a més volen configuració com a codi, Config Sync sobre el clúster que ja tenen és la millora amb millor retorn.

(c) Asseguradora després d'una fusió: PROBABLEMENT SÍ, i és el cas més matisat.

Hi concorren: inversió sense amortitzar (contracte d'allotjament a 3 anys, que són diners compromesos), 40 aplicacions (volum que justifica una plataforma), i dos equips que es mantenen (hi ha mans). A més, en un sector regulat, tenir polítiques de seguretat demostrablement uniformes a banda i banda té valor d'auditoria, no només tècnic.

L'estratègia sensata és híbrid amb data de caducitat: registrar els clústers de totes dues bandes en una flota, unificar polítiques amb Policy Controller i observabilitat amb Cloud Logging/Monitoring, i fer servir aquests 3 anys per migrar per onades les aplicacions que tinguin sentit. L'error seria adoptar-ho com a estat permanent sense pla de convergència; l'altre error seria intentar migrar 40 aplicacions de cop.

Les preguntes que decidirien el detall: quantes d'aquestes 40 aplicacions estan contenidoritzades? Si en són 3, la flota no ajuda les altres 37 i el problema real és de modernització, no de plataforma.

(d) Fabricant amb visió artificial: SÍ, però a la vora i per un motiu diferent.

50 ms de pressupost total per capturar, inferir i decidir fan que el núvol sigui impossible: només l'anada i tornada a europe-southwest1 des de Saragossa en consumeix una part significativa, i un tall de xarxa aturaria la línia de producció. La inferència ha de ser local, i no hi ha discussió possible.

Arquitectura: Google Distributed Cloud (o simplement maquinari amb GPU i un runtime d'inferència) a la planta executant el model; les imatges i els resultats es pugen de manera asíncrona a Cloud Storage; l'entrenament es fa a Vertex AI (mòdul 5) amb l'històric; els models nous es despleguen a la planta des del registre de models.

És el patró canònic de la vora: inferència a baix, entrenament a dalt. I observa que la part que justifica la plataforma no és la latència en si, sinó que la línia no pot parar si cau l'enllaç.

Solució 2 — Escriure i desplegar una política de conformitat

Ubicació al repositori. Tots dos fitxers van a config-flota/cluster/politicas/, perquè són polítiques de clúster i no d'un espai de noms concret:

Política 1 — sense escalada de privilegis:

Política 2 — límits de CPU i memòria:

Fixa't que K8sContainerLimits fa dues coses alhora, i convé saber-ho: exigeix que els límits existeixin i a més que no superin els valors indicats. Els valors 2 vCPU i 4Gi són el sostre per contenidor; es trien mesurant el consum real i deixant marge, no a ull.

Procediment de desplegament segur, pas a pas:

1. Branca i pull request a alpinashop-infra. Mai directe a main: la revisió és part del control (06-02).
2. Validació local abans de pujar, per no descobrir un error de sintaxi en producció:

   kubectl apply --dry-run=server -f config-flota/cluster/politicas/
   

3. Merge a main després de la revisió. Config Sync ho detecta en 30 segons.
4. Verificar la sincronització, que és el pas que la gent es salta:

   gcloud beta container fleet config-management status
   nomos status   # eina especifica de Config Sync, mes detallada
   

5. Esperar entre 7 i 14 dies en dryrun, cobrint almenys un cicle complet de desplegaments i els processos per lots nocturns i setmanals. Una setmana que no inclogui el tancament mensual pot amagar un incompliment.
6. Revisar violacions:

   kubectl get constraints -o json | jq -r '
     .items[] | select(.status.totalViolations > 0) |
     "\\(.metadata.name): \\(.status.totalViolations) violacions"'
   

7. Corregir l'origen, no la política. Si un pod necessita més de 2 vCPU legítimament, es puja el paràmetre amb justificació escrita; si no ho necessita, es corregeix el pod.
8. Canviar a deny en un pull request separat del que va introduir la política, perquè el canvi de mode sigui visible a l'historial i es pugui revertir sol.

Què comprovar abans de passar a deny —la llista de la Marta:

• Zero violacions durant almenys 7 dies consecutius.
• Els CronJob setmanals i mensuals s'han executat almenys una vegada en aquest període.
• Els espais de noms del sistema estan exclosos i s'ha verificat, no suposat.
• Existeix un procediment d'excepció documentat: com demana algú una exempció, qui l'aprova i quan caduca.
• El procediment de reversió està escrit: git revert del commit i esperar 30 segons. Saber que la tornada enrere costa un minut és el que permet avançar amb tranquil·litat.

Solució 3 — Rebatre la proposta d'un proveïdor

Resposta de la Marta a direcció.

Què és cert de la proposta. Tot el que és tècnic. GKE Enterprise unifica de debò la gestió de clústers, Cloud Service Mesh proporciona mTLS automàtic sense tocar el codi, Config Sync i Policy Controller apliquen polítiques homogènies, i l'observabilitat es centralitza. L'integrador no exagera cap capacitat. El problema no és que sigui fals; és que respon a preguntes que no ens hem fet.

Què és irrellevant per a nosaltres, punt per punt.

• «Unificareu la gestió»: unificar la gestió d'un clúster al núvol i un servidor ERP que ni tan sols executa contenidors. No hi ha flota per gestionar; hi ha dos sistemes diferents que només necessiten intercanviar dos fluxos de dades.
• «mTLS extrem a extrem entre la botiga i el núvol»: un túnel IPsec de Cloud VPN ja xifra aquest trànsit, i costa uns pocs euros al mes. El mTLS de la malla resol el xifratge entre serveis, i nosaltres tenim un servei.
• «Polítiques homogènies»: valuós a partir de diversos clústers. Amb un, Policy Controller aporta —i el farem servir—, però això no requereix la llicència Enterprise ni el desplegament a la botiga.
• «Preparats per al creixement multinúvol»: no hi ha cap pla de negoci que contempli un altre núvol. Estaríem pagant avui per una opció que ningú no ha demanat.
• A més, introdueix un risc nou que la proposta no esmenta: maquinari de Google a la rebotiga d'una botiga que avui funciona amb un servidor i un SAI. Això és un element més que es pot trencar, actualitzar i quedar-se sense suport, en un lloc sense personal tècnic.

Preguntes per a l'integrador. Són les que revelen si la proposta es va fer per a nosaltres o és una plantilla:

1. Quines càrregues de treball en contenidors executarem a la botiga de Sabadell? (Resposta real: cap. L'ERP és una aplicació d'escriptori amb MySQL.)
2. Quants serveis es criden entre si a la nostra arquitectura actual? (Resposta real: pràcticament un. La malla no té res a mallar.)
3. Els 900 €/mes, inclouen suport, actualitzacions del maquinari de la botiga i les hores d'operació, o només la llicència?
4. Què passa el dia que el catàleg es mogui a Cloud Run segons DA-001? Bona part d'aquesta proposta deixa d'aplicar, perquè ja no hi haurà clúster per gestionar.
5. Qui opera això? Som una persona d'infraestructura. S'inclou servei gestionat 24×7, i a quin preu?
6. Quin és el cost i el termini de sortir d'aquesta arquitectura si d'aquí a dos anys no encaixa?

Contraproposta.

Cost total de l'ordre de desenes d'euros al mes, davant de 18.000 € més 900 €/mes. La diferència no s'estalvia: s'inverteix en el que sí que ens falta —fiabilitat, SLO i recuperació davant de desastres (07-06)—, que és on avui tenim el risc de debò.

La frase per a direcció. No estem rebutjant la proposta perquè sigui cara, sinó perquè resol el problema d'una empresa que no som. Si obrim cinc botigues més i l'ERP migra a contenidors, hi tornarem a mirar — i per això queda escrit a DA-004 quan es revisa.

Has entès el mapa complet de l'híbrid i el multinúvol, i —més important— saps situar-t'hi.

Distingeixes híbrid, multinúvol, vora i aquella quarta categoria que ningú no anomena, el multinúvol accidental, que és la situació real de gairebé tothom. Coneixes els cinc motius per no ser només en un núvol en la seva versió honesta: la inversió prèvia que caduca sola, la latència l'argument fort de la qual no són els mil·lisegons sinó el funcionament sense connexió, la regulació amb els seus tres nivells —residència, sobirania i control físic— que gairebé ningú no distingeix, la dependència del proveïdor que té graus i la gestió correcta de la qual és saber en quin ets, i la continuïtat que gairebé sempre es resol amb una altra regió i no amb un altre núvol. I coneixes els costos ocults de cada model, amb el més car subratllat: l'humà.

Saps què és Anthos i en què s'ha convertit: GKE Enterprise per a la gestió unificada de clústers, Google Distributed Cloud per al programari de Google fora de Google, GKE Multi-Cloud per a clústers sobre AWS i Azure, i Cloud Service Mesh per a la malla. Reconeixeràs el nom antic en documentació i exàmens i el sabràs traduir.

Domines el concepte central, la flota, i la seva conseqüència menys evident i més potent: la igualtat d'espais de noms, que converteix tienda en «l'equip de la botiga» a tots els clústers alhora. Coneixes els seus components un a un, amb Config Sync —GitOps d'estirada, amb l'avantatge decisiu de no exigir accés entrant als emplaçaments remots— i Policy Controller —Gatekeeper gestionat, amb la seva biblioteca de plantilles i l'imprescindible dryrun abans de deny— com els dos que aporten valor fins i tot amb un sol clúster.

Ho has fet a la pràctica: registrar alpinashop-cluster en una flota, activar Config Sync contra alpinashop-infra, escriure dues polítiques reals —només imatges de l'Artifact Registry propi i etiquetes obligatòries amb valors validats—, mesurar les seves violacions en dryrun, corregir l'origen i només llavors denegar. Amb l'error número u assenyalat: excloure sempre els espais de noms del sistema.

Entens la malla de serveis sense fum: què resol de debò —mTLS automàtic amb identitat per servei i telemetria uniforme sense tocar el codi— i quina complexitat afegeix —contenidors duplicats, un salt de xarxa més, sis objectes nous i una depuració més difícil—, amb el llindar honest d'uns vint serveis i diversos equips per sota del qual no compensa. I coneixes Binary Authorization com a control d'admissió per signatura, que tornarà a 07-04 i que, a diferència de la malla, sí que aplica a Cloud Run.

Saps com es factura —per vCPU de la flota, com a edició de GKE— i per què el preu no és el que decideix: el que decideix és que es paga per capacitats que no es faran servir i per hores d'aprenentatge que no es tenen. Coneixes les alternatives lleugeres, de Cloud VPN i Pub/Sub com a pont fins a Config Connector, amb la nota històrica de Cloud Run for Anthos. I t'emportes la taula de quan sí i quan no amb la seva pregunta resum: tinc càrregues executant-se fora de GCP que necessitin la mateixa gestió? Si només necessites parlar amb un sistema de fora, no necessites Anthos: necessites xarxa.

I tens DA-004 escrita: AlpinaShop no adopta GKE Enterprise. Connecta amb Sabadell per Cloud VPN HA, sincronitza l'estoc amb Workflows cada deu minuts, aboca les comandes per Pub/Sub amb tolerància a talls, manté el TPV funcionant sense connexió, adopta Policy Controller en dryrun perquè aporta amb un sol clúster, i deixa escrites les tres condicions que obligarien a revisar la decisió.

Queda pendent el que aquesta decisió implica en dos fronts. Un és la xarxa: el túnel a Sabadell, el Cloud Router, l'adreçament que no es pot encavalcar i tot el que cal dissenyar perquè dues xarxes que van néixer per separat es parlin sense sorpreses — és 07-03.

L'altre és més antic. Aquesta lliçó ha decidit no muntar una plataforma de contenidors més gran; la següent fa just el contrari i en munta una més petita. Perquè si AlpinaShop té un sol servei web, amb trànsit irregular, ja contenidoritzat i sense estat, la pregunta que porta pendent des de 02-07 té una resposta que ja no es pot ajornar. DA-001 es compleix a la propera lliçó: el catàleg se'n va a Cloud Run.