Serverless architektura: Kdy se vyplatí a kdy ne

Serverless je jedním z těch termínů, které v posledních letech pronikly do každé druhé technické prezentace a každého třetího článku o moderním vývoji. Marketingová oddělení cloudových poskytovatelů ho prezentují jako revoluci, která odstraní všechny problémy s infrastrukturou. Realita je podstatně nuancovanější. Serverless architektura je mocný nástroj, ale jako každý nástroj má své ideální použití -- a situace, kdy způsobí víc problémů, než vyřeší.

Co serverless skutečně znamená

Název "serverless" je trochu zavádějící -- servery samozřejmě existují, jen se o ně nestaráte vy. Místo provozování vlastního serveru (nebo virtuálního stroje v cloudu) napíšete funkci, nahrajete ji poskytovateli a ten se postará o vše ostatní: provisioning, škálování, monitoring, aktualizace operačního systému.

Tři hlavní platformy, se kterými se v praxi setkáte nejčastěji:

AWS Lambda je průkopník a stále nejrozšířenější serverless platforma. Podporuje Python, Node.js, Java, Go a další jazyky. Integruje se s desítkami dalších AWS služeb, což je současně výhoda i nevýhoda -- více o tom později.

Vercel a Netlify Functions přinášejí serverless blíž k frontendovým vývojářům. Pokud stavíte aplikaci v Next.js nebo podobném frameworku, serverless funkce jsou přirozenou součástí deploymentu. Konfigurace je minimální a developer experience vynikající.

Cloudflare Workers nabízejí unikátní přístup -- funkce běží na edge, tedy co nejblíž koncovému uživateli. To znamená extrémně nízkou latenci, ale také specifická omezení (V8 isolates místo plnohodnotného Node.js, limit na CPU čas).

Vedle těchto hlavních hráčů existují i Google Cloud Functions, Azure Functions a řada menších platforem. Princip je ale všude stejný: platíte za skutečné využití, ne za rezervovaný výkon.

Skutečná analýza nákladů

Nejčastějším argumentem pro serverless je cena. "Platíte jen za to, co skutečně používáte." To zní skvěle, ale vyžaduje to kontext.

Kdy serverless skutečně ušetří. Pokud máte API, které obsluhuje 10 000 requestů denně s průměrnou dobou běhu 200 ms, na AWS Lambda zaplatíte řádově jednotky dolarů měsíčně. Ekvivalentní EC2 instance by stála 15-50 dolarů, i ta nejmenší. U sporadic workloadů -- aplikací, které mají výrazné špičky a dlouhá období nečinnosti -- jsou úspory ještě dramatičtější. Interní nástroj, který se používá jen v pracovní dobu, nebo sezónní e-shop s Black Friday špičkou jsou ideální kandidáti.

Kdy serverless překvapí cenou. Problém nastává při konstantním zatížení. Pokud vaše API obsluhuje miliony requestů denně rovnoměrně 24/7, serverless vyjde dráž než dedikovaný server nebo reserved instance v cloudu. AWS Lambda účtuje přibližně 0,20 dolaru za milion requestů plus čas výpočtu. Při vysokém a stabilním zatížení se tato mikro-platba sčítá rychleji, než byste čekali.

Důležité je počítat celkové náklady. Samotná Lambda funkce je levná, ale přidejte API Gateway (3,50 dolaru za milion requestů), CloudWatch logy, případně NAT Gateway pro přístup do VPC (32 dolarů měsíčně jen za existenci) a celkový účet vypadá úplně jinak. Viděli jsme projekty, kde samotné Lambda funkce stály 20 dolarů měsíčně, ale podpůrná infrastruktura kolem nich 200 dolarů.

Problém cold startů

Cold start je prodleva při prvním spuštění funkce, když platforma potřebuje alokovat prostředky a inicializovat runtime. U Node.js a Pythonu mluvíme typicky o 100-500 ms. U Javy nebo .NET to může být 1-5 sekund, někdy i víc.

Pro většinu API endpointů je cold start 200 ms akceptovatelný -- uživatel si ho nevšimne. Problém nastává ve třech scénářích.

Za prvé, řetězení funkcí. Pokud jeden request vyvolá postupně tři Lambda funkce a každá má cold start, uživatel čeká 600 ms navíc. U mikroservisní architektury s desítkami funkcí se to rychle sčítá.

Za druhé, sporadický provoz. Paradoxně právě ten use case, kde serverless nejvíc ušetří na nákladech, trpí cold starty nejvíc. Pokud funkce dostane request jednou za 15 minut, téměř každý request bude cold start.

Za třetí, real-time aplikace. Chatboty, live dashboardy nebo herní servery potřebují konzistentní odezvu. Cold start, který přijde jednou za čas, zhorší uživatelský zážitek víc než konstantně o 50 ms pomalejší, ale předvídatelná odezva.

Existují řešení: provisioned concurrency na AWS (ale platíte za rezervovanou kapacitu, čímž ztrácíte hlavní výhodu serverless), zahřívací pingy (nespolehlivé a nepraktické) nebo přechod na edge runtime jako Cloudflare Workers, kde jsou cold starty pod 5 ms.

Riziko vendor lock-inu

Tohle je téma, které se v marketingových materiálech cloudových poskytovatelů překvapivě neobjevuje. Když napíšete Lambda funkci, která používá DynamoDB pro data, SQS pro fronty, S3 pro soubory a SNS pro notifikace, nejste vázáni jen na AWS Lambda. Jste vázáni na celý AWS ekosystém.

Migrace takové aplikace na Google Cloud nebo Azure není přepsání jedné funkce. Je to přepsání celé datové vrstvy, komunikační vrstvy a často i autentizace. V praxi to znamená měsíce práce a riziko nových bugů.

