Fins ara, la migració d'AlpinaShop ha seguit el camí més conservador: moure el que hi havia a màquines virtuals. Funciona, però la Marta continua mantenint sistemes operatius, escrivint startup scripts, versionant plantilles d'instància i vigilant pedaços de seguretat. És feina que no distingeix AlpinaShop de cap altra botiga: ningú no compra més motxilles perquè el seu servidor estigui ben apedaçat.

App Engine va ser el primer servei de Google Cloud, llançat el 2008, i continua sent una de les maneres més ràpides de posar una aplicació web en producció: puges el codi, Google s'encarrega de tota la resta —servidors, escalat, balanceig, certificats TLS, desplegaments— i pagues per l'ús. En aquesta lliçó desplegaràs el catàleg Flask d'AlpinaShop a App Engine, aprendràs a controlar-ne l'escalat i el cost, dividiràs trànsit entre versions per fer un desplegament canary, connectaràs amb Cloud SQL i Cloud Storage, i acabaràs amb una valoració honesta de per què avui molts equips trien Cloud Run en el seu lloc.

1. Què és un PaaS i què desapareix de la teva feina
2. Entorn estàndard i entorn flexible
3. Anatomia d'app.yaml
4. Desplegar el catàleg d'AlpinaShop
5. Versions, divisió de trànsit i desplegament canary
6. Tipus d'escalat i el seu efecte en el cost
7. Serveis i encaminament amb dispatch.yaml
8. Accés a Cloud SQL i Cloud Storage des d'App Engine
9. Variables d'entorn i configuració
10. Registres i errors
11. Tasques en segon pla: Cloud Tasks i cron.yaml
12. Limitacions reals i per què avui molts equips trien Cloud Run

Plataforma com a servei significa que el proveïdor gestiona tot el que hi ha per sota del teu codi. Comparat amb el que vam fer a 02-01:

Tota la lliçó 02-01 —plantilles, grups gestionats, health checks, escalat automàtic, actualitzacions progressives— es redueix a App Engine a un fitxer de configuració i gcloud app deploy. I surt de franc HTTPS amb domini propi, cosa que a Compute Engine exigirà un balancejador de càrrega i un certificat gestionat (03-02 i 03-07).

El que pagues per això: menys control i més acoblament. No tries el sistema operatiu, no instal·les paquets arbitraris a l'estàndard, i l'app.yaml és un format propi de Google que no funciona enlloc més.

Un detall organitzatiu que sorprèn: una aplicació d'App Engine per projecte, i la seva regió es tria en crear l'aplicació i no es pot canviar. Si t'equivoques, cal crear un projecte nou. Per a AlpinaShop, europe-west1, coherent amb tota la resta.

App Engine té dos entorns que es comporten de manera molt diferent sota el mateix nom:

Quan cadascun. L'estàndard és l'elecció natural per a aplicacions web en un llenguatge suportat: arrenca ràpid, escala a zero i és barat. El flexible té sentit si necessites una dependència del sistema que el sandbox no permet, un binari propi o un llenguatge no suportat.

I aquí la valoració honesta que anticipa l'apartat 12: si estàs pensant en App Engine flexible, gairebé sempre Cloud Run és millor opció avui —també executa el teu contenidor, però escala a zero, es factura per petició i no està lligat al format d'App Engine.

AlpinaShop utilitza l'entorn estàndard amb Python 3.12: el catàleg és Flask pur amb dependències que s'instal·len amb pip, sense res exòtic.

app.yaml és el fitxer que descriu l'aplicació sencera. Construirem el d'AlpinaShop comentant cada bloc.

Tres idees d'aquest fitxer que convé retenir:

• Els handlers de tipus estàtic són gratuïts en temps de CPU. Google serveix aquests fitxers des de la seva pròpia infraestructura, sense arrencar ni ocupar una instància. Servir CSS, JS i imatges per allà en lloc de fer-ho amb Flask redueix el cost i la latència de manera notable.
• secure: always hauria de ser a tots els handlers. Redirigeix HTTP a HTTPS automàticament.
• max_concurrent_requests és la palanca més important del cost. Si la teva aplicació passa la major part del temps esperant la base de dades, pot atendre moltes peticions simultànies per instància; pujar aquest valor redueix el nombre d'instàncies necessàries. Si l'aplicació consumeix CPU, pujar-lo empitjora la latència.

