Abans de tocar cap consola o escriure cap comanda, convé entendre què compres exactament quan contractes el núvol, quina part de la feina deixa de ser teva i quina part continua sent-ho. Aquesta lliçó construeix aquest marc mental: què significa «computació al núvol», en què es diferencien IaaS, PaaS i SaaS, què és concretament Google Cloud Platform i sobre quina infraestructura es recolza, quines famílies de serveis ofereix i com es corresponen amb els mòduls d'aquest curs, com es compara amb AWS i Azure, i per què el model econòmic del núvol (pagar per ús en lloc de comprar ferro) canvia les decisions tècniques. Acabarem presentant AlpinaShop, la botiga en línia que migrarem pas a pas al llarg de tot el curs i que donarà context a cada exemple i cada exercici.

És la lliçó més conceptual del curs, i també la que dona més rendibilitat: gairebé tots els errors cars que es cometen al núvol no són errors de comanda, sinó errors de model mental.

1. Què és la computació al núvol
2. IaaS, PaaS i SaaS: qui gestiona què
3. Què és Google Cloud Platform i en què es recolza
4. Catàleg de famílies de serveis de GCP
5. Comparació honesta amb AWS i Azure
6. El model econòmic: CapEx davant d'OpEx
7. El cas AlpinaShop: d'on partim

La computació al núvol consisteix a consumir recursos informàtics —capacitat de càlcul, emmagatzematge, xarxa, bases de dades, models d'IA— com un servei sota demanda a través d'internet, en lloc de comprar-los, instal·lar-los i mantenir-los tu.

La definició clàssica (la del NIST, encara vigent com a referència) identifica cinc característiques essencials. Val la pena llegir-les a poc a poc, perquè cadascuna té conseqüències pràctiques:

• Autoservei sota demanda: pots crear una màquina o una base de dades sense trucar a ningú ni obrir un tiquet. Conseqüència pràctica: la velocitat d'aprovisionament passa de setmanes a segons, i per això la governança deixa de ser un tràmit i passa a ser crítica (qualsevol pot generar despesa).
• Accés ampli per xarxa: els recursos es consumeixen per xarxa amb protocols estàndard (HTTPS, API REST). Conseqüència: tot el que facis a la consola es pot fer també per API, i per tant automatitzar.
• Agrupació de recursos (pooling): el proveïdor comparteix una infraestructura enorme entre molts clients fent servir virtualització i aïllament. Conseqüència: economies d'escala, però també la necessitat d'entendre l'aïllament i la seguretat multiinquilí.
• Elasticitat ràpida: pots créixer i decréixer gairebé instantàniament. Conseqüència: dimensionar per al pic deixa de ser obligatori.
• Servei mesurat: tot es mesura i es factura per ús. Conseqüència: el cost es converteix en una mètrica d'enginyeria més, com la latència.

AlpinaShop farà una migració que comença com a híbrida (durant unes setmanes conviuen el servidor antic i GCP) i acaba sent núvol públic pur. La connectivitat híbrida i les estratègies multinúvol es tracten al mòdul 7 (Anthos i xarxes avançades).

La distinció entre models de servei és, en el fons, una línia que separa el que gestiona el proveïdor del que gestiones tu. Com més amunt puges, menys controles i menys mantens.

Traduït a serveis concrets de Google Cloud:

Un advertiment important: «menys gestió» no vol dir «menys responsabilitat». En tots els models continues sent responsable de les teves dades, de qui hi accedeix i de la configuració que apliques. Un bucket de Cloud Storage mal configurat exposa dades igual de bé sent serverless. Aquest repartiment es formalitza en el model de responsabilitat compartida, que estudiarem en detall a la lliçó 01-05.

Google Cloud Platform (GCP) és el conjunt de serveis d'infraestructura i plataforma que Google comercialitza sobre la mateixa infraestructura física que utilitza per als seus propis productes: Cerca, YouTube, Gmail o Maps. Aquesta frase, que sona a eslògan, té tres implicacions tècniques molt concretes:

