L'arquitectura serverless (sense servidor) és un model en què escrius i desplegues codi sense gestionar ni aprovisionar servidors: el proveïdor cloud s'encarrega completament de la infraestructura, executa el teu codi només quan cal i et cobra únicament pel temps d'execució real, normalment en mil·lisegons. El nom enganya: és clar que hi ha servidors, però tu no els veus ni els administres. La seva màxima expressió és FaaS (Funcions com a Servei), on desplegues funcions petites que reaccionen a esdeveniments. És rellevant perquè permet construir sistemes que escalen automàticament de zero a milers d'execucions, amb cost zero quan no hi ha trànsit, i redueix dràsticament la càrrega operativa. Però no és una bala de plata: té limitacions importants (el cold start, els temps màxims d'execució, la dependència del proveïdor) que has de conèixer per decidir quan aplicar-lo.

1. Què és serverless i què és FaaS.
2. Arquitectura dirigida per esdeveniments.
3. El problema del cold start (arrencada en fred).
4. Avantatges i limitacions.
5. Exemple de funció serverless.
6. Quan fer servir serverless i quan no.
7. Errors comuns i consells.
8. Exercicis i solucions.

"Serverless" és un paraigua que inclou diversos tipus de serveis gestionats que escalen sols i es paguen per ús: bases de dades serverless, cues de missatges, emmagatzematge d'objectes, etc. El seu component més representatiu és FaaS (Function as a Service): puges una funció —una unitat de codi petita i sense estat— i el proveïdor l'executa en resposta a un esdeveniment (una petició HTTP, un fitxer pujat, un missatge en una cua, un temporitzador). Exemples: AWS Lambda, Azure Functions, Google Cloud Functions.

El serverless brilla en arquitectures dirigides per esdeveniments (event-driven): les funcions no estan "sempre enceses" esperant, sinó que s'activen davant d'un disparador (trigger). Això encaixa de forma natural amb fluxos asíncrons i desacoblats.

Explicació del diagrama: l'usuari puja una imatge a l'emmagatzematge. Aquest acte emet un esdeveniment que dispara una funció per generar una miniatura. La funció desa el resultat i publica un missatge en una cua, que al seu torn dispara una altra funció que notifica l'usuari. Cada peça és petita, independent i escala per separat. No hi ha servidors esperant: el codi només s'executa quan passa alguna cosa.

Quan una funció no s'ha fet servir recentment, el proveïdor no té un entorn llest per a ella. Davant de la primera invocació ha de: aprovisionar un contenidor, carregar el runtime (Node, Python, Java…) i inicialitzar el teu codi. Aquest retard inicial és el cold start (arrencada en fred) i pot anar de desenes de mil·lisegons a diversos segons. Les invocacions següents, mentre l'entorn segueix "calent", són ràpides (warm start).

Mitigacions habituals: mantenir funcions petites, triar runtimes lleugers, fer servir concurrència aprovisionada (entorns preescalfats que es paguen a part) i reutilitzar connexions fora del handler perquè persisteixin entre invocacions calentes.

Una funció AWS Lambda en Node.js que respon a una petició HTTP. El handler és el punt d'entrada que el proveïdor invoca amb l'event (dades del disparador) i el context (metadades de l'execució):

Explicació del codi:

• La línia const db = require("./db").connect(); està fora del handler expressament: el codi d'inicialització s'executa una sola vegada per entorn i es reutilitza en invocacions calentes, evitant reconnectar cada vegada. És una optimització clau en serverless.
• exports.handler = async (event, context) => {...}: el handler és la funció que el proveïdor crida. event porta les dades del disparador; context porta metadades (temps restant, identificadors).
• Es valida l'entrada i, si falta l'id, es respon amb el codi HTTP 400 (petició incorrecta).
• Es consulta la dada i es retorna un objecte amb statusCode, headers i body. El proveïdor (via API Gateway) tradueix aquest objecte en una resposta HTTP real.
• El bloc catch registra l'error i retorna 500 per no exposar detalls interns.

Per definir el disparador HTTP de forma declarativa amb el Serverless Framework:

Explicació: runtime fixa l'entorn d'execució; memorySize i timeout configuren recursos i límit de temps; handler apunta a index.js i a la funció handler; el bloc events declara que una petició GET /usuaris invoca la funció. El framework s'encarrega de crear la Lambda, l'API Gateway i els permisos.

Bons casos d'ús:

• APIs i backends amb trànsit irregular o impredictible (pics puntuals).
• Processament d'esdeveniments: redimensionar imatges, processar fitxers pujats, reaccionar a missatges d'una cua.
• Tasques programades (cron) i automatitzacions puntuals.
• Webhooks i integracions lleugeres entre sistemes.
• Prototips i MVP on vols anar ràpid sense muntar infraestructura.

Mals casos d'ús:

• Aplicacions amb trànsit alt, constant i predictible: a aquest volum sol sortir més barat un servidor o contenidor reservat.
• Processos llargs (per sobre del límit de temps de la funció) o amb ús intensiu de CPU/memòria sostingut.
• Càrregues amb latència crítica i estricta on el cold start seria inacceptable.
• Aplicacions amb estat en memòria persistent (les funcions són efímeres i sense estat).

• Ficar connexions a base de dades dins del handler. Declara-les fora per reutilitzar-les en warm starts i vigila l'esgotament del pool de connexions, un problema clàssic quan moltes funcions escalen alhora.
• Funcions massa grans (funcions monolítiques). Mantén cada funció centrada en una tasca; els paquets grans empitjoren el cold start.
• Ignorar el cost a escala. Serverless és barat amb poc trànsit, però amb milions d'invocacions constants pot ser més car que un contenidor. Mesura.
• No dissenyar per a la idempotència. Els esdeveniments poden lliurar-se més d'una vegada; les teves funcions han de tolerar execucions repetides sense efectes duplicats.
• Oblidar l'observabilitat. En ser distribuït i efímer, sense traces i mètriques adequades depurar és molt difícil. Instrumenta des del principi.
• Consell: abraça el desacoblament per esdeveniments, però documenta bé el flux: una embullada de funcions sense diagrama es torna inmanejable.

1. Explica per què declarar la connexió a la base de dades fora del handler millora el rendiment, i en quin tipus d'invocacions es nota.
2. Una empresa té una API interna amb trànsit constant i elevat les 24 hores. Recomanaries serverless? Justifica-ho.
3. Descriu un flux event-driven serverless per processar factures que es pugen a un emmagatzematge: quins disparadors i funcions encadenaries?

1. Perquè el codi situat fora del handler s'executa una sola vegada en inicialitzar l'entorn i es reutilitza mentre l'entorn segueix calent, evitant reobrir la connexió en cada crida. La millora es nota en les invocacions calentes (warm starts) consecutives; en el primer cold start igualment cal inicialitzar.
2. No, probablement no. Amb trànsit constant i elevat les 24 h, el model de pagament per invocació tendeix a resultar més car que un contenidor o servidor reservat, que a més evita completament el cold start. Serverless rendeix millor amb trànsit irregular o amb pics.
3. Possible flux: (1) l'usuari puja la factura a l'emmagatzematge d'objectes, cosa que emet un esdeveniment ObjectCreated; (2) aquest esdeveniment dispara una funció de validació/extracció que llegeix el PDF i n'obté les dades; (3) la funció publica un missatge en una cua; (4) aquest missatge dispara una altra funció de registre que desa les dades en una base de dades i, opcionalment, dispara una tercera funció de notificació. Cada pas és independent, asíncron i escala per separat.

Has comprès el model serverless i el seu cor FaaS, l'arquitectura dirigida per esdeveniments, el repte del cold start, el balanç d'avantatges i limitacions, com s'escriu una funció i, sobretot, quan convé i quan no. Serverless és una eina potent per a càrregues irregulars i fluxos per esdeveniments, no una solució universal. A la lliçó següent recollirem bones pràctiques transversals per construir aplicacions robustes al núvol amb els patrons de disseny cloud-native.