Šta je serverless i FaaS

Šta je serverless computing

Serverless computing je model oblak računarstva gde cloud provajder automatski upravlja infrastrukturom. Za razliku od klasičnog web hostinga, skaliranjem i alokacijom resursa umesto 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 vreme izvršavanja vašeg koda, ne za vreme kada server ceka na zahteve.

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 izvrsavaju kao odgovor na događaje (events). Svaka funkcija ima jednu jasno definisanu odgovornost, prima ulazne podatke, izvrsava logiku i vraća rezultat. Cloud provajder automatski kreira instancu za izvršavanje funkcije, izvrsava je i gasi instancu kada zavrsi. Ako pristigne 1000 istovremenih zahteva, 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 - optimizovano 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 izvrsavaju na edge lokacijama.

Kako serverless funkcije rade

Kada događaj pokrene serverless funkciju, cloud provajder prolazi kroz nekoliko koraka. Prvo proverava 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 izvrsava 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 vreme (obično 5-15 minuta) i sledeći zahtevi se izvrsavaju mnogo brže jer preskacu inicijalizaciju.

Strategije za smanjenje cold start-a uključuju korišćenje lakši runtime-ova (Node.js i Python su brži od Jave), minimizovanje veličine deployment paketa, koristenje provisioned concurrency (plaćate za unapred zagrejane instance) i izbegavanje teških inicijalizacija u handler funkciji. AWS Lambda SnapStart za Javu i Cloudflare Workers koji koriste V8 izolate umesto 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 primenu serverless modela u praksi.

Idealni scenariji

• API backend-i - REST ili GraphQL API-ji koji obrađuju HTTP zahteve
• Obrada događaja - reagovanje na upload fajla, promenu u bazi, poruku u redu
• Zakazani zadaci - cron poslovi koji se izvrsavaju periodično
• Obrada slika i videa - resizing, kompresija, transkodiranje na zahtev
• 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 zahtevaju konstantnu nisku latenciju (cold start problem), za opterećenja sa konstantno visokim trafficom gde je namenski server jeftiniji i za aplikacije koje zahtevaju 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 vreme servera već samo za vreme kada se vaš kod aktivno izvrsava. AWS Lambda naplaćuje po broju zahteva (0.20 dolara za milion zahteva) 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 zahteva mesečno gde svaki zahtev traje 200ms sa 256MB memorije, mesečni trošak na AWS Lambda bi bio ispod jednog dolara. Ekvivalentni EC2 server t3.micro košta oko 8.50 dolara mesečno čak i kada veći deo 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 zahteva mesečno, serverless troškovi mogu preci 200 dolara mesečno dok bi namenski server sa sličnim kapacitetom kostao manje. Takozvani serverless cost cliff nastaje kada opterećenje pređe određeni prag gde konstantno zakupljen server postaje isplativiji. Za svaku aplikaciju je važno napraviti cost analizu za očekivano opterećenje pre izbora modela.

Prednosti serverless arhitekture

• Nema upravljanja infrastrukturom - ne brinete o serverima, patchevima, skaliranju
• Automatsko skaliranje - od nula do milion zahteva bez ikakve konfiguracije
• Pay-per-use - plaćate samo za izvršavanje, ne za idle vreme
• Brži razvoj - fokus na kod umesto 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 zahtevaju konzistentno brz odziv. Debugging i monitoring su kompleksniji jer se funkcije izvrsavaju 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, vreme izvršavanja i memoriju mogu zahtevati refaktorisanje postojećih aplikacija. Konačno, za timove koji nemaju iskustvo sa cloud servisima, krivulja učenja može biti strma.