Š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 konfigurišete. 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 čeka na zahteve.

Serverless je evolucija od fizičkih servera, preko virtualnih mašina 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 završi. 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 ograničenjem 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šć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 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 zahteve
• Obrada događaja - reagovanje na upload fajla, promjenu u bazi, poruku u redu
• Zakazani zadaci - cron poslovi koji se izvršavaju 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 gdje je namjenski 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 vrijeme servera već samo za vrijeme kada se vaš kod aktivno izvršava. AWS Lambda naplaćuje po broju zahteva (0.20 dolara za milion zahteva) 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 zahteva mesečno gdje 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 preći 200 dolara mesečno dok bi namjenski 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 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 vrijeme
• Brži razvoj - fokus na kod umjesto na infrastrukturu ubrzava isporuku
• Visoka dostupnost - cloud provajder garantuje dostupnost bez vašeg angažovanja
• 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 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 pomažu ali ne mogu u potpunosti simulirati ponašanje u produkciji. Limiti na veličinu deployment paketa, vrijeme 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.