Al costat de l'app.yaml hi van els fitxers habituals d'un projecte Python:

El .gcloudignore no és un detall menor: sense ell, pujaries el directori .git i l'entorn virtual sencer, amb desplegaments lents i el risc real de publicar un fitxer .env amb credencials.

L'aplicació, amb les peces que ja coneixem de les lliçons anteriors:

Fixa't en pool_size=2. És un canvi deliberat respecte de la lliçó anterior: App Engine pot crear desenes d'instàncies en un pic, i cadascuna obriria el seu propi pool. Amb pool_size=5 i 20 instàncies serien 100 connexions només del catàleg. En entorns que escalen de manera agressiva, els pools han de ser petits.

Observa també GAE_VERSION: App Engine injecta variables d'entorn amb informació de l'entorn d'execució (GAE_SERVICE, GAE_VERSION, GAE_INSTANCE, GOOGLE_CLOUD_PROJECT). Mostrar la versió a la pàgina és un truc molt pràctic per verificar desplegaments i divisions de trànsit.

Desplegament:

En desplegar, App Engine construeix el paquet, instal·la les dependències de requirements.txt, crea una versió nova i —tret que diguis el contrari— li envia el 100 % del trànsit. La URL per defecte és https://<projectId>.<region>.r.appspot.com, amb certificat TLS vàlid des del primer segon i sense haver configurat res.

Utilitza sempre --version amb un nom significatiu. Sense ell, App Engine genera un identificador amb marca temporal, difícil de llegir a la llista de versions i a les comandes de repartiment de trànsit.

Cada desplegament crea una versió immutable que continua disponible. Això habilita una cosa molt potent: repartir el trànsit entre versions.

La URL amb el prefix <versio>-dot-<servei>-dot-<projecte> és un detall molt útil: qualsevol versió desplegada és accessible directament, cosa que permet validar a l'entorn real abans de dirigir-hi usuaris.

Sobre el criteri de repartiment, hi ha dos modes i la diferència importa:

Per a un canary d'una interfície d'usuari, cookie és gairebé sempre el correcte: amb random, un client podria veure una pàgina a la versió antiga i la següent a la nova, amb resultats desconcertants.

I un advertiment de cost: les versions antigues amb instàncies mínimes configurades continuen facturant encara que no rebin trànsit. Neteja periòdicament:

App Engine estàndard ofereix tres modes d'escalat, i triar malament és la principal font de factures inesperades.

El problema de l'arrencada en fred. Amb min_instances: 0 no pagues res quan no hi ha trànsit, però la primera petició després d'un període d'inactivitat ha d'esperar que arrenqui una instància: carregar l'intèrpret, importar les dependències, obrir el pool de connexions. En Python amb Flask solen ser 1–3 segons; si el codi importa biblioteques pesades, més.

La solució és reservar instàncies calentes:

I aquí hi ha el compromís, amb números orientatius:

Xifres orientatives per raonar sobre l'ordre de magnitud. Consulta la calculadora oficial de Google Cloud.

Decisió d'AlpinaShop, coherent amb la seva realitat: a alpinashop-dev, min_instances: 0 —al Dani no li importa esperar dos segons i l'entorn passa la nit sense trànsit. En producció, min_instances: 1 i max_instances: 10, perquè un client que veu la botiga trigar tres segons a carregar és un client que se'n va. Durant la campanya de tardor es puja el mínim a 3 i el màxim a 20.

Consells addicionals per reduir arrencades en fred: importa les biblioteques pesades de manera mandrosa, no executis feina costosa a l'arrencada del mòdul, i mantén requirements.txt sense dependències que no facis servir.

Una aplicació d'App Engine pot tenir diversos serveis (abans anomenats mòduls), cadascun amb el seu propi app.yaml, el seu escalat i les seves versions. És la manera de separar components amb perfils diferents.

Per a AlpinaShop:

Cada servei té la seva URL pròpia (https://api-dot-alpinashop-prod.ew.r.appspot.com). Per servir-los tots sota un mateix domini amb rutes diferents, s'utilitza dispatch.yaml:

Avantatges de separar serveis: cadascun escala segons la seva pròpia càrrega (el tauler d'administració no necessita 10 instàncies perquè hi hagi un pic a la botiga), es despleguen de manera independent, i una fallada al tauler no tomba el catàleg. És una separació de dominis de fallada, la mateixa idea que vam aplicar a 01-05 a les zones.

Tingues en compte que les regles de dispatch.yaml s'avaluen en ordre i només se n'admeten un nombre limitat; per a encaminament complex s'utilitza un balancejador de càrrega (03-02).

Aquí es veu el valor d'haver utilitzat biblioteques client a les lliçons anteriors: el codi no canvia.

Cada aplicació d'App Engine té un compte de servei per defecte, <projectId>@appspot.gserviceaccount.com. N'hi ha prou de donar-li els permisos adequats:

Amb això, el mateix storage.Client() i el mateix connector de Cloud SQL de les lliçons 02-02 i 02-03 funcionen sense tocar ni una línia, perquè les Application Default Credentials resolen ara al compte de servei d'App Engine.

Una particularitat de l'entorn estàndard: el sistema de fitxers és de només lectura tret de /tmp, que a més viu en memòria i compta contra la memòria de la instància. No hi desis mai res que hagi de persistir ni fitxers grans. Les imatges que pugen els usuaris van directes a Cloud Storage, exactament com vam programar a 02-02 amb upload_from_file sobre el flux.

Les variables no sensibles van a app.yaml, sota env_variables. Les sensibles, no: app.yaml acaba al repositori de Git i els seus valors són visibles per a qualsevol que pugui veure la configuració de la versió.

El patró correcte és llegir els secrets a l'arrencada des de Secret Manager:

Per distingir entorns, l'habitual és tenir un app.yaml per entorn (app-dev.yaml, app-prod.yaml) i desplegar el que toqui:

El detall complet de Secret Manager, la rotació de secrets i el xifratge amb Cloud KMS és a la lliçó 03-06.

App Engine envia automàticament a Cloud Logging les peticions i tot el que l'aplicació escrigui a la sortida estàndard. No cal configurar res.

Perquè els registres siguin realment útils, escriu-los estructurats en JSON: Cloud Logging els indexa per camps i podràs filtrar per sku o per severitat en lloc de buscar cadenes.

Els errors no capturats arriben automàticament a Error Reporting, que els agrupa per traça de pila, compta ocurrències i pot avisar quan apareix un error nou. És de les coses més rendibles que ofereix la plataforma sense configuració.

El tractament en profunditat de Cloud Logging, les mètriques i les traces és a 06-06 i 06-04.

Una petició HTTP no ha de fer feina llarga: l'usuari espera, i en escalat automàtic hi ha un límit de 10 minuts. Quan AlpinaShop confirma una comanda, cal enviar un correu, actualitzar l'estoc i avisar el magatzem; res d'això no ha de bloquejar la resposta al client.

Cloud Tasks és una cua gestionada: encues una tasca, que consisteix en una petició HTTP diferida a la teva pròpia aplicació, i el servei la lliura amb reintents i control de ritme.

Dos punts crítics aquí: la comprovació de la capçalera X-AppEngine-TaskName com a control d'accés, i la idempotència. Cloud Tasks garanteix lliurament almenys una vegada, no exactament una vegada: si el teu manejador triga i hi ha un reintent, podries enviar dos correus o descomptar l'estoc dues vegades. Registra quines comandes ja has processat i comprova-ho abans d'actuar.

Cron. Per a tasques programades, cron.yaml invoca una URL de la teva aplicació segons un horari:

Els endpoints invocats per cron reben la capçalera X-Appengine-Cron: true, que es comprova igual que la de Tasks. Protegeix aquestes rutes també amb un handler login: admin a app.yaml.

El servei equivalent fora d'App Engine és Cloud Scheduler, que pot invocar HTTP, Pub/Sub o Cloud Functions i funciona amb qualsevol servei de còmput. És l'opció a utilitzar si la teva aplicació no viu a App Engine.

App Engine continua sent un bon producte i hi ha aplicacions que fa més d'una dècada que hi funcionen sense sobresalts. Però convé ser sincer sobre els seus límits el 2026:

• Acoblament al format de Google. app.yaml, dispatch.yaml i cron.yaml no existeixen fora d'App Engine. Migrar a un altre proveïdor —o fins i tot a un altre servei de Google— implica refer la configuració.
• Runtimes limitats i amb calendari propi. Només els llenguatges i versions que Google suporta; quan una versió de Python queda obsoleta, cal migrar en el termini que marqui Google.
• Sandbox restrictiu a l'entorn estàndard. Res de binaris propis, dependències del sistema o escriptura al disc.
• L'entorn flexible ha quedat desplaçat. Arrenca en minuts, no escala a zero i costa més que les alternatives basades en contenidors.
• Regió immutable i una aplicació per projecte. Rígid per a arquitectures que evolucionen.
• La inversió no s'acumula. El temps dedicat a dominar app.yaml no serveix en cap altre lloc; el temps dedicat a dominar contenidors serveix a tot arreu.

Cloud Run (lliçó 07-02) ocupa avui aquest espai: executa el teu contenidor, escala a zero, es factura per ús, ofereix divisió de trànsit entre revisions igual que App Engine, HTTPS automàtic, i el que desplegues és una imatge de contenidor estàndard que també funcionaria a GKE, al teu portàtil o en un altre núvol.

Quan continua tenint sentit App Engine: ja el fas servir i funciona; vols el camí més curt des de codi Python a una URL amb HTTPS; no tens contenidors ni ganes d'aprendre'ls ara mateix; o necessites específicament dispatch.yaml i el cron integrat.

Quan triar Cloud Run: projecte nou, ja treballes amb contenidors, vols portabilitat, o necessites control sobre l'entorn d'execució.

Per a AlpinaShop, la decisió que documentarem a 02-07 és començar per Compute Engine (lift-and-shift, ja fet) i evolucionar cap a contenidors. App Engine es queda com una opció coneguda i descartada de manera raonada, que és la millor manera de descartar alguna cosa.

• Crear l'aplicació a la regió equivocada. És irreversible: exigeix projecte nou. Verifica-ho abans de gcloud app create.
• Desplegar sense .gcloudignore. Desplegaments lents i risc de pujar .env o .git.
• Oblidar --no-promote en provar. Enviaràs el 100 % del trànsit a una versió sense validar.
• Utilitzar --split-by=random per a un canary d'interfície. L'usuari veu versions diferents en peticions consecutives.
• Deixar versions antigues amb min_instances > 0. Facturen sense rebre trànsit.
• Posar min_instances: 0 en producció sense mesurar. L'arrencada en fred se't menja la conversió.
• Pools de connexions grans. Multiplicats per moltes instàncies, esgoten max_connections de Cloud SQL.
• Desar fitxers al sistema local. Només /tmp, en memòria i efímer.
• Secrets a env_variables d'app.yaml. Acaben a Git. Utilitza Secret Manager.
• Manejadors de Cloud Tasks no idempotents. El lliurament és almenys una vegada.
• Servir estàtics des de Flask. Utilitza handlers static_dir: són més ràpids i no consumeixen instàncies.
• Consell: posa secure: always a tots els handlers.
• Consell: utilitza --version amb noms llegibles.
• Consell: mostra GAE_VERSION a l'aplicació per verificar d'un cop d'ull quina versió serveix cada petició.
• Consell: defineix max_instances sempre. És el teu fre d'emergència davant d'un pic anòmal o un atac.

1. Crea l'aplicació d'App Engine a europe-west1 sobre alpinashop-dev.
2. Escriu una aplicació Flask mínima que mostri "AlpinaShop" i la versió (GAE_VERSION), amb una ruta /salud.
3. Escriu un app.yaml amb runtime python312, classe F1, escalat automàtic de 0 a 4 instàncies i un handler estàtic per a /estatico.
4. Desplega com a versió v1 i comprova la URL.
5. Explica què canviaries a app.yaml per a producció i justifica el cost associat.

1. Modifica l'aplicació per mostrar els preus amb IVA i desplega-la com a v2 sense enviar-li trànsit.
2. Comprova v2 a la seva URL específica.
3. Envia el 20 % del trànsit a v2 amb repartiment per cookie.
4. Comprova el repartiment fent diverses peticions i observant la versió mostrada.
5. Simula una fallada i executa un rollback complet a v1. Després neteja les versions sense trànsit.

1. Crea un segon servei api amb el seu propi app.yaml i escalat propi, que exposi /api/pedidos.
2. Escriu un dispatch.yaml que enviï /api/* al servei api i la resta al default.
3. Afegeix un cron.yaml amb una tasca diària a les 3:00 (hora de Madrid) que cridi /tareas/exportar-pedidos al servei api.
4. Protegeix l'endpoint de cron comprovant la capçalera corresponent.
5. Explica per què el manejador d'una tasca ha de ser idempotent i com ho garantiries per a l'enviament del correu de confirmació d'una comanda.

Solució 1

Per a producció canviaria instance_class: F2 (més memòria per al pool de connexions i les biblioteques client), min_instances: 1 per eliminar l'arrencada en fred del primer client, i max_instances: 10 per absorbir els pics de tardor. El cost afegit és el de mantenir una instància F2 encesa les 24 hores, de l'ordre de 30–40 € al mes: una xifra petita davant del valor que la portada de la botiga carregui sempre en menys d'un segon. Convé verificar l'import a la calculadora oficial abans de comprometre's.

Solució 2

Amb --split-by=cookie, si mantens la cookie entre peticions veuràs sempre la mateixa versió: és el comportament desitjat per no desconcertar l'usuari. Sense cookie —com al bucle de curl anterior, on cada crida és una sessió nova— el repartiment es comporta com a aleatori, i al voltant de 2 de cada 10 respostes mostraran v2.

Solució 3

5. El manejador ha de ser idempotent perquè Cloud Tasks garanteix lliurament almenys una vegada: si el manejador triga més del previst, si retorna un error transitori o si la instància es recicla a mitges, la tasca es reintenta i la mateixa comanda arriba dues vegades. Sense protecció, el client rebria dos correus de confirmació i l'estoc es descomptaria dues vegades.

La manera de garantir-ho per al correu de confirmació és registrar el fet de manera transaccional a la base de dades:

La clau és a ON CONFLICT DO NOTHING sobre una clau primària: la base de dades garanteix que només una execució aconsegueix inserir la fila, i les altres surten sense enviar res. Retornar 204 al segon intent evita a més reintents infinits.

Has vist què significa realment pujar un nivell d'abstracció. A App Engine desapareixen el sistema operatiu, els pedaços, el servidor web, el balanceig, els certificats TLS, els health checks i les plantilles d'instància: tot el que va ocupar la lliçó 02-01 es redueix a un app.yaml i un gcloud app deploy. Coneixes la diferència decisiva entre l'entorn estàndard —sandbox, arrencada en segons, escalat a zero, barat— i el flexible —contenidors, arrencada en minuts, sense escalat a zero—, i saps que avui el flexible ha quedat desplaçat per Cloud Run.

Has dissecat app.yaml línia a línia: runtime, entrypoint, classe d'instància, política d'escalat, variables d'entorn i handlers, inclosa la idea de servir els estàtics des de la infraestructura de Google per no gastar instàncies. Has desplegat el catàleg Flask d'AlpinaShop i has obtingut una URL amb HTTPS sense configurar res. Has après a desplegar amb --no-promote, validar a la URL de la versió, repartir trànsit amb afinitat per cookie per a un canary i fer rollback amb una sola comanda: pràctiques de desplegament que a Compute Engine exigien plantilles versionades i actualitzacions progressives. Has entès els tres modes d'escalat i el compromís central entre min_instances: 0 i l'arrencada en fred, amb la decisió raonada d'AlpinaShop: zero en desenvolupament, un en producció, tres en campanya. Has separat serveis amb dispatch.yaml perquè el tauler d'administració i el catàleg escalin per separat, has connectat Cloud SQL i Cloud Storage sense canviar ni una línia de codi gràcies a les credencials per defecte, has llegit secrets de Secret Manager a l'arrencada, has vist els registres estructurats i Error Reporting, i has mogut la feina pesada fora de la petició amb Cloud Tasks i cron.yaml, aprenent pel camí què significa que un lliurament sigui almenys una vegada i com escriure un manejador idempotent.

I has acabat amb una valoració honesta: App Engine és còmode però acoblat al format de Google, i la inversió que hi fas no s'acumula fora d'ell. L'alternativa que sí que s'acumula són els contenidors. A 02-05, Google Kubernetes Engine, farem aquest pas: repassarem Kubernetes des de zero —contenidor, pod, Deployment, Service, node i pla de control—, compararem els modes Autopilot i Standard, crearem el clúster alpinashop-cluster, construirem i publicarem la imatge del catàleg a Artifact Registry, escriurem els manifestos de Deployment i Service, escalarem amb HorizontalPodAutoscaler i farem actualitzacions sense tall amb el seu rollback. És el nivell d'abstracció amb més poder i també amb més responsabilitat de tot el mòdul.