A serverless legnagyobb tévedése: hogy egyetlen döntésnek hisszük

Ez a harmadik írásom egy lazán összefüggő sorozatban, és mielőtt a serverlessre térnék, érdemes hátralépni egyet.

Amikor egy új fejlesztésbe kezdünk, ritkán vesszük észre, hogy néhány perc alatt eldöntünk három olyan dolgot, ami évekre meghatározza a rendszer sorsát. És a legtöbbször nem is döntünk, hanem azt választjuk, amit megszoktunk. A sorozatom erről szól: melyik az a megszokott választás, amit érdemes kimondva végiggondolni, mielőtt automatikusan ránk ragad.

Írtam már a modularis monolitról, mikor és hol érdemes megfontolni a használatát. Arról, hogy a legtöbb rendszernek nem kellett volna szétrobbannia mikroszolgáltatások rajává; a jól felépített monolit a legtöbb csapatnak gyorsabb, olcsóbb és könnyebben üzemeltethető, a szétszedésre akkor kerüljön sor, amikor egy konkrét skálázási vagy szervezeti kényszer valóban megköveteli.

A második cikkemben a NoSQL és az SQL kapcsolatáról írtam néhány gondolatot. Az, hogy a NoSQL a legtöbb csapatnál nem skálázási döntés volt, hanem menekülés a sématervezés elől és hogy 2026-ban a kézenfekvő választás a relációs adatbázis, amíg egy mért korlát mást nem indokol.

Mindkét írásnak ugyanaz volt a lényege: az iparág hajlamos divatból dönteni, a számlát pedig évekkel később, drágán fizeti ki. Kezdd azzal a megoldással, ami egyszerű és bevált és csak akkor válassz bonyolultabbat, ha számokkal meg tudod indokolni, miért éri meg.

Most jön a lánc harmadik szeme, ami az architektúra döntésből egyenesen következik: ha eldöntötted, hogy a rendszered modularis monolit vagy microservice szolgáltatás, a következő kérdés, hogy min fut, milyen compute modellen. És itt jön be a serverless.

A serverless nem egy termék, hanem egy “spektrum”

Van egy mondat, amit az elmúlt évtizedben nagyjából minden második architektúra-review-n hallottam: “ezt csináljuk serverlessben, akkor nem kell semmit üzemeltetni.” Kényelmes mondat. A gond nem azzal van, amit állít, hanem azzal, amit elhallgat: a serverless nem egyetlen kapcsoló, amire igent vagy nemet mondasz. Egy egész spektrum, aminek a két végén nagyon más gazdaságosság és nagyon más függőség áll. A jó hír, hogy ma ezt a teljes spektrumot végig lehet játszani egyetlen felhőn belül is.

A nagy ígéret, ami sok mindenben be is jött

2014 novemberében az AWS bejelentette a Lambdát: futtass kódot események hatására, szerver kiépítése és menedzselése nélkül, és csak a tényleges futásidőért fizess. Az üzenet pontosan arra a fájdalompontra tapintott rá, amit minden ops-csapat ismert: a kapacitástervezésre, a patchelésre, a hajnali telefonra egy elfogyott diszk miatt. Jeff Bezos ezt “undifferentiated heavy lifting”-nek hívta, az a munka, ami nem ad üzleti értéket, csak el kell végezni.

És sok mindenben be is váltotta. Egy eseményvezérelt integráció, egy ritkán futó batch job, egy webhook feldolgozó, ezekre a Lambda közel ideális. Nulla forgalomnál nulla költség, spike-nál automatikus skálázás, patchelni sincs mit. Ahol illik a profilhoz, ott a Lambda az egyik legjobb ár-érték döntés, amit ma meg lehet hozni. Az AWS a tizedik születésnapon maga fogalmazta meg a víziót: “olyan jövő, ahol minden kód, amit írsz, tiszta üzleti logika”. Elegáns cél. A mérnöki érettség viszont abban van, hogy tudjuk: nem minden workload tiszta üzleti logika.

Ahol a modell határaihoz érünk, tények, nem vádak

Két olyan tulajdonsága van a függvény-alapú (FaaS) modellnek, amit érdemes józanul beárazni, mert a szolgáltató sem titkolja őket.

