Fins ara, cada peça de Quilòmetre Zero ha corregut en màquines concretes: els tres nodes de Cassandra que Ansible va configurar a 07-05, els brokers de Kafka que es reinicien d'un en un respectant les ISR, el clúster de Patroni amb el seu etcd, el MinIO amb els seus discos, el clúster de Kubernetes sobre el qual es despleguen els sis serveis. Algú ha comprat aquestes màquines, les ha instal·lat en un centre de dades, els ha posat discos i xarxa, i les substitueix quan fallen. I quan a 07-03 es va decidir un pla de recuperació davant de desastres en pilot light amb una "regió secundària", es va deixar oberta la pregunta d'on és aquesta regió i qui l'opera. Aquesta lliçó hi respon canviant la premissa: la infraestructura passa a ser una API que un proveïdor ofereix sota demanda, amb regions i zones de disponibilitat, xarxes virtuals, balancejadors, autoescalat i, sobretot, serveis gestionats que fan per nosaltres el que al curs hem muntat a mà. Veurem els models de servei i de desplegament, els conceptes que canvien el disseny (regions i zones, VPC, elasticitat), la correspondència entre cada component de Quilòmetre Zero i el seu equivalent gestionat a AWS i GCP, els avantatges i els desafiaments (inclòs el que exigeix una revisió legal), la infraestructura com a codi amb Terraform, els pilars d'una arquitectura ben dissenyada, i una introducció a FinOps amb el cost mensual aproximat de la plataforma. La pràctica desplega Quilòmetre Zero a AWS amb Terraform i els manifestos k8s/ de 07-05. Serverless, edge i CDN queden per a 08-04.

1. Models de servei: IaaS, PaaS, SaaS i la responsabilitat compartida
2. Models de desplegament: pública, privada, híbrida i multinúvol
3. Regions, zones de disponibilitat i recuperació davant de desastres
4. Xarxes al núvol: VPC, subxarxes, balancejadors i autoescalat
5. Serveis gestionats: què substitueix cada peça de Quilòmetre Zero
6. Avantatges i desafiaments: elasticitat, pagament per ús, lock-in, egress i compliment
7. Infraestructura com a codi amb Terraform
8. Arquitectura ben dissenyada: els pilars
9. FinOps: etiquetes, reserves, spot, pressupostos i el cost de Quilòmetre Zero
10. Pràctica: Quilòmetre Zero a AWS amb Terraform i EKS
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

El núvol es defineix pel que el proveïdor assumeix i el que continua sent responsabilitat del client. Aquesta línia es mou segons el model de servei, i saber on és en cada cas és el que evita tant pagar pel que no s'usa com suposar que "el núvol ho fa" quan no ho fa.

