Što je serverless i FaaS

Što je serverless computing

Serverless computing je model oblak računarstva gdje cloud pružatelj automatski upravlja infrastrukturom. Za razliku od klasičnog web hostinga, skaliranjem i alokacijom resursa umjesto vaš. Uprkos imenu, serveri i dalje postoje ali vi o njima ne razmišljate niti ih konfigurisete. Pisete kod, deploy-ujete ga i cloud pružatelj se brine o svemu ostalom uključujući operativni sistem, runtime okruženje, skaliranje i visoku dostupnost. Placate samo za vrijeme izvršavanja vašeg koda, ne za vrijeme kada server ceka na zahtjeve.

Serverless je evolucija od fizičkih servera, preko virtualnih masina i kontejnera do potpuno apstrahovanog computing modela. Svaki korak u ovoj evoluciji uklanja jedan sloj odgovornosti sa developera i prenosi ga na cloud pružatelja. Kod serverless modela developer se fokusira isključivo na poslovnu logiku dok se cloud pružatelj brine o svemu ostalom što dramatično ubrzava razvoj i smanjuje operativne troškove za mnoge tipove aplikacija.

Functions as a Service (FaaS)

FaaS je najprepoznatljiviji oblik serverless computing-a. U FaaS modelu pišete male, samostalne funkcije koje se izvršavaju kao odgovor na događaje (events). Svaka funkcija ima jednu jasno definisanu odgovornost, prima ulazne podatke, izvršava logiku i vraća rezultat. Cloud pružatelj automatski kreira instancu za izvršavanje funkcije, izvršava je i gasi instancu kada zavrsi. Ako pristigne 1000 istovremenih zahtjeva, pružatelj automatski kreira 1000 instanci.

Glavni FaaS pružatelji

• AWS Lambda - prvi i najzreliji FaaS servis, pokrenut 2014. godine
• Google Cloud Functions - Googleov FaaS sa dobrom integracijom sa Firebase
• Azure Functions - Microsoftov FaaS sa odličnom .NET podrškom
• Cloudflare Workers - edge computing sa globalnom distribucijom i V8 izolacijom
• Vercel Functions - optimizirano za Next.js i frontend framework-e
• Netlify Functions - jednostavno za Jamstack sajtove

Svaki pružatelj ima specifičnosti u pogledu podrzbanih programskih jezika, maksimalnog vremena izvršavanja, memorijskih limita i načina triggera. Za klasičniji pristup razmotrite cloud hosting uslugu. AWS Lambda podržava Node.js, Python, Java, Go, .NET i Ruby sa maksimalnim vremenom izvršavanja od 15 minuta i do 10 GB memorije. Cloudflare Workers koriste V8 runtime sa ogranicenjem na 50ms CPU vremena (besplatni plan) ali sa izuzetno niškom latencijom jer se izvršavaju na edge lokacijama.

Kako serverless funkcije rade

Kada događaj pokrene serverless funkciju, cloud pružatelj prolazi kroz nekoliko koraka. Prvo provjerava da li postoji topla instanca koja je već inicijalizovana i spremna za izvršavanje. Ako ne postoji, kreira se nova instanca što se naziva cold start. Cold start uključuje pokretanje kontejnera, učitavanje runtime-a, učitavanje vašeg koda i izvršavanje inicijalizacione logike. Nakon toga se izvršava handler funkcija sa podacima iz događaja.

Cold start problem

Cold start je najčešći izvor latencije u serverless arhitekturi. Za Node.js funkcije cold start obično traje 100-500ms, za Python 200-800ms, a za Javu može biti 1-5 sekundi ili više zbog JVM inicijalizacije. Nakon prvog izvršavanja, instanca ostaje topla netko vrijeme (obično 5-15 minuta) i sljedeći zahtjevi se izvršavaju mnogo brže jer preskacu inicijalizaciju.

Strategije za smanjenje cold start-a uključuju korištenje lakši runtime-ova (Node.js i Python su brži od Jave), minimizovanje veličine deployment paketa, koristenje provisioned concurrency (plaćate za unaprijed zagrejane instance) i izbjegavanje teških inicijalizacija u handler funkciji. AWS Lambda SnapStart za Javu i Cloudflare Workers koji koriste V8 izolate umjesto kontejnera značajno smanjuju cold start do nivoa koji je zanemarljiv za većinu aplikacija.

