De tot el que AlpinaShop té al seu servidor físic, la base de dades tienda és el més valuós i el més fràgil. Conté les comandes, els clients, l'estoc i els preus. Corre sobre un únic PostgreSQL que la Marta va instal·lar fa anys, sense rèplica, sense failover, amb un pg_dump nocturn que ningú no ha provat mai de restaurar i amb l'actualització de versió major pendent des de fa dos cicles perquè "no és bon moment". Si aquell disc falla un dissabte d'octubre, AlpinaShop no ven.

Cloud SQL és el servei de bases de dades relacionals gestionades de Google Cloud: PostgreSQL, MySQL i SQL Server amb còpies automàtiques, alta disponibilitat regional, rèpliques de lectura, pedaços gestionats i recuperació a un punt en el temps. En aquesta lliçó migrarem la base de dades tienda a la instància alpinashop-pedidos, connectarem l'aplicació Flask de manera segura i deixarem a la Lucía una rèplica on llançar els seus informes sense castigar la botiga.

1. Què deixa de fer la Marta: base de dades gestionada davant d'autogestionada
2. Motors, edicions i dimensionament
3. Crear la instància alpinashop-pedidos
4. Bases de dades, usuaris i contrasenyes
5. Alta disponibilitat regional i failover
6. Rèpliques de lectura per als informes de la Lucía
7. Còpies de seguretat, retenció i recuperació a un punt en el temps
8. Connectivitat: IP pública, IP privada i l'Auth Proxy
9. Connectar l'aplicació Flask
10. Migrar les dades actuals
11. Manteniment programat i finestres
12. Escalat vertical i límits
13. Quan Cloud SQL es queda curt: AlloyDB i Spanner

La manera més honesta d'explicar el valor de Cloud SQL és enumerar tasques i veure qui les fa.

Les dues últimes files són el preu a pagar: perds accés de superusuari i control total del motor. A Cloud SQL no hi ha SSH a la màquina, no pots instal·lar qualsevol extensió ni tocar tots els paràmetres. Per a la immensa majoria d'aplicacions —inclosa AlpinaShop— és un intercanvi excel·lent. Si el teu producte depèn d'una extensió exòtica o d'un pg_hba.conf recargolat, hauràs de comprovar la compatibilitat abans o quedar-te a Compute Engine.

Hi ha també un canvi de cost que convé dir sense adorns: una VM amb PostgreSQL instal·lat és més barata que una instància Cloud SQL equivalent. El que compres amb aquesta diferència és el temps de la Marta i l'eliminació d'un risc que avui no està cobert. Si poses preu a una tarda d'indisponibilitat en plena campanya, el compte surt sol.

Motors disponibles:

AlpinaShop ja utilitza PostgreSQL, així que l'elecció és evident: PostgreSQL 16, mateixa família que la seva instal·lació actual, sense canvis a l'aplicació.

Edicions. Cloud SQL s'ofereix en dues edicions que convé distingir:

Per a l'arrencada d'AlpinaShop, Enterprise és suficient. Si en el futur la botiga no tolera ni un minut de tall, Enterprise Plus és la via d'escapament sense canviar de servei.

Dimensionament. Es tria un tipus de màquina igual que a Compute Engine. Criteris pràctics per a una base de dades:

• La memòria és el primer. L'objectiu és que el conjunt de dades "calent" (índexs i taules consultades amb freqüència) càpiga a la RAM. Una base de dades que fa lectures de disc constantment va lenta per molta CPU que tingui.
• El disc determina les IOPS. Com vam veure a 02-01, en discos persistents el rendiment creix amb la mida. Un disc de 10 GB té molt poques IOPS encara que les teves dades ocupin 8 GB.
• Activa el creixement automàtic d'emmagatzematge. Que la base de dades s'aturi per disc ple és un incident evitable.
• Comença modest i escala. Canviar el tipus de màquina és una operació de minuts amb reinici.

La base de dades tienda d'AlpinaShop ocupa uns 12 GB. Triem db-custom-2-7680 (2 vCPU, 7,5 GB de RAM) amb 50 GB de disc SSD i creixement automàtic: espai de sobres perquè el disc no limiti les IOPS i RAM suficient per cachejar el conjunt actiu.

Aquesta comanda concentra gairebé totes les decisions de la lliçó, així que la desglossem:

• --region=europe-west1 (no zona): Cloud SQL és un servei regional. La instància principal viu en una zona, però l'elecció s'expressa a escala de regió.
• --availability-type=REGIONAL activa l'alta disponibilitat: una instància en espera en una altra zona amb replicació síncrona. És el flag que converteix un punt únic de fallada en una arquitectura tolerant.
• --storage-auto-increase: el disc creix sol quan s'omple. Mai no decreix, així que continua vigilant-ne el creixement.
• --backup-start-time=03:00 (hora UTC): còpia diària en horari de baix trànsit.
• --enable-point-in-time-recovery + --retained-transaction-log-days=7: desa els WAL per poder restaurar a qualsevol instant dels últims 7 dies.
• --maintenance-window-*: Google aplicarà les actualitzacions els diumenges a les 4:00 UTC, no un dimarts a les 11:00.
• --maintenance-release-channel=production: rep les versions ja madures, no les més recents.
• --database-flags: els paràmetres del motor s'ajusten aquí. log_min_duration_statement=1000 registra tota consulta que trigui més d'un segon, que és la millor eina de diagnòstic de rendiment que existeix i costa zero configurar-la.

La creació triga uns minuts. En acabar:

Una instància és el servidor; a dins hi viuen les bases de dades i els usuaris.

Utilitza sempre --prompt-for-password: escriure la contrasenya a la línia de comandes la deixa a l'historial de bash i als registres d'auditoria.

Crear l'usuari no li dóna permisos dins de la base: això es fa amb SQL. Connecta't (apartat 8) i executa:

La clàusula ALTER DEFAULT PRIVILEGES és la que sol faltar: sense ella, els permisos s'apliquen només a les taules que existien en aquell moment, i qualsevol taula creada després queda inaccessible per a l'aplicació. És una font clàssica d'errors després d'un desplegament.

Cloud SQL també admet autenticació IAM: en lloc de contrasenyes, els usuaris i els comptes de servei s'autentiquen amb la seva identitat de Google Cloud i un token de vida curta. És l'opció recomanada perquè elimina les contrasenyes del sistema. Ho deixem apuntat aquí i es desenvolupa a 03-04.

Amb --availability-type=REGIONAL, Cloud SQL manté una instància en espera en una altra zona d'europe-west1, amb replicació síncrona del disc: cada escriptura es confirma a totes dues zones abans de donar el commit per bo.

Què significa a la pràctica:

• La instància en espera no serveix trànsit. No és una rèplica de lectura: existeix només per prendre el relleu. Pagues per ella i no la utilitzes, i aquesta és precisament l'assegurança que compres.
• El failover és automàtic i conserva l'adreça de connexió. L'aplicació no canvia la seva configuració; només veu un tall de connexions d'aproximadament un minut (menys a Enterprise Plus).
• L'aplicació ha de saber reconnectar. Aquest és el punt que s'oblida: si el teu pool de connexions no reintenta, el failover es converteix en un error visible per al client. Configura reintents al pool (ho veurem a l'apartat 9).
• Duplica aproximadament el cost de la instància. És la decisió econòmica més clara d'aquesta lliçó: per a alpinashop-prod sí; per a alpinashop-dev, no.

Es pot provar de debò, i cal provar-ho:

Executa aquesta comanda en un entorn de proves mentre l'aplicació està funcionant i observa quant triga a recuperar-se. Un pla d'alta disponibilitat que mai no s'ha exercitat és una hipòtesi, no un pla.

La Lucía llança consultes d'agregació sobre les comandes: vendes per categoria, evolució mensual, productes sense rotació. Executades contra la base principal, competeixen per CPU i memòria amb la botiga, i un informe pesat un dissabte de campanya pot alentir el checkout.

La solució immediata és una rèplica de lectura: una còpia asíncrona que accepta consultes SELECT.

Característiques que cal tenir clares:

• La replicació és asíncrona: la rèplica va lleugerament endarrerida (normalment mil·lisegons o pocs segons). Per a informes és irrellevant; per llegir una comanda just després de crear-la, no serveix.
• És de només lectura. Qualsevol escriptura falla.
• Pot tenir un tipus de màquina diferent del principal: si els informes de la Lucía necessiten més memòria, els la pots donar sense tocar producció.
• Pot estar en una altra regió, cosa que serveix a més com a pla de recuperació davant de desastre geogràfic.
• Es pot promoure a instància independent amb gcloud sql instances promote-replica. És una operació irreversible que trenca la replicació, útil en una recuperació real o per crear un entorn de proves amb dades actuals.

Vigila el retard de replicació:

A Cloud Monitoring, la mètrica rellevant és database/replication/replica_lag (06-04). Una alerta quan superi uns minuts evita informes que semblen correctes però estan desactualitzats.

On és el límit. Una rèplica de lectura resol el problema d'avui, però les consultes analítiques sobre una base transaccional sempre seran ineficients: PostgreSQL desa per files, i un informe que agrega una columna sobre milions de comandes llegeix files senceres. La solució definitiva per a la Lucía és exportar les dades a BigQuery, amb emmagatzematge columnar i motor pensat per agregar. Això és el mòdul 4. De moment, la rèplica és la resposta correcta i barata.

Ja vam configurar còpies diàries amb 14 dies de retenció i PITR de 7 dies en crear la instància. Vegem què implica cada mecanisme.

Còpies automàtiques. Diàries, incrementals, emmagatzemades fora de la instància i sense cost de rendiment apreciable. No són pg_dump: són còpies de l'emmagatzematge.

Aquesta última comanda és un hàbit que val el seu pes en or: abans de qualsevol migració d'esquema, una còpia manual amb descripció explícita.

Restaurar. Hi ha dos escenaris molt diferents:

Gairebé sempre vols el segon. Restaurar sobre la instància original destrueix l'estat actual, incloses les dades posteriors a l'incident, que potser vols conservar. Clonar a una instància nova et deixa comparar, extreure només el necessari i decidir amb calma.

Recuperació a un punt en el temps (PITR). És la diferència entre "recupero la còpia d'anit" i "recupero l'estat exacte de les 09:14:59, un segon abans que el script esborrés la taula de preus". Funciona combinant l'última còpia amb els registres de transaccions (WAL). Requereix tenir PITR habilitat abans de l'incident; activar-lo després no permet viatjar al passat.

Un exemple realista d'ús: el Dani executa a les 09:15 un UPDATE sense WHERE sobre productos. A les 09:20 es detecta. La seqüència correcta és clonar a alpinashop-pedidos-restaurada amb --point-in-time a les 09:14:59, verificar-hi que els preus són correctes, exportar únicament la taula afectada i reimportar-la a producció. La botiga no s'atura i no es perd cap venda d'aquells cinc minuts.

Exportacions lògiques. A més de les còpies gestionades, convé exportar periòdicament a Cloud Storage en format SQL: serveix per migrar, per endur-se les dades fora de Google Cloud i com a còpia independent del servei.

Les còpies gestionades van lligades a la instància: si algú esborra la instància, s'esborren amb ella (excepte còpies finals). Una exportació en un bucket amb versionatge i retenció és una capa de protecció diferent. Aquesta és la raó, per cert, per la qual vam dedicar la lliçó anterior a Cloud Storage abans que aquesta.

Connectar-se a Cloud SQL és on més gent s'encalla, així que anem per parts.

Xarxes autoritzades (IP pública). Només per a accés administratiu, i mai 0.0.0.0/0:

Cloud SQL Auth Proxy. És la peça clau. Un binari que s'executa al costat de la teva aplicació, escolta a localhost i reenvia les connexions a Cloud SQL per un túnel TLS, autenticant-se amb les teves credencials de Google Cloud. Avantatges: la instància no necessita IP pública, no cal gestionar certificats ni llistes d'IP, i l'accés es controla amb el rol IAM roles/cloudsql.client.

Aquest identificador projecte:regio:instancia és el nom de connexió de la instància, i el necessitaràs constantment:

Amb el proxy en marxa, qualsevol client PostgreSQL apunta a localhost com si la base fos a la teva màquina:

I si ets a Cloud Shell, no cal ni descarregar-lo:

En producció no es llança un procés proxy a part: s'utilitza el connector de Python, que fa el mateix dins del procés de l'aplicació.

Aspectes del codi que cal entendre bé:

• pool_pre_ping=True és el flag que fa sobreviure al failover. Abans de lliurar una connexió del pool, comprova que continua viva; si el failover la va tancar, la descarta i n'obre una altra. Sense això, després d'un failover l'aplicació retorna errors fins que es reinicia.
• pool_recycle=1800 evita connexions caducades pels temps d'inactivitat dels intermediaris de xarxa.
• pool_size s'ha de multiplicar pel nombre de processos. Si gunicorn arrenca 4 workers amb pool_size=5, són 20 connexions per instància. Amb 10 instàncies del MIG en un pic de tardor, 200 connexions: exactament el max_connections que vam configurar. Aquest càlcul és la causa número u de caigudes per esgotament de connexions, i cal fer-lo abans, no després.
• Consultes parametritzades (:sku). No concatenis mai cadenes en SQL: és la porta de la injecció SQL.
• La contrasenya ve d'una variable d'entorn, i en producció aquesta variable s'omple des de Secret Manager (03-06), mai d'un fitxer al repositori.

Si el nombre de connexions es converteix en un problema, el patró habitual és posar PgBouncer al davant, o utilitzar Cloud SQL Enterprise Plus amb el seu gestor de connexions integrat.

Ha arribat el moment de moure la base tienda real. Per a 12 GB, el camí més simple i controlat és pg_dump més importació des de Cloud Storage.

Pas 1: bolcat al servidor d'origen.

--no-owner i --no-acl eviten que el bolcat intenti assignar propietaris i permisos a usuaris que no existeixen a Cloud SQL. És la causa més freqüent d'errors durant una importació.

Pas 2: pujar el bolcat al bucket.

Pas 3: autoritzar Cloud SQL a llegir el bucket. La instància té el seu propi compte de servei, i necessita permís explícit:

Aquest pas s'oblida sempre i produeix un error de permisos poc descriptiu. Recorda-ho: la instància de Cloud SQL és una identitat més, i sense permís no llegeix el teu bucket.

Pas 4: importar.

Pas 5: verificar. No donis mai per bona una migració sense contrastar:

Aquest ANALYZE final importa: després d'una importació massiva, les estadístiques del planificador estan buides i les consultes poden anar absurdament lentes fins que es recalculen.

El problema del tall. Aquest procediment implica aturar les escriptures mentre es bolca i s'importa: per a 12 GB, potser 30-40 minuts de botiga en mode lectura. És assumible si es fa de matinada.

Quan no és assumible, l'eina és Database Migration Service (DMS): crea una rèplica contínua des del teu PostgreSQL d'origen cap a Cloud SQL, manté la sincronització mentre la botiga continua funcionant i permet un tall final de segons. Requereix que l'origen tingui replicació lògica habilitada i connectivitat amb Google Cloud. Per a una migració de desenes o centenars de GB amb exigència de disponibilitat, és l'opció correcta; per als 12 GB d'AlpinaShop en una matinada de diumenge, pg_dump és més simple i suficient.

Google actualitza el motor i la infraestructura periòdicament. Aquestes actualitzacions impliquen un reinici breu, i vols decidir quan passa.

Els tres últims flags són especialment valuosos per a AlpinaShop: defineixen un període de denegació de manteniment que bloqueja les actualitzacions durant la campanya de tardor. Google les posposarà fins després del 15 de novembre.

Bona pràctica: mantén alpinashop-dev a preview amb la finestra un dia abans que producció. Així els canvis arriben primer a desenvolupament i tens marge de reacció.

Cloud SQL escala verticalment per a escriptures: no hi ha manera de repartir les escriptures entre diverses instàncies.

Límits i consideracions que cal conèixer:

• El disc creix però no es redueix. Si actives el creixement automàtic i una càrrega anòmala infla el disc a 2 TB, continuaràs pagant 2 TB. L'única sortida és exportar i recrear.
• Les connexions són un recurs escàs. max_connections depèn de la memòria de la instància; cada connexió de PostgreSQL és un procés amb la seva memòria.
• No hi ha superusuari. L'usuari postgres de Cloud SQL té privilegis amplis però no és SUPERUSER. Algunes extensions i operacions no estan disponibles.
• Extensions limitades a la llista suportada. Comprova la teva abans de migrar.
• Escalar té sostre. El tipus de màquina més gran disponible marca el límit físic de la teva base de dades. Si t'hi acostes, és senyal que necessites una altra arquitectura.

Tres senyals que Cloud SQL se t'ha quedat petit: les escriptures saturen la instància més gran disponible; necessites escriptura activa en diverses regions simultàniament; o les consultes analítiques sobre la mateixa base de dades són inevitables i molt pesades.

Per a AlpinaShop, Cloud SQL cobreix amb escreix l'horitzó previsible: una botiga espanyola amb pics estacionals és molt lluny d'aquests límits. La ruta de creixement natural seria, primer, descarregar l'analítica a BigQuery (mòdul 4); després, si el volum transaccional ho exigís, AlloyDB, que permet migrar amb canvis mínims per la seva compatibilitat amb PostgreSQL. Spanner s'estudia amb detall a la lliçó 02-06, dins del panorama de bases de dades no relacionals i distribuïdes.

• Crear la instància sense alta disponibilitat "i ja l'activarem". Canviar a REGIONAL després és possible, però implica reinici i se sol posposar indefinidament.
• Confiar en còpies que mai no s'han restaurat. Programa una restauració de prova trimestral a una instància clonada.
• Activar PITR després de l'incident. No serveix: cal tenir-lo abans.
• Restaurar sobre la instància original en un incident. Clona a una instància nova i decideix amb calma.
• Oblidar ALTER DEFAULT PRIVILEGES. Les taules creades després del GRANT queden inaccessibles.
• No donar permís de lectura del bucket al compte de servei de la instància abans d'importar.
• Importar sense --no-owner --no-acl. Falla per usuaris inexistents al destí.
• No fer ANALYZE després de la importació. Consultes absurdament lentes per estadístiques buides.
• Dimensionar el pool sense multiplicar per processos i instàncies. Esgotament de connexions en el pitjor moment possible.
• Ometre pool_pre_ping. L'aplicació no sobreviu a un failover.
• Exposar la IP pública amb xarxes autoritzades àmplies. Utilitza l'Auth Proxy o el connector.
• Consell: activa log_min_duration_statement des del primer dia. És diagnòstic gratuït.
• Consell: fes una còpia manual amb descripció abans de cada migració d'esquema.
• Consell: defineix un període de denegació de manteniment que cobreixi la campanya de tardor.
• Consell: exporta periòdicament a un bucket amb versionatge, com a còpia independent del cicle de vida de la instància.

1. Crea alpinashop-pedidos-dev amb PostgreSQL 16, db-g1-small o db-custom-1-3840, a europe-west1, amb disponibilitat zonal (no regional) i còpies diàries amb 7 dies de retenció. Justifica per què en desenvolupament no posem alta disponibilitat.
2. Crea la base de dades tienda i els usuaris app_catalogo i informes_lectura.
3. Connecta't amb gcloud sql connect i crea l'esquema tienda amb una taula productos (sku, nombre, precio, stock, activo).
4. Concedeix a app_catalogo permisos de lectura/escriptura i a informes_lectura només lectura, incloent-hi els privilegis per defecte.
5. Comprova des d'informes_lectura que un INSERT falla i un SELECT funciona.

1. Insereix tres productes i anota l'hora exacta.
2. Simula un accident: DELETE FROM tienda.productos; sense WHERE.
3. Clona la instància a un instant anterior a l'esborrat.
4. Verifica al clon que les dades hi són i explica com retornaries només aquella taula a la instància original.
5. Esborra el clon i calcula què t'hauria costat tenir-lo un mes encès.

1. Escriu una aplicació Flask mínima que es connecti amb el connector de Python i exposi /productos.
2. Configura el pool amb pool_pre_ping, pool_recycle i un pool_size justificat per a 4 workers de gunicorn i fins a 6 instàncies.
3. Calcula el nombre total de connexions en el pitjor cas i compara'l amb max_connections.
4. Explica què passaria durant un failover amb i sense pool_pre_ping.
5. Indica d'on hauria de venir la contrasenya en producció i per què no d'una variable al codi.

Solució 1

En desenvolupament no posem alta disponibilitat perquè duplica el cost per protegir-nos d'un risc que en desenvolupament no té conseqüències: si la instància cau unes hores, ningú no perd una venda. L'alta disponibilitat es paga on hi ha ingressos en joc. És la mateixa lògica de repartiment de recursos que vam aplicar amb els labels de centro-coste a 01-04.

Solució 2

Per retornar només aquella taula a la instància original, s'exporta del clon i s'importa a producció, sense tocar la resta:

Aquest és l'avantatge de clonar en lloc de restaurar a sobre: es recupera exactament la taula danyada i es conserven totes les dades correctes escrites després de l'incident.

Un clon és una instància completa i es factura com a tal des del moment en què existeix: una db-custom-1-3840 amb 20 GB d'SSD volta les desenes de dòlars al mes. Deixar clons de rescat oblidats encesos és una despesa silenciosa molt comuna; esborra'ls tan bon punt acabi la recuperació.

Solució 3

3. El càlcul en el pitjor cas:

Amb max_connections=200 hi ha marge, però és estret: queden 32 connexions per a les tasques de manteniment, els informes de la Lucía i les sessions administratives. Si el MIG pogués arribar a 10 instàncies, serien 280 connexions i la base de dades les rebutjaria. Les opcions són baixar pool_size a 3, augmentar la memòria de la instància per elevar max_connections, o introduir PgBouncer.

4. Durant un failover, les connexions obertes del pool queden trencades. Sense pool_pre_ping, SQLAlchemy lliura aquestes connexions mortes i cada petició falla amb un error de connexió fins que el pool es recicla o l'aplicació es reinicia: minuts d'errors 500 visibles per al client. Amb pool_pre_ping, cada connexió es verifica abans d'utilitzar-se; les trencades es descarten i se n'obren de noves de manera transparent, i l'usuari només percep una latència una mica més gran durant uns segons.

5. En producció la contrasenya ha de venir de Secret Manager (lliçó 03-06), injectada com a variable d'entorn o llegida a l'arrencada amb el compte de servei de l'aplicació. Mai al codi ni al repositori perquè quedaria a l'historial de Git per sempre, seria visible per a qualsevol amb accés al repositori i no podria rotar-se sense tornar a desplegar. L'opció òptima és directament l'autenticació IAM de Cloud SQL, que elimina la contrasenya.

La base de dades tienda ha deixat de ser el punt feble d'AlpinaShop. Has vist en una taula concreta quines tasques deixa de fer la Marta —pedaços, còpies, failover, rèpliques, xifratge— i què es perd a canvi: el superusuari i el control total del motor, un intercanvi que per a aquesta aplicació és clarament favorable. Has triat PostgreSQL 16, edició Enterprise i un dimensionament raonat en què la memòria i la mida del disc importen més que la CPU. Has creat alpinashop-pedidos a europe-west1 amb una sola comanda que concentra les decisions importants: alta disponibilitat regional, còpies diàries amb 14 dies de retenció, PITR de 7 dies, finestra de manteniment el diumenge de matinada i registre de consultes lentes des del primer minut.

Has creat la base tienda amb usuaris diferenciats i permisos mínims, sense oblidar ALTER DEFAULT PRIVILEGES. Has entès que la instància en espera de l'alta disponibilitat no serveix trànsit i que el seu valor és en el failover automàtic que conserva l'adreça de connexió, i que aquest failover només és transparent si l'aplicació reconnecta —d'aquí pool_pre_ping. Has creat una rèplica de lectura perquè els informes de la Lucía no competeixin amb la botiga, sabent que és una solució correcta però temporal, perquè l'analítica de debò viu a BigQuery. Has configurat còpies, has après a clonar a un punt en el temps en lloc de restaurar destructivament, i has vist per què una exportació a un bucket amb versionatge és una capa de protecció diferent de les còpies gestionades. Has comparat IP pública, IP privada, Auth Proxy i connector de Python, i has connectat el catàleg Flask amb un pool ben dimensionat i consultes parametritzades. I has fet la migració real amb pg_dump, importació des del bucket, verificació i ANALYZE, amb Database Migration Service anotat per quan el tall no sigui acceptable.

AlpinaShop ja té el seu còmput en màquines virtuals, les seves imatges en un bucket i les seves dades en una base gestionada. Però la Marta continua mantenint sistemes operatius, plantilles d'instància i startup scripts. A 02-04, App Engine, veurem què passa quan s'elimina també aquesta capa: què és un PaaS, en què es diferencien l'entorn estàndard i el flexible, com es descriu una aplicació sencera en un app.yaml de vint línies, com es despleguen versions i es divideix el trànsit per fer un canary, com es configura l'escalat —inclòs l'escalat a zero— i com la mateixa aplicació Flask accedeix a Cloud SQL i a Cloud Storage sense que ningú administri ni un sol servidor.