Dues files no canvien mai de columna: les dades i les identitats són sempre del client. Aquest és el model de responsabilitat compartida que tots els proveïdors publiquen: el proveïdor respon de la seguretat del núvol (que ningú no accedeixi físicament al disc, que l'hipervisor aïlli), el client de la seguretat al núvol (que el bucket no sigui públic, que el rol IAM no tingui *, que les dades personals estiguin xifrades i a la regió correcta). Un bucket km0-factures accessible sense autenticació és responsabilitat del client en qualsevol model.

Per a Quilòmetre Zero, el repartiment natural és: PaaS per a tot el que té equivalent gestionat (bases de dades, Kafka, Kubernetes, memòria cau, objectes), IaaS només on no n'hi ha o on el control compensa (els nodes de treball de Kubernetes són IaaS per sota, però gestionats com a grup), i SaaS per al que no aporta diferència (identitat, observabilitat si es decideix externalitzar-la).

Quilòmetre Zero, que avui té el seu propi maquinari, passarà a núvol públic amb un període híbrid durant la migració (l'enllaç VPN entre el centre de dades i la VPC permet que Kafka repliqui amb MirrorMaker i que Patroni tingui una rèplica al núvol abans del tall). El multinúvol es descarta explícitament: amb quatre equips, operar dos proveïdors costaria més que el risc que mitiga, i la portabilitat es manté d'una altra manera, amb Kubernetes com a capa de desplegament i amb contenidors per al que no és gestionat (apartat 6).

Un proveïdor organitza la seva infraestructura en regions (una zona geogràfica: Irlanda, Frankfurt, París...) i, dins de cada regió, en diverses zones de disponibilitat (availability zones, AZ): centres de dades físicament separats (quilòmetres de distància, energia i xarxa independents) però connectats amb latència d'1-2 ms. Aquesta estructura es correspon directament amb els dominis de fallada de 07-03:

• Una AZ és un domini de fallada de centre de dades: incendi, tall d'energia, fallada de xarxa de l'edifici. Distribuir les rèpliques entre AZ (els tres nodes de Cassandra en tres AZ; el primari de Patroni i la seva rèplica síncrona en AZ diferents; els brokers de Kafka amb broker.rack = AZ perquè les rèpliques de cada partició es reparteixin) fa que la pèrdua d'una AZ no sigui un desastre, només un failover. És el que a 07-05 feia topologySpreadConstraints amb l'etiqueta de zona.
• Una regió és un domini de fallada geogràfic (i regulatori): un desastre natural, una fallada d'un servei regional del proveïdor, o un canvi legal. La regió secundària de 07-03 és una altra regió del mateix proveïdor, a centenars o milers de quilòmetres, amb latència de 10-80 ms, cosa que descarta la replicació síncrona entre elles.

Amb això, les tres estratègies de DR de 07-03 es concreten al núvol:

Quilòmetre Zero manté la decisió de 07-03 (pilot light) per cost, amb una diferència important respecte del centre de dades propi: al núvol, la regió secundària no costa res mentre està buida. Terraform pot crear la infraestructura de la regió secundària en 20 minuts a partir del mateix codi; l'única cosa que ha d'existir per endavant són les dades replicades. L'activa-activa es deixa com a pas següent a 08-05, perquè implica resoldre conflictes d'escriptura entre regions (03-04) i canviaria el model de consistència de l'estoc.

Una VPC (Virtual Private Cloud) és una xarxa privada aïllada dins de la regió, amb el seu rang d'adreces (10.0.0.0/16), dividida en subxarxes que pertanyen cadascuna a una AZ. La convenció que Quilòmetre Zero adopta, i que és l'habitual, és de tres capes per AZ:

Els grups de seguretat són tallafocs amb estat per recurs, i expressen les mateixes regles que les polítiques de xarxa de Kubernetes de 07-05 però a la capa de la VPC: RDS només accepta 5432 des del grup de seguretat dels nodes d'EKS; MSK només 9094 (TLS) des d'EKS; res des de fora. Els serveis gestionats com S3 s'assoleixen per endpoints de VPC, que eviten que el trànsit cap a km0-fotos surti a Internet (i eviten el cost del NAT).

Els balancejadors gestionats substitueixen l'Ingress + Kong de 07-05 en la seva capa externa: un balancejador d'aplicació (ALB a AWS, HTTP(S) Load Balancer a GCP) termina TLS amb certificats gestionats i renovats automàticament, reparteix entre les AZ, fa health checks i exposa una IP a diverses AZ. Kong continua existint al darrere, com a gateway amb els seus plugins (06-05); el balancejador és només la porta de la regió. El WebSocket de 08-02 exigeix que el balancejador suporti Upgrade i tingui un timeout d'inactivitat llarg (l'ALB ho permet; un balancejador de xarxa de capa 4 ho passa sense mirar).

L'autoescalat opera en dos nivells que cal distingir: l'HPA de 07-05 afegeix Pods segons CPU o lag de Kafka, però els Pods necessiten nodes; l'autoescalador del clúster (Cluster Autoscaler o Karpenter a EKS, l'autoescalat de node pools a GKE) afegeix i treu màquines virtuals quan hi ha Pods pendents o nodes buits. Per sota, un grup d'autoescalat de màquines virtuals (Auto Scaling Group) les reemplaça si fallen un health check i les reparteix entre AZ. La Setmana de la Verema amb k6 (07-06) es converteix així en: l'HPA puja comandes de 3 a 12 Pods → 6 Pods pendents per falta de CPU → Karpenter arrenca 2 nodes en 90 s → els Pods es programen. Aquests 90 s són la raó de mantenir marge (nodes amb capacitat lliure) abans d'una campanya anunciada, o d'escalar per calendari.