Use cases za serverless

Serverless arhitektura je idealna za određene tipove opterećenja dok za druge može biti skupa ili nepraktična. Razumijevanje pravog use case-a je ključno za uspješnu primjenu serverless modela u praksi.

Idealni scenariji

• API backend-i - REST ili GraphQL API-ji koji obrađuju HTTP zahtjeve
• Obrada događaja - reagovanje na upload datoteke, promjenu u bazi, poruku u redu
• Zakazani zadaci - cron poslovi koji se izvršavaju periodično
• Obrada slika i videa - resizing, kompresija, transkodiranje na zahtjev
• Chatbotovi i AI inference - obrada korisničkih poruka i pozivi ka AI modelima
• Webhooks - prijem i obrada webhook poziva od eksternih servisa
• IoT data processing - obrada podataka sa senzora i uređaja

Manje pogodni scenariji

Serverless nije optimalan za dugotrajne procese koji traju više od 15 minuta, za aplikacije koje zahtijevaju konstantnu nisku latenciju (cold start problem), za opterećenja sa konstantno visokim trafficom gdje je namjenski server jeftiniji i za aplikacije koje zahtijevaju lokalni filesystem ili dugotrajne WebSocket konekcije. U ovim slučajevima kontejneri ili tradicionalni serveri su bolji izbor.

Model naplate

Jedna od najvećih prednosti serverless modela je plaćanje po potrošnji (pay-per-use). Ne plaćate za idle vrijeme servera već samo za vrijeme kada se vaš kod aktivno izvršava. AWS Lambda naplaćuje po broju zahtjeva (0.20 dolara za milion zahtijeva) i po trajanju izvršavanja mjerenom u GB-sekundama (koliko memorije funkcija koristi pomnozeno sa trajanjem izvršavanja u sekundama).

Poređenje troškova

Za mali sajt ili API sa 100.000 zahtjeva mjesečno gdje svaki zahtjev traje 200ms sa 256MB memorije, mjesečni trošak na AWS Lambda bi bio ispod jednog dolara. Ekvivalentni EC2 server t3.micro košta oko 8.50 dolara mjesečno čak i kada veći dio vremena ne radi ništa. Za ovaj tip opterećenja serverless je drastično jeftiniji.

Međutim, kalkulacija se mijenja pri velikom obimu. Za aplikaciju sa 100 miliona zahtijeva mjesečno, serverless troškovi mogu preci 200 dolara mjesečno dok bi namjenski server sa sličnim kapacitetom kostao manje. Takozvani serverless cost cliff nastaje kada opterećenje prijeđe određeni prag gdje konstantno zakupljen server postaje isplativiji. Za svaku aplikaciju je važno napraviti cost analizu za očekivano opterećenje prije izbora modela.

Prednosti serverless arhitekture

• Nema upravljanja infrastrukturom - ne brinete o serverima, patchevima, skaliranju
• Automatsko skaliranje - od nula do milion zahtijeva bez ikakve konfiguracije
• Pay-per-use - plaćate samo za izvršavanje, ne za idle vrijeme
• Brži razvoj - fokus na kod umjesto na infrastrukturu ubrzava isporuku
• Visoka dostupnost - cloud pružatelj garantuje dostupnost bez vašeg angazovanja
• Skaliranje do nule - nema troškova kada nema prometa

Mane i izazovi

Serverless arhitektura donosi i specifične izazove. Vendor lock-in je realan jer svaki pružatelj ima specifične API-je, servise i alate koji otezavaju migraciju na drugog pružatelja. Cold start latencija može biti problematična za aplikacije koje zahtijevaju konzistentno brz odziv. Debugging i monitoring su kompleksniji jer se funkcije izvršavaju u efemernim okruženjima bez pristupa tradicionalnim alatima za dijagnostiku.

Lokalni razvoj i testiranje također predstavljaju izazov jer je teško replicirati cloud okruženje lokalno. Alati kao što su AWS SAM, Serverless Framework i LocalStack pomazu ali ne mogu u potpunosti simulirati ponašanje u produkciji. Limiti na veličinu deployment paketa, vrijeme izvršavanja i memoriju mogu zahtijevati refaktorisanje postojećih aplikacija. Konačno, za timove koji nemaju iskustvo sa cloud servisima, krivulja učenja može biti strma.