Kaj je serverless in FaaS

Kaj je serverless computing

Serverless computing je model računalništva v oblaku, kjer cloud ponudnik samodejno upravlja z infrastrukturo. V nasprotju s klasičnim spletnim gostovanjem, skaliranjem in dodeljevanjem virov namesto vas. Kljub imenu strežniki še naprej obstajajo, vendar o njih ne razmišljate niti jih ne konfigurirate. Pišete kodo, jo razmestite in cloud ponudnik poskrbi za vse ostalo, vključno z operacijskim sistemom, runtime okoljem, skaliranjem in visoko razpoložljivostjo. Plačujete samo za čas izvajanja vaše kode, ne za čas, ko strežnik čaka na zahteve.

Serverless je evolucija od fizičnih strežnikov prek virtualnih strojev in kontejnerjev do popolnoma abstrahiranega computing modela. Vsak korak v tej evoluciji odstranjuje en sloj odgovornosti z razvijalca in ga prenaša na cloud ponudnika. Pri serverless modelu se razvijalec osredotoča izključno na poslovno logiko, medtem ko cloud ponudnik skrbi za vse ostalo, kar dramatično pospeši razvoj in zmanjšuje operativne stroške za številne vrste aplikacij.

Functions as a Service (FaaS)

FaaS je najbolj prepoznavna oblika serverless computinga. V FaaS modelu pišete majhne, samostojne funkcije, ki se izvajajo kot odgovor na dogodke (events). Vsaka funkcija ima eno jasno določeno odgovornost, prejme vhodne podatke, izvaja logiko in vrne rezultat. Cloud ponudnik samodejno ustvari instanco za izvajanje funkcije, jo izvede in ugasne instanco, ko zaključi. Če pride 1000 sočasnih zahtev, ponudnik samodejno ustvari 1000 instanc.

Glavni FaaS ponudniki

• AWS Lambda - prva in najbolj zrela FaaS storitev, zagnana leta 2014
• Google Cloud Functions - Googleov FaaS z dobro integracijo s Firebase
• Azure Functions - Microsoftov FaaS z odlično podporo za .NET
• Cloudflare Workers - edge computing z globalno distribucijo in V8 izolacijo
• Vercel Functions - optimizirano za Next.js in frontend ogrodja
• Netlify Functions - preprosto za Jamstack spletne strani

Vsak ponudnik ima posebnosti glede podprtih programskih jezikov, največjega časa izvajanja, omejitev pomnilnika in načina sprožanja. Za klasičnejši pristop razmislite o cloud hosting storitvi. AWS Lambda podpira Node.js, Python, Java, Go, .NET in Ruby z največjim časom izvajanja 15 minut in do 10 GB pomnilnika. Cloudflare Workers uporabljajo V8 runtime z omejitvijo na 50 ms CPU časa (brezplačni plan), vendar z izjemno nizko latenco, saj se izvajajo na edge lokacijah.

Kako delujejo serverless funkcije

Ko dogodek sproži serverless funkcijo, cloud ponudnik prehaja skozi več korakov. Najprej preveri, ali obstaja topla instanca, ki je že inicializirana in pripravljena za izvajanje. Če ne obstaja, se ustvari nova instanca, kar se imenuje cold start. Cold start vključuje zagon kontejnerja, nalaganje runtimea, nalaganje vaše kode in izvajanje inicializacijske logike. Po tem se izvede handler funkcija s podatki iz dogodka.

Problem cold starta

Cold start je najpogostejši vir latence v serverless arhitekturi. Za Node.js funkcije cold start običajno traja 100-500 ms, za Python 200-800 ms, za Javo pa je lahko 1-5 sekund ali več zaradi inicializacije JVM. Po prvem izvajanju instanca ostane topla nekaj časa (običajno 5-15 minut) in naslednje zahteve se izvajajo veliko hitreje, saj preskočijo inicializacijo.

Strategije za zmanjšanje cold starta vključujejo uporabo lažjih runtime-ov (Node.js in Python sta hitrejša od Jave), zmanjšanje velikosti deployment paketa, uporabo provisioned concurrency (plačujete za vnaprej segrete instance) in izogibanje težkim inicializacijam v handler funkciji. AWS Lambda SnapStart za Javo in Cloudflare Workers, ki uporabljajo V8 isolates namesto kontejnerjev, bistveno zmanjšujejo cold start do ravni, ki je za večino aplikacij zanemarljiva.

