El cloud computing (computació al núvol) és el lliurament sota demanda de recursos informàtics (servidors, emmagatzematge, bases de dades, xarxa, programari) a través d'Internet, amb un model de pagament per ús. En lloc de comprar, instal·lar i mantenir maquinari propi en un centre de dades físic, una empresa lloga aquests recursos a un proveïdor (AWS, Microsoft Azure, Google Cloud, etc.) i els consumeix com un servei. Això és rellevant perquè canvia radicalment el model de costos (d'inversió CAPEX a despesa operativa OPEX), permet escalar en minuts en lloc de mesos i trasllada part de la responsabilitat operativa al proveïdor. Comprendre els models de servei, els models de desplegament i, sobretot, el repartiment de responsabilitats és la base de qualsevol decisió arquitectònica al núvol.

1. Quin problema resol el núvol i característiques essencials.
2. Models de servei: IaaS, PaaS i SaaS.
3. Models de desplegament: públic, privat, híbrid i multinúvol.
4. El model de responsabilitat compartida.
5. Geografia del núvol: regions, zones de disponibilitat i edge.
6. Errors comuns i consells.
7. Exercicis i solucions.

Abans del núvol, desplegar una aplicació implicava comprar servidors, esperar setmanes al seu lliurament, instal·lar-los en un rack, configurar xarxa i refrigeració, i mantenir-los durant anys encara que la demanda fos variable. El núvol resol això amb cinc característiques essencials (definides pel NIST, l'institut d'estàndards nord-americà):

• Autoservei sota demanda: l'usuari aprovisiona recursos per si mateix, sense intervenció humana del proveïdor.
• Accés ampli per xarxa: els recursos estan disponibles a través de la xarxa mitjançant mecanismes estàndard.
• Agrupació de recursos (resource pooling): el proveïdor serveix múltiples clients amb infraestructura compartida (multi-tenant).
• Elasticitat ràpida: la capacitat escala cap amunt o cap avall de forma automàtica segons la demanda.
• Servei mesurat (measured service): el consum es mesura i es factura de forma transparent (pagament per ús).

Els tres models clàssics es diferencien per quant gestiona el proveïdor i quant gestiones tu. Una analogia útil és la pizza: fer-la a casa (on-premises), comprar la massa congelada (IaaS), demanar-la a domicili (PaaS) o anar a un restaurant (SaaS).

• IaaS (Infraestructura com a Servei): llogues els blocs bàsics (CPU, RAM, disc, xarxa) normalment com a màquines virtuals. Tu instal·les el sistema operatiu, el runtime i l'aplicació. Màxima flexibilitat, màxima responsabilitat.
• PaaS (Plataforma com a Servei): puges el teu codi i el proveïdor s'encarrega del sistema operatiu, els pedaços, l'escalat i el balanceig. Ideal per accelerar el desenvolupament sense gestionar servidors.
• SaaS (Programari com a Servei): consumeixes una aplicació completa per subscripció. No gestiones res de la infraestructura; només uses i configures.

Existeixen models més recents com FaaS (Funcions com a Servei, base del serverless) i CaaS (Contenidors com a Servei), que veurem en lliçons posteriors.

El model de servei respon a "quin nivell d'abstracció consumeixo"; el model de desplegament respon a "on i per a qui viu aquest núvol".

• Núvol públic: recursos compartits del proveïdor. És el model més comú per la seva elasticitat i cost.
• Núvol privat: infraestructura dedicada (al teu CPD o allotjada), habitual en sectors molt regulats com la banca o les assegurances quan hi ha requisits estrictes de sobirania de la dada.
• Núvol híbrid: combina totes dues, per exemple mantenint dades sensibles en privat i desbordant pics de càrrega al públic (cloud bursting).
• Multinúvol: es fan servir diversos proveïdors públics alhora, per evitar la dependència d'un de sol o aprofitar el millor de cadascun.

Aquest és el concepte més important i pitjor entès de la seguretat al núvol. La idea: el proveïdor és responsable de la seguretat de el núvol (el maquinari, la xarxa física, la virtualització) i el client és responsable de la seguretat en el núvol (les seves dades, la seva configuració, els seus accessos). La frontera es mou segons el model de servei.

Explicació del diagrama: a mesura que passem d'IaaS a SaaS, la caixa del proveïdor creix i la del client es redueix. Però hi ha una constant: la responsabilitat sobre les dades i el control d'accessos gairebé mai es delega del tot. En IaaS tu apliques els pedaços al sistema operatiu; en PaaS ho fa el proveïdor; en SaaS gestiones únicament qui accedeix i quines dades introdueixes.