• Xarxa troncal privada global. Google opera la seva pròpia xarxa de fibra entre centres de dades i més d'un centenar de punts de presència. Quan el trànsit entra en un PoP de Google (per exemple, a Madrid), viatja fins al teu servei per aquesta xarxa privada, no per internet públic. Això redueix latència i variabilitat, i és la base de serveis com el balancejador de càrrega global i Cloud CDN (mòdul 3).
• Centres de dades propis i disseny a mida. Google dissenya els seus servidors, els seus commutadors de xarxa i els seus xips (TPU per a IA, Titan per a seguretat d'arrencada). El xifratge de dades en repòs i en trànsit dins de la seva infraestructura està activat per defecte, sense que l'hagis de configurar.
• Tecnologies nascudes per a escala interna. Diversos serveis de GCP són la versió comercial de sistemes interns: BigQuery descendeix de Dremel, Cloud Bigtable de Bigtable, Pub/Sub del sistema de missatgeria intern, i Kubernetes és la reescriptura oberta de Borg. No són productes concebuts per al mercat i escalats després: van ser escalats primer.

Una precisió de nomenclatura útil des del principi: avui Google fa servir majoritàriament la marca «Google Cloud» per a tot (incloent-hi Workspace i les solucions sectorials), i «Google Cloud Platform» o GCP per a la part d'infraestructura i plataforma que ens ocupa. Veuràs tots dos termes a la documentació; en aquest curs els fem servir indistintament per referir-nos a la plataforma tècnica.

El catàleg de Google Cloud supera els dos-cents serveis, però s'agrupa en un grapat de famílies. No cal que els coneguis tots: cal que sàpigues quina família resol quin problema per poder buscar-hi dins.

Dues observacions sobre nomenclatura, perquè trobaràs documentació antiga que fa servir noms retirats:

• Cloud Monitoring, Cloud Logging i Cloud Trace són els noms actuals del que durant anys es va dir Stackdriver.
• Vertex AI va unificar el que abans eren AI Platform i AutoML per separat.
• Artifact Registry substitueix Container Registry (gcr.io), que està en desús.

Si un tutorial que trobes per internet menciona Stackdriver, AI Platform o gcr.io, és anterior al 2022 i probablement contingui més coses desactualitzades.

Els tres grans proveïdors cobreixen pràcticament les mateixes necessitats. Les diferències reals són en els detalls de cada servei, en el model de preus i en l'ecosistema de l'empresa, no en «quin pot fer X».

On acostuma a destacar cadascun, dit sense màrqueting:

• Google Cloud té avantatge reconegut en analítica de dades (BigQuery és serverless de debò: no gestiones clúster) i en Kubernetes, que és tecnologia d'origen Google. La seva xarxa global i el balancejador global amb una única IP anycast són tècnicament elegants. La seva quota de mercat és la tercera, cosa que a la pràctica significa menys oferta de professionals amb experiència i de vegades menys integracions de tercers.
• AWS té el catàleg més ampli, la comunitat més gran i la documentació de tercers més abundant. També la complexitat acumulada més gran i una consola menys coherent.
• Azure domina allà on ja hi ha una forta inversió en Microsoft (Active Directory, .NET, llicències de Windows Server), amb avantatges d'integració i llicenciament difícils d'igualar en aquest context.

Per a AlpinaShop, amb una aplicació Python sense dependències de Microsoft i amb ambició d'explotar les seves dades de vendes, Google Cloud és una elecció raonable. No és l'única possible, i això és una resposta perfectament professional.

Aquest és el canvi que més afecta les decisions tècniques, i el que pitjor s'entén al principi.

Els conceptes clau que has d'interioritzar:

• Pagament per ús: es factura per segons de CPU, gigabytes emmagatzemats per mes, gigabytes de trànsit de sortida, consultes executades. Un recurs apagat deixa de generar cost de còmput, però un disc persistent continua costant encara que la VM estigui aturada. És l'error de novell número u.
• Elasticitat: la capacitat s'ajusta a la demanda. Per a AlpinaShop, el trànsit de la qual es multiplica en les campanyes de tardor, això vol dir deixar de pagar tot l'any per la capacitat que només necessita sis setmanes.
• Descomptes per compromís i per ús sostingut: Google aplica automàticament descomptes per ús sostingut a les VMs que corren bona part del mes, i ofereix descomptes més grans si et compromets a 1 o 3 anys. També existeixen les VMs Spot, molt més barates a canvi de poder ser interrompudes.
• Cost de sortida (egress): moure dades cap a Google és gratis; treure-les cap a internet, no. En arquitectures amb molt trànsit de descàrrega (imatges de catàleg, per exemple) aquesta partida importa.

Advertiment sobre xifres. Els preus, les quotes i els detalls del nivell gratuït canvien sovint i varien per regió. En aquest curs fem servir xifres només com a ordre de magnitud; verifica sempre els imports vigents a la calculadora i a la documentació oficial de preus de Google Cloud abans de prendre una decisió. L'optimització sistemàtica de costos es tracta a la lliçó 07-05.

Un matís que convé dir aviat: el núvol no és automàticament més barat. Una càrrega estable, predictible i sempre encesa pot resultar més cara al núvol que en un servidor propi amortitzat. El que el núvol compra de debò és elasticitat, velocitat de canvi i serveis gestionats que substitueixen hores de personal. Si la teva càrrega no aprofita res d'això, l'argument econòmic es debilita.

Durant tot el curs treballarem amb un cas únic, perquè cada servei que veiem encaixi en una arquitectura que creix de manera coherent.

AlpinaShop és una pime espanyola d'unes 40 persones que ven material de muntanya per internet: motxilles, botes i tendes de campanya. El seu domini corporatiu és alpinashop.example. Les persones amb qui treballarem són:

• Marta, responsable d'infraestructura. Lidera la migració i serà qui creï projectes, configuri xarxes i vigili la facturació.
• Dani, desenvolupador backend. Manté l'aplicació Flask i desplega els canvis.
• Lucía, analista de dades. Avui viu dins d'un full de càlcul i vol respondre preguntes de negoci amb dades reals.

• Un servidor físic llogat en un proveïdor d'allotjament tradicional, amb contracte anual i un dimensionament fix.
• Una única instància de PostgreSQL en aquest mateix servidor, amb la base de dades tienda, i una còpia de seguretat diària a un disc extern la restauració del qual no s'ha provat mai.
• L'aplicació web és un catàleg en Python amb Flask servit per Gunicorn darrere de Nginx.
• Les imatges de producte (uns 60 GB i creixent) són al disc local del servidor, servides pel mateix Nginx.
• L'analítica consisteix a exportar un CSV mensual des de la base de dades a un full de càlcul.

Al llarg del curs construirem, peça a peça, aquesta arquitectura destí. Els noms són fixos i els retrobaràs a cada mòdul:

• Projectes alpinashop-prod i alpinashop-dev, a la regió europe-west1 (zona europe-west1-b).
• Bucket alpinashop-catalogo per a les imatges de producte.
• Instància Cloud SQL alpinashop-pedidos (PostgreSQL) amb la base de dades tienda.
• Servei Cloud Run alpinashop-web i clúster GKE alpinashop-cluster.
• Topic Pub/Sub pedidos-nuevos i dataset BigQuery alpinashop_analitica.

En aquesta lliçó no hem creat res encara: hem establert el perquè. A la següent obrirem el compte i posarem les primeres defenses contra ensurts a la factura.

• Creure que migrar és «aixecar les mateixes VMs al núvol». Un lift and shift literal reprodueix a GCP els mateixos problemes d'abans, i a més pagant per hora. És un primer pas vàlid per reduir risc, però només és un pas: el valor arriba en substituir components per serveis gestionats.
• Confondre «gestionat» amb «no és problema meu». El proveïdor gestiona la infraestructura; les teves dades, els teus permisos i la teva configuració continuen sent teus.
• Assumir que el núvol surt més barat sense fer números. Compara amb la càrrega real, no amb la teòrica, i inclou-hi el cost de personal i el de trànsit de sortida.
• Oblidar l'egress. Servir 60 GB d'imatges a molts usuaris genera trànsit de sortida facturable. És un argument a favor d'una CDN, no en contra del núvol.
• Aprendre el catàleg de memòria. Ningú coneix dos-cents serveis. Aprèn les famílies, i dins de cada família el criteri d'elecció. La lliçó 02-07 està dedicada precisament a aquest criteri per al còmput.
• Consell: pensa en el cost com una mètrica d'enginyeria. Igual que revises latència i errors, revisa despesa. Veure-ho aviat evita redissenys dolorosos.
• Consell: no busquis «el millor proveïdor». Busca el que millor encaixi amb el teu equip, el teu stack i els teus requisits regulatoris. Els tres funcionen.

Per a cadascuna d'aquestes situacions, indica si correspon a IaaS, PaaS, serverless o SaaS, i justifica quina part del manteniment desapareix de la teva llista de tasques:

1. Marta crea una màquina virtual amb Debian on instal·larà ella mateixa PostgreSQL.
2. Dani desplega l'aplicació Flask empaquetada en un contenidor i només indica quanta CPU necessita per petició.
3. AlpinaShop contracta Google Workspace per al correu corporatiu.
4. Marta crea una instància gestionada de PostgreSQL i tria versió, mida i finestra de còpies de seguretat.

Per a cadascun d'aquests tres problemes reals d'AlpinaShop, indica la família de serveis de GCP que l'aborda i el mòdul del curs on s'estudia. No cal que encertis el servei exacte: l'objectiu és raonar per família.

1. A la campanya de tardor el web triga 8 segons a carregar i alguns clients abandonen la cistella.
2. Lucía necessita creuar tres anys de comandes amb dades d'estoc per decidir quant material comprar.
3. Quan el web falla, ningú se n'assabenta fins que un client escriu pel formulari de contacte.

El servidor actual d'AlpinaShop costa 280 € al mes amb contracte anual i està dimensionat per suportar el pic de tardor. Durant 10 mesos a l'any utilitza al voltant del 15 % de la seva CPU; durant 6 setmanes se satura i el web es degrada.

Sense fer càlculs exactes de preus de GCP (que canvien i cal consultar), argumenta en cinc o sis línies quins avantatges econòmics i operatius oferiria un model de pagament per ús amb autoescalat, i quin risc econòmic nou apareix que abans no existia.

Solució 1

1. IaaS (Compute Engine). Google s'ocupa del maquinari, l'energia, la xarxa física i la virtualització. Marta continua sent responsable del sistema operatiu, els pedaços, la instal·lació de PostgreSQL, les seves còpies de seguretat i la seva alta disponibilitat.
2. Serverless (Cloud Run). Desapareixen el sistema operatiu, el servidor d'aplicacions, el dimensionament i l'escalat. Dani només manté la imatge del contenidor i la seva configuració.
3. SaaS. No queda cap tasca d'infraestructura: només administració d'usuaris i configuració del producte.
4. PaaS (Cloud SQL). Google gestiona el SO, la instal·lació del motor, els pedaços, les còpies de seguretat i la commutació per error. Marta continua sent responsable de l'esquema, les consultes, els índexs i de qui hi té accés.

Solució 2

1. Famílies de còmput (escalat automàtic) i xarxes (balanceig de càrrega i CDN). Mòduls 2, 3 i 7. La causa pot ser tant a la capacitat de còmput com al lliurament de les imatges.
2. Família de dades i analítica, amb BigQuery com a magatzem i Looker Studio per visualitzar. Mòdul 4.
3. Família de DevOps i operacions: Cloud Monitoring per a mètriques i alertes, Cloud Logging per a diagnòstic. Mòdul 6.

Solució 3

Resposta orientativa: avui AlpinaShop paga durant tot l'any la capacitat que només necessita sis setmanes, i tot i així aquesta capacitat resulta insuficient al pic (paga de més i serveix de menys, que és el pitjor d'ambdós mons). Amb pagament per ús i autoescalat, el cost seguiria aproximadament la demanda: baix als mesos tranquils i alt només durant la campanya, quan a més coincideix amb el màxim d'ingressos, de manera que el cost es correlaciona amb la facturació. A això s'hi sumen avantatges operatius difícils de valorar en euros però reals: desapareix el risc de quedar-se sense capacitat en el pitjor moment, i desapareixen tasques de manteniment del servidor.