Aquesta taula és la correspondència entre el que s'ha construït al curs i el que el proveïdor ofereix gestionat. A cada fila, el que es guanya és el que el proveïdor assumeix (instal·lació, pedaços, failover, backups, escalat) i el que es perd és control i portabilitat.

Tres notes sobre aquesta taula. Primera: Pub/Sub de GCP no és Kafka: no té particions ni offsets a l'estil Kafka (encara que ofereix ordenació per clau i reproducció), i el codi de consumidors amb grups i commits canvia; si es vol Kafka a GCP, és Confluent Cloud. Segona: Keyspaces és compatible amb CQL però no és Cassandra: el nivell de consistència i les transaccions lleugeres tenen diferències que cal verificar amb el repositori de 04-04 abans de migrar. Tercera: el que és gestionat no elimina l'operació, la canvia: ja no s'apedaça PostgreSQL, però continua calent dimensionar la instància, triar la finestra de manteniment (RDS reinicia per aplicar pedaços majors), provar les restauracions i vigilar les connexions.

A 07-05 es van distingir les eines de configuració (Ansible: deixar una màquina existent en un estat) de les d'aprovisionament (Terraform: crear la infraestructura mateixa), i es va remetre aquí. Quan la infraestructura és una API, descriure-la com a codi és el que permet revisar-la en pull request, reproduir-la en una altra regió i saber què existeix. Terraform (i la seva bifurcació oberta OpenTofu) és declaratiu: es descriu l'estat desitjat en fitxers .tf (llenguatge HCL) i l'eina calcula i executa les crides a l'API necessàries per arribar-hi, en l'ordre que dicten les dependències.

Quatre conceptes són suficients per llegir i escriure la pràctica de l'apartat 10:

1. Proveïdors (providers): plugins que tradueixen recursos a crides d'API (aws, google, kubernetes, helm, kafka...). Es declaren amb versió fixada.
2. Recursos i dades: resource "aws_db_instance" "inventari" { ... } crea; data "aws_availability_zones" "disponibles" {} consulta. Es referencien entre ells (aws_vpc.km0.id), i aquestes referències són el graf de dependències.
3. Estat remot: Terraform desa en un fitxer d'estat la correspondència entre el que s'ha declarat i el que existeix (ids reals). Aquest fitxer és crític i compartit: es desa en un backend remot (S3 amb versionat, i una taula de DynamoDB com a cadenat perquè dues persones no apliquin alhora; és el mateix problema d'exclusió mútua de 03-03 resolt amb un servei gestionat), es xifra i mai no es puja a Git. Conté secrets (contrasenyes inicials d'RDS), cosa que reforça l'anterior.
4. Mòduls: carpetes de .tf reutilitzables amb variables d'entrada i sortides (module "vpc" { source = "terraform-aws-modules/vpc/aws" ... }). Quilòmetre Zero usa mòduls de la comunitat per a VPC i EKS (centenars de recursos que no val la pena escriure a mà) i mòduls propis per a cada entorn.

El cicle és terraform init (descarrega proveïdors i mòduls, connecta amb l'estat), terraform plan (calcula el diff entre el que s'ha declarat i l'estat i el mostra: + crear, ~ modificar, - destruir, -/+ reemplaçar), i terraform apply (l'executa després de confirmar). El plan és la peça més valuosa: s'executa al pipeline (07-05) i s'enganxa a la pull request; un -/+ sobre aws_db_instance.inventari (reemplaçar la base de dades) és el que una revisió ha d'aturar. En GitOps, apply només l'executa el pipeline després del merge, mai una persona des del seu portàtil.

Els proveïdors publiquen marcs d'"arquitectura ben dissenyada" (well-architected) amb pilars que serveixen com a llista de comprovació. Els sis d'AWS (GCP té una llista equivalent) coincideixen gairebé un a un amb mòduls del curs:

La seva utilitat pràctica és la revisió periòdica: cada semestre, recórrer les preguntes del marc sobre la plataforma i anotar què falta. És un exercici del projecte final (08-05).

Al núvol, el cost és una mètrica més del sistema, i com qualsevol mètrica cal mesurar-la, atribuir-la i posar-hi alertes. La disciplina s'anomena FinOps i, en el seu nivell bàsic, es redueix a cinc pràctiques:

1. Etiquetatge (tagging): tot recurs porta etiquetes equip, servei, entorn, centre_cost. Sense elles, la factura és un número; amb elles, "l'equip de repartiment va gastar 1 840 € al setembre, el 60 % en MSK". Terraform les aplica per defecte a tot (default_tags).
2. Reserves i plans d'estalvi: comprometre's a un ús durant 1 o 3 anys a canvi d'un 30-60 % de descompte. S'aplica a la base que sempre està encesa (els nodes mínims d'EKS, RDS, MSK, ElastiCache), mai al pic.
3. Instàncies spot: capacitat sobrant del proveïdor amb un 60-90 % de descompte, que pot ser retirada amb 2 minuts d'avís. Ideal per al que tolera interrupcions i es reinicia sol: els executors d'Spark (05-03 ja tolerava la pèrdua d'executors recomputant particions), els nodes d'EKS per a càrregues sense estat amb diverses rèpliques. Mai per a RDS, Cassandra, Kafka ni el pla de control.
4. Pressupostos i alertes: un pressupost per equip i entorn, amb alerta al 80 % i al 100 % previstos, i detecció d'anomalies (un NAT gateway que de sobte mou 2 TB perquè algú ha servit les fotos sense CDN). Són alertes com les de 07-01, cap al mateix canal.
5. Apagar el que està ociós: entorns de staging apagats de nit i el cap de setmana (amb Terraform o amb programacions), clústers d'Spark efímers (EMR arrenca per al DAG km0_vendes_diaries i es destrueix en acabar), volums i snapshots orfes.

Els preus següents són ficticis i orientatius, de l'ordre de magnitud correcte per a una regió europea, i serveixen per al raonament, no com a pressupost. L'exercici útil és veure on és el cost, no la xifra exacta.

El que la taula ensenya: el còmput (EKS + bases de dades + Kafka) és dos terços del total; les reserves estalvien un 25-30 % sobre la base; l'egress és la partida més sensible al disseny (la CDN de 08-04 la divideix per sis); i dos serveis gestionats (MWAA, Flink gestionat) costen més que els seus equivalents autogestionats al clúster, cosa que il·lustra que "gestionat" no sempre guanya: la decisió depèn de quant costa el temps de l'equip que l'operaria.

L'estructura del codi d'infraestructura, que s'afegeix al projecte km0/:

El que segueix és main.tf explicat bloc a bloc. Està simplificat (hi falten alguns paràmetres de seguretat i de xarxa que un mòdul real inclou), però cada bloc és real i correspon a una decisió de les seccions anteriors.

Els Pods de comandes i cataleg porten a k8s/comandes-deployment.yaml una toleration per a km0/spot i una affinity que prefereix base, de manera que en campanya desborden a spot; Cassandra, Kafka (si fos autogestionat) i les bases de dades no toleren el taint i mai no cauen en spot. L'autoescalador del clúster (Karpenter, instal·lat amb el proveïdor helm) és qui passa el grup campanya de 0 a 12 segons els Pods pendents.

El que aquí substitueix el que s'havia construït a mà: multi_az = true és Patroni + etcd + rèplica síncrona + failover automàtic (RDS canvia el DNS de l'endpoint a l'standby en ~60 s; l'aplicació només necessita reconnectar, que és el que el pool amb reintents de 07-04 ja fa); backup_retention_period és el pgBackRest i l'arxivat de WAL de 07-03. El que no substitueix: la prova de restauració setmanal, que continua sent un treball d'Airflow que restaura l'últim snapshot en una instància temporal i executa comprovacions.

Els Pods de cataleg necessiten escriure a km0-fotos; els de comandes, llegir els seus secrets. En lloc de credencials de llarga durada en un Secret de Kubernetes (el que 06-04 evitava amb Vault), EKS permet associar un rol IAM a una service account de Kubernetes: el Pod obté credencials temporals automàticament, amb el mínim privilegi, i CloudTrail registra qui ha fet què. És la identitat de càrrega de treball de 06-04 (SPIFFE) amb l'IAM del proveïdor.

Al manifest k8s/cataleg-deployment.yaml n'hi ha prou amb serviceAccountName: cataleg i l'anotació eks.amazonaws.com/role-arn: <arn del rol> a la ServiceAccount; l'SDK d'AWS al Pod (boto3, el mateix fotos.py de 04-03 apuntant a S3 en lloc de a MinIO) troba les credencials sol.

Els manifestos no canvien de forma: canvien els valors de configuració que apunten a les dependències. A 07-05, comandes-config tenia KAFKA_BOOTSTRAP=kafka-0.kafka:9092; ara el genera el pipeline a partir de les sortides de Terraform:

El que desapareix de k8s/ en passar a serveis gestionats: els StatefulSets de PostgreSQL amb Patroni, de Kafka i de Redis, i els seus operadors. El que es queda: els sis serveis, Kong, el mesh, Cassandra (si no s'adopta Keyspaces), Prometheus/Loki/Tempo (si no s'adopta CloudWatch) i Mosquitto. L'HPA de 07-05 funciona igual; el que és nou és Karpenter a sota. I les proves de 07-06 es repeteixen contra l'entorn staging desplegat amb staging.tfvars (instàncies petites, sense Multi-AZ, sense DR), que s'apaga a les nits.

• Suposar que "gestionat" significa "sense operar". RDS continua reiniciant a la finestra de manteniment, MSK continua necessitant dimensionar particions, i ningú no prova les restauracions per nosaltres. El treball canvia, no desapareix.
• Una sola AZ "per estalviar". Un NAT, una subxarxa, RDS sense Multi-AZ: la primera incidència d'AZ del proveïdor és una caiguda total. Multi-AZ per a tot el que sigui al camí d'una comanda.
• Oblidar l'egress i el trànsit entre AZ al pressupost. Són les dues partides que sorprenen a la primera factura. CDN per al que és públic, endpoints de VPC per a S3, client.rack als consumidors de Kafka.
• Rols IAM amb *. Un rol de servei amb s3:* sobre tots els buckets converteix un Pod compromès en una fuita total. Una política per service account, amb accions i recursos concrets (bloc 6).
• L'estat de Terraform a Git o en un portàtil. Conté secrets i és l'únic mapa del que existeix. Backend remot xifrat amb versionat i cadenat, sempre.
• Aplicar sense llegir el pla. Un -/+ sobre una base de dades és una destrucció amb recreació. El pla va a la pull request i deletion_protection a producció.
• Triar la regió només per preu o latència. Les dades personals tenen restriccions de residència; la regió és una decisió amb revisió legal, i documentada.
• Comprar reserves per al pic. Les reserves cobreixen la base que sempre està encesa; el pic va a spot o a sota demanda. Comprar de més és pagar per capacitat que no s'usa.
• Consell: desplega primer staging amb la mateixa configuració de Terraform i mides petites; el 90 % dels errors de xarxa, IAM i grups de seguretat apareixen allà a cost mínim.
• Consell: posa el cost a Grafana al costat de la resta de mètriques (els proveïdors exporten la despesa diària per etiqueta). Un gràfic d'euros per comanda és la mètrica de negoci que més converses útils genera.

Revisa el main.tf de l'apartat 10 i respon: (a) si l'AZ b desapareix sencera, quins components de Quilòmetre Zero es veuen afectats, quin mecanisme recupera cadascun i en quant de temps aproximat; (b) què hauria passat amb one_nat_gateway_per_az = false; (c) quin component del main.tf no sobreviuria a la pèrdua de la regió i què caldria executar per recuperar-lo.

Usant la taula de costos de l'apartat 9 (preus ficticis), calcula l'estalvi o el sobrecost mensual aproximat d'aquestes tres decisions i raona si compensen: (a) substituir MWAA per Airflow a EKS (estimat: 40 € de nodes); (b) passar km0_analitica d'RDS a Multi-AZ; (c) moure els nodes permanents d'EKS de sota demanda a una reserva de 3 anys (descompte estimat 55 % en lloc de 40 %) sabent que l'equip planeja reduir a 4 nodes permanents d'aquí a un any.

Per a cadascun d'aquests components, decideix si Quilòmetre Zero hauria d'usar el servei gestionat del proveïdor o desplegar-lo a EKS, aplicant el criteri de "lock-in selectiu" de l'apartat 6 (benefici del gestionat davant del cost de la dependència): PostgreSQL, Kafka, Cassandra, Keycloak, Vault, Prometheus/Grafana. Justifica cadascuna en dues frases.

Exercici 1.

(a) Amb l'AZ b caiguda: RDS km0_inventari: l'standby era a b (o el primari; RDS ho decideix); si era l'standby, no passa res visible i RDS en crea un de nou en una altra AZ; si era el primari, failover automàtic a l'standby en ~60 s, durant els quals les reserves d'estoc fallen i la saga reintenta (07-04). MSK: el broker 2 cau; les particions el líder de les quals hi era trien nou líder entre les ISR (03-03) en segons; amb min.insync.replicas=2 i RF=3 es continua escrivint. Cassandra: un node de tres; amb QUORUM (2 de 3) es continua llegint i escrivint. ElastiCache: si el primari era a b, failover automàtic a la rèplica (~30 s) i la memòria cau es reomple; si era la rèplica, res. EKS: els nodes de b desapareixen; Kubernetes reprograma els seus Pods a a i c (07-05: topologySpreadConstraints garantia que cap servei no tingués totes les seves rèpliques a b) en 1-3 minuts, i Karpenter afegeix nodes si falta capacitat. ALB: deixa d'enviar a b després de fallar els health checks (segons). NAT: el de b cau, però els nodes de b també, així que ningú no el necessita.

(b) Un sol NAT a, per exemple, l'AZ a: si cau a, els nodes de b i c continuen vius però perden la sortida a Internet: pagaments no assoleix la passarel·la, el pipeline no descarrega imatges. Un component sa queda inutilitzat per un domini de fallada aliè: exactament el que 07-03 anomenava redundància no independent.

(c) Tot el de la regió primària. El que hi ha a la secundària: la rèplica d'RDS (inventari_dr), el bucket replicat i l'MSK mínim amb MirrorMaker. Per recuperar: terraform apply del mateix codi amb region = "eu-central-1" (uns 20-30 min per a VPC + EKS + ElastiCache), promoure la rèplica d'RDS (aws rds promote-read-replica, ~5 min), desplegar els manifestos apuntant als nous endpoints, restaurar Cassandra des dels snapshots replicats a S3 (el pas més llarg i el que fixa l'RPO de comandes), i canviar el registre de Route 53. És el runbook del pilot light de 07-03, i l'RTO real és el que surti al game day, no el de la taula.

