Co je serverless a FaaS

Co je serverless computing

Serverless computing je model cloud computingu, kde poskytovatel cloudu automaticky spravuje infrastrukturu. Na rozdíl od klasického webhostingu se za vás stará o škálování a přidělování zdrojů. Navzdory názvu servery stále existují, ale vy o nich nepřemýšlíte ani je nekonfigurujete. Napíšete kód, nasadíte ho a poskytovatel cloudu se postará o všechno ostatní včetně operačního systému, běhového prostředí, škálování a vysoké dostupnosti. Platíte pouze za dobu běhu kódu, ne za dobu, kdy server čeká na požadavky.

Serverless je evolucí od fyzických serverů přes virtuální stroje a kontejnery až k zcela abstrahovanému výpočetnímu modelu. Každý krok této evoluce sundává z vývojáře jednu vrstvu odpovědnosti a přenáší ji na poskytovatele cloudu. V serverless modelu se vývojář soustředí výhradně na business logiku, zatímco poskytovatel cloudu se stará o vše ostatní, což dramaticky zrychluje vývoj a u mnoha typů aplikací snižuje provozní náklady.

Functions as a Service (FaaS)

FaaS je nejznámější forma serverless computingu. V modelu FaaS píšete malé, samostatné funkce, které se spouštějí jako reakce na události. Každá funkce má jednu jasně definovanou odpovědnost, přijímá vstupní data, vykoná logiku a vrátí výsledek. Poskytovatel cloudu automaticky vytvoří instanci pro běh funkce, spustí ji a po dokončení instanci vypne. Pokud přijde 1000 současných požadavků, poskytovatel automaticky vytvoří 1000 instancí.

Hlavní poskytovatelé FaaS

• AWS Lambda - první a nejvyzrálejší FaaS služba, spuštěná v roce 2014
• Google Cloud Functions - FaaS od Googlu s dobrou integrací na Firebase
• Azure Functions - FaaS od Microsoftu s vynikající podporou .NET
• Cloudflare Workers - edge computing s globální distribucí a izolací přes V8
• Vercel Functions - optimalizované pro Next.js a frontendové frameworky
• Netlify Functions - jednoduché pro Jamstack weby

Každý poskytovatel má specifika ohledně podporovaných programovacích jazyků, maximální doby běhu, limitů paměti a způsobu spouštění. Pro klasičtější přístup zvažte službu cloud hostingu. AWS Lambda podporuje Node.js, Python, Java, Go, .NET a Ruby s maximální dobou běhu 15 minut a až 10 GB paměti. Cloudflare Workers používají běhové prostředí V8 s limitem 50 ms CPU času (na free tarifu), ale s extrémně nízkou latencí, protože běží na edge lokacích.

Jak fungují serverless funkce

Když nějaká událost spustí serverless funkci, projde poskytovatel cloudu několika kroky. Nejprve zkontroluje, zda existuje teplá instance, která je již inicializovaná a připravená ke spuštění. Pokud ne, vytvoří se nová instance, čemuž se říká cold start. Cold start zahrnuje spuštění kontejneru, načtení běhového prostředí, načtení vašeho kódu a vykonání inicializační logiky. Poté se spustí handler funkce s daty z události.

Problém cold startu

Cold start je nejčastějším zdrojem latence v serverless architektuře. U funkcí v Node.js trvá cold start obvykle 100-500 ms, u Pythonu 200-800 ms a u Javy to může být 1-5 sekund i více kvůli inicializaci JVM. Po prvním spuštění zůstává instance po nějakou dobu teplá (obvykle 5-15 minut) a následující požadavky se vykonají mnohem rychleji, protože přeskočí inicializaci.

Strategie pro snížení cold startu zahrnují použití odlehčených běhových prostředí (Node.js a Python jsou rychlejší než Java), minimalizaci velikosti deployment balíčku, použití provisioned concurrency (placení za předehřáté instance) a vyhnutí se náročné inicializaci v handler funkci. AWS Lambda SnapStart pro Javu a Cloudflare Workers používající V8 izoláty místo kontejnerů výrazně snižují cold start na úroveň, která je pro většinu aplikací zanedbatelná.

