Què és serverless? La computació sense servidor explicada de manera senzilla

Serverless és una manera d'executar codi sense configurar ni gestionar cap servidor. Lliures el teu codi a un proveïdor de núvol, i aquest només l'executa quan alguna cosa el dispara —una petició web, un fitxer pujat, una notificació de pagament— i després s'atura. Normalment pagues pel temps que el codi s'està executant, no per una màquina aturada.

Per què importa quan crees amb IA

Quan mires opcions d'allotjament o codi en crear una app amb IA, t'hi trobaràs les «funcions serverless», les «funcions d'edge» o les «funcions al núvol». Moltes plataformes d'allotjament les ofereixen, i alguns creadors d'apps amb IA despleguen backends així. Entendre el model t'ajuda amb tres preguntes pràctiques:

• Cost. La teva app costarà diners mentre ningú l'usi?
• Velocitat. Per què la primera petició després d'un període tranquil és més lenta?
• Límits. Per què una tasca llarga —generar un informe gran, processar un vídeo— ha caducat?

També ajuda saber què no és serverless: no vol dir que no hi hagi backend. Continues tenint codi del costat del servidor; només que algú altre gestiona les màquines. Per als conceptes bàsics, mira què és un servidor.

Una analogia del dia a dia

Un servidor tradicional és com tenir un cotxe propi. Sempre és allà, a punt per anar a l'instant, però el pagues —assegurança, aparcament, manteniment— tant si el conduiu com si no.

Serverless és com demanar un taxi. Només pagues els trajectes que fas, i si cent persones necessiten un taxi alhora, arriben cent taxis. Però pot haver-hi una petita espera perquè arribi el cotxe (un cold start), cada trajecte té una durada màxima, i el conductor no et recorda des de l'últim viatge (les funcions són sense estat, o stateless).

Com funcionen les funcions serverless

En la seva forma més comuna, anomenada functions as a service (funcions com a servei):

1. Escrius una funció: un petit tros de codi que gestiona un tipus d'esdeveniment, com ara «gestiona un POST a /api/bookings».
2. La desplegues. El proveïdor la guarda i la connecta a un disparador: una URL, un horari, un nou fitxer a l'emmagatzematge, un missatge en una cua.
3. Arriba un esdeveniment. El proveïdor engega una còpia de la teva funció (o reutilitza una de ja escalfada), l'executa i retorna el resultat.
4. S'escala sola. Si arriben mil peticions alhora, el proveïdor executa moltes còpies en paral·lel, fins als límits del teu compte.
5. Es queda inactiva. Quan el trànsit s'atura, les còpies s'apaguen. Si no hi ha res en execució, no pagues res de còmput.

Una funció serverless petita en JavaScript podria tenir aquest aspecte:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

No cal codi per arrencar un servidor, obrir un port o mantenir un procés en execució. La plataforma s'encarrega de tot això.

De vegades «serverless» també s'usa de manera més laxa per a altres serveis gestionats que s'escalen automàticament i es cobren per ús, com les bases de dades serverless, que es pausen quan estan inactives.

Termes clau

Un exemple resolt: un petit web de reserves

El web de reserves d'un estudi de ioga rep una allau de visites cada diumenge al vespre, quan es publica el nou horari, i molt poques la resta de la setmana.

• Amb un servidor sempre encès, l'estudi paga una màquina les 24 hores, dimensionada per al pic de diumenge al vespre, i gairebé inactiva la resta del temps.
• Amb funcions serverless, GET /api/classes i POST /api/bookings són funcions. L'allau de diumenge engega moltes còpies automàticament; un dimarts tranquil al matí, quasi no s'executa res i la factura és propera a zero.

Els compromisos també apareixen. La primera persona que obri el web un dimarts al matí pot esperar un moment extra per un cold start. La base de dades ha de gestionar moltes connexions curtes de moltes còpies de funció, cosa que pot fer necessari un pool de connexions. I si més endavant l'estudi vol una tasca de «generar el PDF d'assistència anual de tothom», pot superar el límit de temps de la funció i caldrà executar-la en un altre lloc.

Quan encaixa serverless i quan no

Idees equivocades habituals

• «Serverless vol dir sense backend». Vol dir sense servidors que gestionar. Continues escrivint i protegint codi de backend.
• «Serverless sempre és més barat». Barat a baix volum, però el preu per petició pot sumar-se amb un volum alt i constant.
• «Serverless escala infinitament». Les plataformes tenen límits de concurrència, i la teva base de dades pot ser el coll d'ampolla molt abans que les funcions.
• «Els fitxers guardats en una funció hi seran la pròxima vegada». L'emmagatzematge local és temporal. Usa una base de dades o emmagatzematge de fitxers.
• «Escalar a zero és el mateix que serverless». Relacionats, però no idèntics. Algunes plataformes executen la teva app com un servidor normal que s'adorm quan està inactiu i es desperta amb la següent petició: estalvi similar i un retard similar a la primera petició, però sense els límits de temps per petició de les funcions.

Què demanar al teu creador d'apps amb IA

• «Aquest backend s'executarà com a funcions serverless o com a servidor sempre encès o que s'adorm? Què vol dir per al cost?»
• «És probable que alguna tasca superi el límit de temps de la plataforma? Si és així, com la gestionem?»
• «Guarda tot el que ha de persistir a la base de dades o a l'emmagatzematge de fitxers, no a la memòria o als fitxers locals.»
• «Com s'han de gestionar les connexions a la base de dades si moltes còpies s'executen alhora?»
• «Quin és el retard de la primera petició després que l'app hagi estat inactiva?»

Com allotja Mythex les apps

Mythex no descriu el seu allotjament com a funcions serverless. Quan publiques, la teva app s'executa com una aplicació web normal o un contenidor que Mythex gestiona per tu; no cal configurar cap allotjament. És escalar a zero: les apps publicades i les seves bases de dades s'adormen quan estan inactives i es desperten amb la següent visita; una app adormida no gasta res de còmput, i les màquines addicionals només s'engeguen quan hi ha molt trànsit (el Pro permet fins a 3 per servei). La base de dades Postgres connectada també s'adorm després de 5 minuts inactiva i es factura pel temps que ha estat despert. Així obtens gran part del benefici de «pagar pel que uses», amb el mateix tipus de retard en la primera petició després d'un període tranquil. Mira límits d'allotjament a la documentació, i les nostres guies sobre allotjament web i reduir els costos d'allotjament.

Preguntes