Un error clàssic és assumir que "està al núvol, per tant és segur". Si configures malament un bucket d'emmagatzematge i el deixes públic, la fuga de dades és responsabilitat teva, no del proveïdor. En sectors regulats (per exemple asseguradores subjectes a normativa com GDPR/LOPDGDD o DORA), entendre aquesta frontera és crític per al compliment; qualsevol disseny concret s'ha de validar amb l'equip de compliance corresponent.

Els proveïdors organitzen la seva infraestructura física en una jerarquia geogràfica:

• Regió (region): una zona geogràfica àmplia (ex. eu-west-1 a Irlanda, eu-south-2 a Espanya). Tries regió per latència (proximitat als usuaris), sobirania de la dada (que les dades no surtin de la UE) i cost (els preus varien per regió).
• Zona de disponibilitat (Availability Zone, AZ): dins d'una regió hi ha diverses zones, que són centres de dades físicament separats però connectats per xarxa de baixa latència. Serveixen per a la tolerància a fallades: si una AZ cau (incendi, tall elèctric), les altres segueixen funcionant.
• Edge / punts de presència (PoP): ubicacions properes a l'usuari final per fer memòria cau de contingut (CDN) i reduir la latència.

Explicació de les comandes:

• aws ec2 describe-regions: demana al proveïdor el catàleg de regions. El paràmetre --query filtra la resposta JSON per mostrar només el nom, i --output table la presenta en taula llegible.
• aws ec2 describe-availability-zones --region eu-west-1: llista les zones dins de la regió d'Irlanda. Veuràs una cosa com eu-west-1a, eu-west-1b, eu-west-1c. Distribuir els teus servidors entre diverses AZ és la pràctica bàsica d'alta disponibilitat.

La regla d'or de la resiliència: desplega en almenys dues zones de disponibilitat per sobreviure a la caiguda d'un centre de dades, i considera multiregió només si necessites recuperació davant desastres a escala geogràfica (és més car i complex).

• Confondre model de servei amb model de desplegament. Són eixos ortogonals: pots tenir IaaS en núvol privat o SaaS en núvol públic. No són el mateix.
• Creure que "tot ho gestiona el proveïdor". El model de responsabilitat compartida deixa sempre les dades i els accessos al teu costat. Configura xifratge i permisos mínims.
• Ignorar la regió per descuit. Desplegar als EUA dades de clients europeus pot infringir la normativa de protecció de dades. Tria la regió conscient de la sobirania de la dada.
• No fer servir diverses zones de disponibilitat. Un desplegament en una sola AZ no és alta disponibilitat: és un punt únic de fallada amb factura mensual.
• Subestimar el lock-in. Fer servir serveis propietaris accelera al principi però lliga a un proveïdor. Valora el cost de migrar abans de comprometre't.
• Consell: comença per PaaS o serveis gestionats quan puguis; baixa a IaaS només quan necessitis un control que la plataforma no et dona.

1. Una startup vol llançar una API web ràpid, sense equip d'operacions, i prefereix no gestionar servidors ni pedaços. Quin model de servei recomanaries i per què?
2. La teva empresa emmagatzema dades sensibles de clients europeus. Explica dues decisions de disseny relacionades amb regions i responsabilitat compartida que hagis de prendre.
3. Classifica aquests serveis en IaaS, PaaS o SaaS: (a) una màquina virtual Linux buida, (b) Gmail, (c) una plataforma on puges el teu codi i es desplega sola.

1. PaaS. En no tenir equip d'operacions i voler velocitat, l'ideal és pujar el codi a una plataforma gestionada (tipus App Service, App Engine o Heroku) que s'ocupi del sistema operatiu, els pedaços i l'escalat. IaaS exigiria administrar servidors; SaaS no aplica perquè desenvolupen el seu propi programari.
2. (a) Triar una regió dins de la UE (ex. Espanya o Irlanda) per respectar la sobirania i la normativa de protecció de dades, evitant que les dades resideixin fora del territori permès. (b) Assumir la responsabilitat sobre el xifratge i els controls d'accés, ja que el model de responsabilitat compartida deixa sempre la protecció de la dada al costat del client; el proveïdor només garanteix la seguretat de la infraestructura. Qualsevol decisió concreta l'ha de revisar l'equip de compliance.
3. (a) IaaS (et donen la infraestructura nua), (b) SaaS (aplicació llesta per fer servir), (c) PaaS (plataforma per desplegar el teu codi).

Hem vist què és el núvol, els seus tres models de servei (IaaS, PaaS, SaaS) i com es diferencien pel repartiment de gestió, els models de desplegament (públic, privat, híbrid, multinúvol), el crític model de responsabilitat compartida i la geografia de regions i zones de disponibilitat. Aquests fonaments són la base sobre la qual es construeix tota la resta. A la lliçó següent baixarem un nivell d'abstracció per empaquetar i executar aplicacions de forma portable i reproduïble amb contenidors i orquestració mitjançant Docker i Kubernetes.