Případy užití serverless

Serverless architektura je ideální pro určité typy zátěže, zatímco pro jiné může být drahá nebo nepraktická. Pochopení správného případu užití je klíčem k úspěšnému nasazení serverless modelu v praxi.

Ideální scénáře

• API backendy - REST nebo GraphQL API zpracovávající HTTP požadavky
• Zpracování událostí - reakce na nahrání souboru, změnu v databázi, zprávu ve frontě
• Naplánované úlohy - cron joby spouštějící se periodicky
• Zpracování obrázků a videa - změna velikosti, komprese, transkódování na vyžádání
• Chatboti a AI inference - zpracování zpráv uživatelů a volání AI modelů
• Webhooky - příjem a zpracování webhook volání z externích služeb
• Zpracování IoT dat - zpracování dat ze senzorů a zařízení

Méně vhodné scénáře

Serverless není optimální pro dlouho běžící procesy trvající déle než 15 minut, pro aplikace vyžadující stálou nízkou latenci (problém cold startu), pro zátěž s neustále vysokým provozem, kde je dedikovaný server levnější, a pro aplikace vyžadující lokální souborový systém nebo dlouhotrvající WebSocket spojení. V těchto případech jsou lepší volbou kontejnery nebo tradiční servery.

Cenový model

Jednou z největších výhod serverless modelu je platba za skutečné využití. Neplatíte za nečinnost serveru, ale pouze za dobu, kdy se váš kód aktivně vykonává. AWS Lambda účtuje podle počtu požadavků (0,17 Kč za milion požadavků) a podle délky běhu měřené v GB-sekundách (kolik paměti funkce používá vynásobeno délkou běhu v sekundách).

Porovnání nákladů

U malého webu nebo API se 100 000 požadavky měsíčně, kde každý požadavek trvá 200 ms s 256 MB paměti, by měsíční náklady na AWS Lambda byly pod 25 Kč. Ekvivalentní EC2 server t3.micro stojí kolem 170 Kč měsíčně, i když většinu času nic nedělá. U tohoto typu zátěže je serverless drasticky levnější.

Výpočet se ovšem mění při velkém měřítku. U aplikace se 100 miliony požadavků měsíčně mohou náklady na serverless přesáhnout 4 000 Kč měsíčně, zatímco dedikovaný server s podobnou kapacitou by stál méně. Takzvaný serverless cost cliff nastává, když zátěž překročí určitý práh, kde se neustále pronajatý server stává nákladově efektivnějším. U každé aplikace je důležité udělat analýzu nákladů pro očekávanou zátěž ještě před volbou modelu.

Výhody serverless architektury

• Žádná správa infrastruktury - nestaráte se o servery, záplaty, škálování
• Automatické škálování - od nuly k milionu požadavků bez jakékoli konfigurace
• Platba za využití - platíte pouze za běh, ne za nečinnost
• Rychlejší vývoj - zaměření na kód místo infrastruktury zrychluje dodávku
• Vysoká dostupnost - poskytovatel cloudu garantuje dostupnost bez vašeho přičinění
• Škálování na nulu - žádné náklady, když není provoz

Nevýhody a výzvy

Serverless architektura přináší i specifické výzvy. Vendor lock-in je reálný, protože každý poskytovatel má specifická API, služby a nástroje, které ztěžují migraci k jinému poskytovateli. Latence cold startu může být problematická u aplikací vyžadujících konzistentně rychlou odezvu. Ladění a monitoring jsou složitější, protože funkce běží v efemérních prostředích bez přístupu k tradičním diagnostickým nástrojům.

Lokální vývoj a testování rovněž představují výzvu, protože je obtížné replikovat cloudové prostředí lokálně. Nástroje jako AWS SAM, Serverless Framework a LocalStack pomáhají, ale nedokážou plně nasimulovat produkční chování. Limity na velikost deployment balíčku, dobu běhu a paměť mohou vyžadovat refaktoring stávajících aplikací. A nakonec, pro týmy bez zkušeností s cloudovými službami může být křivka učení strmá.