Primeri uporabe serverless

Serverless arhitektura je idealna za določene vrste obremenitev, medtem ko je za druge lahko draga ali nepraktična. Razumevanje pravega primera uporabe je ključno za uspešno uporabo serverless modela v praksi.

Idealni scenariji

• API backendi - REST ali GraphQL API-ji, ki obdelujejo HTTP zahteve
• Obdelava dogodkov - odzivanje na nalaganje datoteke, spremembo v podatkovni bazi, sporočilo v čakalni vrsti
• Načrtovani opravki - cron opravila, ki se izvajajo periodično
• Obdelava slik in videa - resizing, kompresija, transkodiranje na zahtevo
• Chatboti in AI inference - obdelava uporabniških sporočil in klici na AI modele
• Webhooks - sprejem in obdelava webhook klicev od zunanjih storitev
• IoT data processing - obdelava podatkov s senzorjev in naprav

Manj primerni scenariji

Serverless ni optimalen za dolgotrajne procese, ki trajajo več kot 15 minut, za aplikacije, ki zahtevajo konstantno nizko latenco (problem cold starta), za obremenitve s konstantno visokim prometom, kjer je namenski strežnik cenejši, in za aplikacije, ki zahtevajo lokalni datotečni sistem ali dolgotrajne WebSocket povezave. V teh primerih so kontejnerji ali tradicionalni strežniki boljša izbira.

Model zaračunavanja

Ena največjih prednosti serverless modela je plačilo po porabi (pay-per-use). Ne plačujete za idle čas strežnika, ampak samo za čas, ko se vaša koda aktivno izvaja. AWS Lambda zaračunava po številu zahtev (0,20 USD za milijon zahtev) in po trajanju izvajanja, merjenem v GB-sekundah (koliko pomnilnika funkcija uporablja, pomnoženo s trajanjem izvajanja v sekundah).

Primerjava stroškov

Za majhno spletno stran ali API s 100.000 zahtevami mesečno, kjer vsaka zahteva traja 200 ms s 256 MB pomnilnika, bi bil mesečni strošek na AWS Lambda pod enim evrom. Enakovreden EC2 strežnik t3.micro stane okoli 8,50 USD mesečno, tudi ko večino časa ne dela nič. Za to vrsto obremenitve je serverless drastično cenejši.

Vendar pa se izračun spreminja pri velikem obsegu. Za aplikacijo s 100 milijoni zahtev mesečno lahko serverless stroški presežejo 200 USD mesečno, namenski strežnik s podobno zmogljivostjo pa bi stal manj. Tako imenovani serverless cost cliff nastane, ko obremenitev preseže določen prag, kjer postane konstantno zakupljen strežnik bolj donosen. Za vsako aplikacijo je pomembno narediti analizo stroškov za pričakovano obremenitev pred izbiro modela.

Prednosti serverless arhitekture

• Brez upravljanja infrastrukture - ne skrbite za strežnike, popravke, skaliranje
• Samodejno skaliranje - od nič do milijona zahtev brez kakršne koli konfiguracije
• Pay-per-use - plačujete samo za izvajanje, ne za idle čas
• Hitrejši razvoj - poudarek na kodi namesto na infrastrukturi pospeši dostavo
• Visoka razpoložljivost - cloud ponudnik zagotavlja razpoložljivost brez vaše angažiranosti
• Skaliranje do nič - brez stroškov, ko ni prometa

Slabosti in izzivi

Serverless arhitektura prinaša tudi specifične izzive. Vendor lock-in je resničen, saj ima vsak ponudnik specifične API-je, storitve in orodja, ki otežujejo migracijo na drugega ponudnika. Cold start latenca je lahko problematična za aplikacije, ki zahtevajo dosledno hitri odziv. Debugging in monitoring sta kompleksnejša, saj se funkcije izvajajo v efemernih okoljih brez dostopa do tradicionalnih orodij za diagnostiko.

Lokalni razvoj in testiranje prav tako predstavljata izziv, saj je težko replicirati cloud okolje lokalno. Orodja, kot so AWS SAM, Serverless Framework in LocalStack, pomagajo, vendar ne morejo v celoti simulirati vedenja v produkciji. Omejitve glede velikosti deployment paketa, časa izvajanja in pomnilnika lahko zahtevajo refaktoriranje obstoječih aplikacij. Nazadnje je za ekipe brez izkušenj s cloud storitvami krivulja učenja lahko strma.