Az első a cold start. Amikor egy függvényt egy ideje nem hívtak, vagy új példányt kell felhúzni, a futtatókörnyezet nulláról indul el, és ez a késleltetés a felhasználó számára érzékelhető. Ezt maga az AWS dokumentálja, és külön eszközt (Provisioned Concurrency-t) ad rá, hogy a lambda példányok cold start nélkül induljanak, persze megfelelő összegért. Ez nem hiba, a modell természetes következménye, amivel tervezni kell.

A második a költséggörbe alakja. A per-millisecond árazás alacsony és hullámzó forgalomnál verhetetlen. Állandó, magas terhelésen viszont a fajlagos ár átfordul, és egy tisztességesen kihasznált konténer vagy instance olcsóbb lehet. A szakma legismertebb esettanulmánya épp erről szól és pont azért hiteles, mert nem egy AWS-kritikustól, hanem az Amazon saját csapatától jött:

A Prime Video-tanulság: itt ér össze a monolit és a serverless

2023-ban a Prime Video mérnökei megírták, hogy az audió/videó minőségellenőrző szolgáltatásukat elosztott, serverless (Lambda + Step Functions) architektúráról átvitték egy monolitikus alkalmazásba EC2-re és ECS-re, és ezzel több mint 90%-kal csökkentették az üzemeltetési költséget:

• Elérhető cikk: prime-ec2-ecs-saves-costs,
• Eredeti, archivált cikk: scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90.

Ez a történet pontosan a sorozat két korábbi darabját köti össze. Az első írásom arról szólt, hogy a monolit gyakran a jobb választás és itt egy Amazon-csapat pont ezt tapasztalta meg: a szolgáltatásokat microservice architektúrából visszamigrálták monolitba. De vegyük észre, hogy ez egyszerre volt architektúra és compute döntés: nemcsak egybeköltöztették a komponenseket, hanem a compute modellt is arrébb tolták a spektrumon, Lambdáról EC2/ECS-re. A tanulság nem az, hogy „a serverless zsákutca”. Épp ellenkezőleg: ez a történet az AWS ökoszisztéma szélességéről szól. Ugyanaz a csapat, ugyanazon a felhőn belül, egyetlen döntéssel váltott compute modellt, amikor a workload profilja ezt indokolta nem kellett kilépnie a felhőből, nem kellett újraírnia mindent egy másik szolgáltatóra. Csak arrébb csúszott a spektrumon.

A spektrum, amit sokan kihagynak: EKS + a CNCF serverless-réteg

Itt jön az a rész, amiről a „Lambda vagy semmi” viták rendre megfeledkeznek. A serverless-nek az AWS-en belül is több szintje van, és ezek pont a fenti két korlátra adnak választ, miközben a portabilitást is javítják.

• AWS Fargate: serverless a konténereknek. Se node-ot, se klasztert nem kell provisionálnod; deklarálsz egy podot vagy taskot, megadod a CPU-t és memóriát, és a többit az AWS intézi, use-alapú árazással. Fontos, hogy a Fargate nemcsak ECS-sel, hanem EKS-sel is működik: natív Kubernetes-podokat ütemez láthatatlan infrastruktúrára. Vagyis megkapod a „ne üzemeltess szervert” élményt, de konténer és Kubernetes-alapon, ami sokkal hordozhatóbb, mint egy tisztán Lambda-natív architektúra. Egy modularis monolit egyébként pont ide illik: egyetlen egybefüggő alkalmazás, konténerben, serverless futtatással.

Erre a Kubernetes-alapra ülnek rá a CNCF serverless eszközök, amiket az AWS a saját blogjában és megoldásaiban maga ajánl EKS-en:

• KEDA (Kubernetes Event-Driven Autoscaling) — CNCF graduated projekt 2023 augusztusa óta. Event-forrás alapú skálázást ad, beleértve a scale-to-zerót, vagyis a Lambda „nulla forgalom = nulla költség” logikáját hozza el Kubernetesre. Az AWS saját containers-blogja mutatja be KEDA + Karpenter párosban EKS-en, költséghatékony eseményvezérelt workloadokra.