Jak minimalizovat lock-in. Oddělte business logiku od infrastrukturního kódu. Vaše doménová logika by neměla vědět, jestli běží na Lambdě nebo na klasickém Express serveru. Používejte adaptérový vzor pro přístup k databázi a dalším službám. A pokud je to možné, preferujte otevřené standardy (PostgreSQL místo DynamoDB, Redis místo ElastiCache).

Realita ale je, že určitá míra lock-inu je nevyhnutelná a často akceptovatelná. Pokud AWS Lambda řeší váš problém a nemáte realistický důvod migrovat, optimalizace pro přenositelnost může být zbytečná investice.

Kde serverless skutečně exceluje

Existují use casy, pro které je serverless jako dělaný.

Event-driven zpracování. Uživatel nahraje obrázek, Lambda ho zmenší a uloží thumbnaily. Přijde objednávka, funkce odešle potvrzovací email a aktualizuje sklad. Webhook z platební brány spustí zpracování platby. Tyto jednorázové, na událost reagující operace jsou ideální serverless kandidáti -- krátké, izolované a s nepředvídatelnou frekvencí.

API pro mobilní a webové aplikace. REST nebo GraphQL API, které obsluhuje CRUD operace, je klasický serverless use case. Zvlášť pokud je provoz nepravidelný (více ve špičkách, méně v noci) a jednotlivé endpointy jsou relativně jednoduché.

Plánované úlohy a cron joby. Místo serveru, který 23 hodin a 55 minut denně nic nedělá a jednou za hodinu spustí synchronizaci dat, použijte scheduled Lambda funkci. Platíte jen za těch pár sekund skutečného běhu.

Prototypování a MVP. Když potřebujete rychle ověřit nápad, serverless vám ušetří čas na konfiguraci infrastruktury. Deploynete funkci, připojíte databázi a máte fungující backend za odpoledne. Pokud se projekt rozroste, můžete později migrovat na tradičnější architekturu.

Kde serverless není dobrá volba

Stejně důležité je vědět, kdy serverless nepoužít.

Dlouho běžící procesy. AWS Lambda má maximální timeout 15 minut. Cloudflare Workers mají limit na CPU čas 30 sekund (50 ms na free plánu). Pokud potřebujete zpracovat velký dataset, provést komplexní výpočet nebo udržovat dlouhodobé připojení (WebSockets), serverless není ten správný nástroj.

Náročné výpočty. Machine learning inference, zpracování videa, kompilace kódu -- operace, které potřebují hodně CPU nebo GPU, jsou na serverless drahé a pomalé. Dedikovaná GPU instance na AWS stojí zlomek toho, co byste zaplatili za ekvivalentní výpočetní čas na Lambdě.

Stavové aplikace. Serverless funkce jsou bezstavové. Každé volání začíná s čistým štítem. Pokud vaše aplikace potřebuje udržovat stav mezi requesty (session data, cache v paměti, persistent connections), musíte ho externalizovat do databáze nebo cache služby. To přidává latenci a komplexitu.

Komplexní transakční systémy. Bankovní systémy, rezervační platformy nebo jakákoli aplikace, kde potřebujete distribuované transakce přes více služeb, jsou s serverless náročné na správnou implementaci. Není to nemožné, ale orchestrace přes Step Functions nebo Saga pattern přidává vrstvy složitosti.

Hybridní přístup jako pragmatické řešení

V praxi nejlépe funguje kombinace. Jádro aplikace -- hlavní API s konstantním provozem -- běží na tradičním serveru nebo v kontejneru. Serverless funkce pak obsluhují okrajové úlohy: zpracování webhooků, generování reportů, odesílání emailů, resize obrázků.

Tento hybridní přístup kombinuje předvídatelné náklady a výkon tradičního hostingu s elasticitou a jednoduchostí serverless pro úlohy, kde to dává smysl. Není to tak elegantní jako "vše je serverless", ale je to pragmatické a v produkci funguje spolehlivě.

Další variantou je kontejnerový serverless (AWS Fargate, Google Cloud Run). Získáte výhody serverless modelu (platíte za využití, automatické škálování) bez omezení klasických funkcí (delší běh, plný runtime, stavovost). Je to kompromis, který stojí za zvážení.

Kdy zůstat u tradičního hostingu

Někdy je nejlepší volba ta nejjednodušší. VPS za 10-20 dolarů měsíčně s Nginx, vaší aplikací a PostgreSQL databází je řešení, které funguje pro ohromné množství projektů. Je předvídatelné, snadno debugovatelné, nemá cold starty a nejste závislí na konkrétním cloud poskytovateli.

Pokud máte malý tým, předvídatelný provoz a aplikaci, která nepotřebuje škálovat na tisíce instancí, klasický server nebo managed hosting je legitimní a často lepší volba než serverless.

Závěr

Serverless architektura není budoucnost veškerého backendu. Je to specifický nástroj pro specifické problémy. Exceluje u event-driven zpracování, nepravidelného provozu a rychlého prototypování. Selhává u dlouho běžících procesů, konstantně zatížených systémů a komplexních stavových aplikací.

Rozhodování mezi serverless a tradičním hostingem by nikdy nemělo vycházet z toho, co je zrovna trendy. Mělo by vycházet z analýzy vašeho konkrétního projektu -- jaký máte provozní profil, jaké máte nároky na latenci, jak velký je váš tým a jaký máte rozpočet. Správně zvolená architektura vám ušetří tisíce dolarů ročně a desítky hodin práce měsíčně. Špatně zvolená vám přidá problémy, které jste předtím neměli.