Šta je serverless i FaaS

Šta je serverless computing

Serverless computing je model oblak računarstva gdje cloud provajder 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 provajder 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 provajdera. Kod serverless modela developer se fokusira isključivo na poslovnu logiku dok se cloud provajder 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 provajder automatski kreira instancu za izvršavanje funkcije, izvršava je i gasi instancu kada zavrsi. Ako pristigne 1000 istovremenih zahtijeva, provajder automatski kreira 1000 instanci.

Glavni FaaS provajderi

• 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 provajder 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 provajder 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 neko vrijeme (obično 5-15 minuta) i sljedeći zahtevi 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. Razumevanje pravog use case-a je ključno za uspeš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 namenski 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 zahtijeva (0.20 dolara za milion zahtijeva) i po trajanju izvršavanja merenom 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 zahtijeva 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 menja pri velikom obimu. Za aplikaciju sa 100 miliona zahtijeva mjesečno, serverless troškovi mogu preci 200 dolara mjesečno dok bi namenski server sa sličnim kapacitetom kostao manje. Takozvani serverless cost cliff nastaje kada opterećenje pređ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 provajder garantuje dostupnost bez vašeg angazovanja
• Skaliranje do nule - nema troškova kada nema saobraćaja

Mane i izazovi

Serverless arhitektura donosi i specifične izazove. Vendor lock-in je realan jer svaki provajder ima specifične API-je, servise i alate koji otezavaju migraciju na drugog provajdera. 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đe 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.