Ce este serverless? Serverless computing explicat simplu

Serverless este un mod de a rula cod în care nu configurezi și nu gestionezi tu niciun server. Îi dai codul tău unui furnizor de cloud, iar acesta rulează codul doar când ceva îl declanșează — o cerere web, un fișier încărcat, o notificare de plată — apoi se oprește. De obicei plătești pentru timpul în care codul tău rulează efectiv, nu pentru o mașină care stă inactivă.

De ce contează serverless când construiești cu AI

Când construiești o aplicație cu AI și te uiți la opțiuni de hosting sau la cod, vei întâlni „funcții serverless”, „funcții edge” sau „funcții cloud”. Multe platforme de hosting le oferă, iar unele constructoare AI publică backend-uri în acest fel. Înțelegerea modelului te ajută cu trei întrebări practice:

• Cost. Va costa aplicația ta bani cât timp nu o folosește nimeni?
• Viteză. De ce este prima cerere după o perioadă liniștită mai lentă?
• Limite. De ce a expirat o sarcină lungă — generarea unui raport mare, procesarea unui video?

Ajută și să știi ce nu este serverless: nu înseamnă absența unui backend. Ai în continuare cod pe server; doar că altcineva rulează mașinile. Pentru bazele acestui subiect, vezi ce este un server.

O analogie din viața de zi cu zi

Un server tradițional este ca un automobil deținut de tine. Este mereu acolo, gata să pornească instant, dar plătești pentru el — asigurare, parcare, întreținere — indiferent dacă îl folosești sau nu.

Serverless este ca a chema un taxi. Plătești doar cursele pe care le faci, iar dacă o sută de oameni au nevoie de o cursă deodată, vin o sută de taxiuri. Dar poate exista o scurtă așteptare până ajunge mașina (un cold start), fiecare cursă are o lungime maximă, iar șoferul nu își amintește de tine de la cursa precedentă (funcțiile sunt stateless, fără stare).

Cum funcționează funcțiile serverless

În forma cea mai comună, numită functions as a service:

1. Scrii o funcție — o bucată mică de cod care tratează un anumit tip de eveniment, de exemplu „tratează un POST către /api/bookings”.
2. O publici. Furnizorul o stochează și o leagă de un declanșator: un URL, un program, un fișier nou în stocare, un mesaj într-o coadă.
3. Sosește un eveniment. Furnizorul pornește o copie a funcției tale (sau reutilizează una deja caldă), o rulează și returnează rezultatul.
4. Se scalează singură. Dacă sosesc o mie de cereri deodată, furnizorul rulează multe copii în paralel, până la limitele contului tău.
5. Intră în inactivitate. Când traficul se oprește, copiile se închid. Fără nimic în execuție, nu plătești nimic pentru calcul.

O funcție serverless minusculă în JavaScript ar putea arăta așa:

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

Nu există cod care să pornească un server, să deschidă un port sau să mențină un proces în viață. Platforma se ocupă de toate acestea.

„Serverless” este folosit și mai liber pentru alte servicii gestionate care se scalează automat și se taxează pe utilizare — de exemplu bazele de date serverless, care se opresc când nu sunt folosite.

Termeni cheie

Un exemplu lucrat: un mic site de rezervări

Site-ul unui studio de yoga primește un val de vizite în fiecare duminică seara, când apare noul program, și foarte puține în restul săptămânii.

• Pe un server pornit permanent, studioul plătește o mașină 24/7, dimensionată pentru vârful de duminică seara și mai mult inactivă restul timpului.
• Cu funcții serverless, GET /api/classes și POST /api/bookings sunt funcții. Aglomerația de duminică pornește automat multe copii; într-o marți dimineața liniștită, aproape nimic nu rulează, iar factura este aproape zero.

Apar și compromisurile. Prima persoană care deschide site-ul marți dimineața ar putea aștepta un pic în plus din cauza unui cold start. Baza de date trebuie să gestioneze multe conexiuni scurte de la multe copii de funcții, ceea ce poate cere un pooler de conexiuni. Și dacă studioul vrea mai târziu un task „generează PDF-ul cu prezențele anuale ale tuturor”, acesta poate depăși limita de timp a funcției și să aibă nevoie de un alt loc de rulare.

Când se potrivește serverless — și când nu

Idei greșite frecvente

• „Serverless înseamnă fără backend.” Înseamnă fără servere de gestionat. Tot trebuie să scrii și să securizezi codul de backend.
• „Serverless este întotdeauna mai ieftin.” Ieftin la volum mic, dar prețul per cerere se poate aduna la volum mare și constant.
• „Serverless se scalează infinit.” Platformele au limite de concurență, iar baza ta de date poate deveni blocajul cu mult înainte ca funcțiile să devină.
• „Fișierele salvate într-o funcție vor fi acolo și data viitoare.” Stocarea locală este temporară. Folosește o bază de date sau stocare de fișiere.
• „Scale-to-zero este același lucru cu serverless.” Înrudite, dar nu identice. Unele platforme rulează aplicația ta ca un server obișnuit care doarme când nu e folosit și se trezește la următoarea cerere — economii similare și o întârziere similară la prima cerere, dar fără limitele de timp pe cerere specifice funcțiilor.

Ce să ceri constructorului tău AI

• „Acest backend va rula ca funcții serverless, sau ca un server pornit permanent ori care doarme? Ce înseamnă asta pentru cost?”
• „Este probabil ca unele sarcini să depășească limita de timp a platformei? Dacă da, cum le tratăm?”
• „Stochează tot ce trebuie să persiste în baza de date sau în stocarea de fișiere, nu în memorie sau în fișiere locale.”
• „Cum ar trebui gestionate conexiunile la baza de date dacă rulează multe copii deodată?”
• „Care este întârzierea la prima cerere după ce aplicația a stat inactivă?”

Cum găzduiește Mythex aplicațiile

Mythex nu își descrie hosting-ul ca funcții serverless. Când publici, aplicația ta rulează ca o aplicație web sau un container obișnuit, gestionat de Mythex pentru tine — nu trebuie configurat niciun hosting. Este scale-to-zero: aplicațiile publicate și bazele lor de date dorm când nu sunt folosite și se trezesc la următoarea vizită, o aplicație care doarme nu cheltuie nimic pe calcul, iar mașini suplimentare pornesc doar când traficul este mare (Pro permite până la 3 per serviciu). Baza de date Postgres atașată doarme și ea după 5 minute de inactivitate și se taxează pentru timpul în care a fost trează. Deci obții o mare parte din beneficiul „plătești doar ce folosești”, cu același tip de întârziere la prima cerere după o perioadă liniștită. Vezi limitele de hosting din documentație și ghidurile noastre despre hosting web și reducerea costurilor de hosting.

Întrebări