Exercici 2.

(a) MWAA 320 € → Airflow a EKS 40 €: estalvi ≈ 280 €/mes (3 360 €/any). Compensa si l'equip de plataforma assumeix operar Airflow (actualitzacions, base de metadades, guàrdia); amb l'operador de Kubernetes i una instància petita d'RDS per a les metadades (~30 € més), continua compensant, i a més evita una dependència específica del proveïdor. És l'exemple que el gestionat no sempre guanya.

(b) 210 € → aproximadament el doble, ≈ 420 €: sobrecost ≈ 210 €/mes. Per a km0_analitica, la pèrdua temporal de la qual no impedeix vendre (RTO d'hores a 07-03, es reconstrueix des del llac), no compensa; la decisió de 07-03 continua sent vàlida.

(c) Base de nodes: 900 € sota demanda; amb reserva d'1 any al 40 %: 540 €; amb reserva de 3 anys al 55 %: 405 €. Diferència a favor de 3 anys: 135 €/mes. Però la reserva de 3 anys cobreix 6 nodes i d'aquí a un any només se'n faran servir 4: es pagarien 2 nodes reservats sense usar durant 2 anys (≈ 2 × 67 € × 24 mesos ≈ 3 200 €), davant d'un estalvi de 135 × 12 = 1 620 € el primer any. No compensa: reserva d'1 any, renegociable quan el dimensionament canviï. Les reserves es compren per a la base estable, i "estable" inclou el futur previsible.

Exercici 3.

• PostgreSQL → RDS (gestionat). Benefici alt (Multi-AZ, PITR, pedaços substitueixen el clúster de Patroni complet) i lock-in baix: és PostgreSQL estàndard, un pg_dump el mou a qualsevol lloc.
• Kafka → MSK (gestionat). Benefici alt (el rolling de brokers de 07-05 i la gestió de discos desapareixen) i lock-in baix: protocol Kafka estàndard, MirrorMaker el replica a qualsevol Kafka. A GCP, Confluent abans que Pub/Sub per la mateixa raó.
• Cassandra → a EKS (o EC2), no Keyspaces. Keyspaces canvia la semàntica (transaccions lleugeres, alguns tipus, model de cost per petició) i el repositori de 04-04 necessitaria revisió: lock-in alt per a un benefici mitjà. Es manté autogestionat amb l'operador de 07-05, i es revisa si l'equip de plataforma no dona l'abast.
• Keycloak → a EKS, no Cognito. Cognito és més limitat en fluxos i personalització, i migrar usuaris i clients d'un proveïdor d'identitat és dolorós: lock-in alt. Keycloak en dues rèpliques amb RDS al darrere és fàcil d'operar.
• Vault → Secrets Manager (gestionat), amb matís. Per als secrets estàtics i la seva rotació, Secrets Manager amb IRSA és més simple i s'integra amb IAM. Les credencials dinàmiques de base de dades i la PKI per a mTLS que Vault donava a 06-04 no tenen equivalent directe: si el mesh assumeix el mTLS (08-01), Vault es pot retirar; si no, es manté Vault a EKS només per a això.
• Prometheus/Grafana → a EKS. La instrumentació de serveis/comu/ és estàndard (OpenTelemetry, exposició Prometheus) i els dashboards i alertes de 07-01 ja existeixen; CloudWatch costaria més i canviaria el llenguatge de consulta (PromQL). Lock-in evitable a cost baix. Els serveis gestionats de Prometheus/Grafana del proveïdor són un punt mitjà acceptable si l'emmagatzematge de mètriques creix.

El núvol converteix la infraestructura en una API, i amb això canvia tres coses en el disseny de Quilòmetre Zero. La primera és la responsabilitat: IaaS, PaaS, SaaS i FaaS mouen la línia entre el que fa el proveïdor i el que fa el client, però les dades i les identitats queden sempre en aquest costat. La segona és la geografia: regions i zones de disponibilitat són dominis de fallada amb nom, les AZ absorbeixen les fallades quotidianes amb Multi-AZ en tot el que toca una comanda, i la regió secundària del pilot light de 07-03 passa a ser codi de Terraform que no costa res mentre no s'executa. La tercera és la substitució: RDS per Patroni, MSK pels brokers d'Ansible, S3 per MinIO, EKS pel clúster propi, amb una taula que diu què es guanya i què es perd a cada fila, i un criteri de lock-in selectiu (gestionat on el benefici és alt i l'API estàndard, propi on la dependència costaria més que l'operació). Terraform descriu la VPC de tres capes per AZ, EKS amb nodes base i spot, RDS Multi-AZ amb la seva rèplica en una altra regió, MSK, ElastiCache, S3 amb versionat i replicació, i IRSA perquè cada Pod tingui només els permisos que necessita; els manifestos de 07-05 es despleguen gairebé sense canvis, i el pla de Terraform es revisa a la pull request com qualsevol codi. Els pilars de l'arquitectura ben dissenyada resumeixen el curs com a llista de comprovació, i FinOps hi afegeix el cost com a mètrica: etiquetes, reserves per a la base, spot per a Spark i els pics, pressupostos amb alerta, i una taula que mostra que el còmput és dos terços de la factura, que dos serveis gestionats costen més que els seus equivalents al clúster, i que l'egress és la partida que el disseny més pot reduir.

Precisament aquesta partida, i dues preguntes més, obren la lliçó següent. Cal un servei a Kubernetes, amb les seves rèpliques, les seves sondes i la seva guàrdia, per generar una miniatura cada vegada que la Formatgeria Montblanc puja una foto, o per produir un PDF quan arriba un pagament.confirmat? I per què les fotos de formatge-curat han de viatjar des d'Irlanda fins al mòbil de l'Anna a València a cada visita, quan podrien ser a vint quilòmetres d'ella? Funcions que existeixen només mentre hi ha un esdeveniment per processar, i còmput i memòria cau a la vora de la xarxa: Arquitectures Serverless i Edge Computing.