• Knative — a request-alapú, scale-to-zero serverless élményt adja konténerekre, bármely Kubernetes-klaszteren. A dokumentációja nyíltan a hordozhatóságot pozicionálja: „bármely Kubernetes-klaszteren fut, portabilitást adva a felhőszolgáltatók és az on-prem között”.

A CNCF egész sor ilyen projektet termelt ki igy például OpenFaaS, Knative, OpenWhisk, KEDA a teljesség igénye nélkül, amelyek konténerekre építve adják a serverless fejlesztői élményt anélkül, hogy egyetlen szolgáltatói API-hoz láncolnának. A lényeg: ezt a réteget nyugodtan futtathatod EKS-en. Így az AWS elért skáláját, hálózatát és menedzselt kontrollsíkját kombinálod egy hordozható, nyílt szabvány köré épített alkalmazásréteggel.

A lock-in mint tervezési döntés, nem végzet

A vendor lock-in a serverlessnél valós, de nem misztikus erő, architekturális döntések összege. Egy tisztán Lambda + DynamoDB + Step Functions + EventBridge stack a legszorosabb kötés, amit köthetsz; egy EKS + Fargate + Knative/KEDA stack ugyanazt az élményt adja lényegesen lazább csomóval. Egyik sem eleve jó vagy rossz, az a kérdés, hogy tudatosan hol húzod meg a határt aközött, amit a sebességért cserébe hajlandó vagy a szolgáltatódra bízni, és amit szándékosan hordozhatóan tartasz.

Érdemes hozzátenni: a hordozhatóságnak ára van. A CNCF-réteg üzemeltetése nem ingyen van, Kubernetes-kompetenciát és karbantartást igényel. Néha épp az a helyes döntés, hogy vállalod a Lambda-natív kötést a fejlesztési sebességért. A lényeg, hogy ez tudatos döntés legyen, ne megszokás.

A harmadik döntés és a sorozat közös tanulsága

A serverless nem hype/lufi, és nem is a jövő egyetlen igaz útja. A tíz év tanulsága prózaibb, és pont ezért használható: a serverless egy spektrum, és a jó döntés nem egy pontot választ rajta örökre, hanem workloadonként a megfelelőt.

• Alacsony vagy erősen hullámzó, eseményvezérelt, jól körülhatárolt feladat, ahol a fejlesztési sebesség a legfőbb érték - Lambda.
• Konténerizált szolgáltatás vagy modularis monolit, ahol nem akarsz node-okat üzemeltetni, de hordozhatóbb alapot szeretnél - Fargate (ECS vagy EKS).
• Állandó/magas terhelés, késleltetés-érzékenység, vagy tudatos portabilitási igény -EKS + a CNCF serverless-réteg (KEDA, Knative, Karpenter, stb.), ahol a serverless élményt és a scale-to-zerót nyílt szabványokon kapod meg, az AWS skáláján futtatva.

És most álljon össze a három írás egyetlen ellenőrzőlistává. Amikor új fejlesztésbe kezdesz, mielőtt bármit kódolnál, tedd fel ezt a három kérdést ebben a sorrendben:

1. Architektúra típusa: meg tudod-e indokolni, miért nem egy jól felépített monolit? Ha nem, kezdd monolittal, és szedd szét később, ha egy mért kényszer valóban megköveteli.
2. Adatréteg: meg tudod-e indokolni számokkal, miért nem relációs adatbázis? Ha nem, a válasz a Postgres.
3. Compute modell: ismered-e a workload terhelésprofilját annyira, hogy tudatosan válassz a serverless spektrumon Lambda, Fargate és EKS + CNCF között? Ha nem, előbb mérd meg, aztán válassz.

Mindhárom kérdésben ugyanaz a minta tér vissza: kezdd az egyszerű, bevált megoldással, és csak mért indokkal térj el tőle, soha ne pusztán divatból.

A serverless legnagyobb erénye sosem az volt, hogy „nincs szerver”. Hanem az, hogy végre a workloadhoz igazíthatod a compute modellt, nem fordítva. A tudás abban van, hogy tudod, mikor melyiket vedd le a polcról és hogy ezt tudatos döntésnek tekinted, ne megszokásnak.

Kérdés merült fel benned? Írj nekünk, és mi segítünk megtalálni a számodra optimális megoldást.