El risc nou és que la despesa deixa de tenir un sostre natural. Un error de configuració, un bucle de reintents, un procés que no s'apaga o un pic de trànsit il·legítim poden disparar la factura sense que ningú ho autoritzi explícitament. Per això els pressupostos i les alertes de facturació es configuren el primer dia, no el primer ensurt: és exactament el que farem a la lliçó 01-02.

En aquesta lliçó hem construït el marc conceptual del curs. Hem vist què és la computació al núvol i quines cinc característiques la defineixen; com IaaS, PaaS, serverless i SaaS dibuixen una línia mòbil entre el que gestiona el proveïdor i el que gestiones tu; què és Google Cloud Platform i per què la seva xarxa global, els seus centres de dades propis i la seva herència tecnològica interna són arguments tècnics i no només comercials; quines famílies de serveis existeixen i en quin mòdul del curs s'estudia cadascuna; com es compara GCP amb AWS i Azure sense caure en el fanatisme; i per què el pas de CapEx a OpEx canvia les decisions de disseny, amb el pagament per ús i l'elasticitat com a peces centrals i el control de la despesa com a nova responsabilitat d'enginyeria.

I hem conegut AlpinaShop: el seu servidor llogat, el seu PostgreSQL únic, els seus 60 GB d'imatges a disc local i els seus pics de tardor que tomben el web. Marta, Dani i Lucía ens acompanyaran a cada lliçó.

A la lliçó següent, Configuració del teu compte de GCP, passem de la teoria a l'acció: crearem el compte, entendrem què inclou realment el nivell gratuït, veurem per què una empresa com AlpinaShop necessita Cloud Identity i no comptes personals, crearem el compte de facturació i el projecte alpinashop-dev, i configurarem pressupostos i alertes abans d'encendre res. Comencem a construir.