Felidéztem, mennyire nem értettem a serverless működését, és elővettem mindazokat a kérdéseket, amelyek akkor bennem kavarogtak.

Eltűntek a szerverek? A varázsló leleplezése

🧙‍♂️ (professzor) „🐣, ma a serverless világát vesszük át. A név alapján olyan, mintha egy varázsige lenne, amely eltünteti a szervereket, a valóság azonban sokkal földhözragadtabb, mégis mélyebb.”

🐣 (hallgató) „Nincsenek is szerverek? Csak nem úgy kiáltottál, mint Harry Potter, hogy »Szerverek, tűnjetek el!«, és tényleg eltűntek?”

🧙‍♂️ (professzor) „Haha, pontosan ezt gondolja az emberek kilencven százaléka az első pillanatban! A szerverek valójában a felhő mélyén gőzerővel dolgoznak. A különbség az, hogy neked nem kell velük törődnöd.”

🐣 (hallgató) „Tehát átverés? Mint amikor a boltban »vegyszermentes« felirat van a zöldségen, közben a háttérben mégis teleöntik permettel?”

🧙‍♂️ (professzor) „Furcsa hasonlat, de ül. A »serverless« valójában azt jelenti, hogy nem kell szervereket menedzselned. Régen saját szervereket tartottunk, operációs rendszert telepítettünk, hibákat javítottunk – mintha hörcsögöt gondoztunk volna. A serverless esetén mindezt a felhőszolgáltató vállalja át.”

🐣 (hallgató) „Ha egy hörcsög meghal, sírunk. Ha egy szerver hal meg, az ügyfél ordít. Sokkal keményebb.”

🧙‍♂️ (professzor) „És a szerverrel ellentétben a hörcsög nem rángat fel hajnali háromkor azzal, hogy »a adatbázis nem válaszol«."

📌 Megjegyzés: a serverless alapfogalma A serverless (szerver nélküli) nem azt jelenti, hogy nincsenek szerverek, hanem azt, hogy a felhőszolgáltató üzemelteti és felügyeli őket helyetted.

  • Hagyományos modell: saját szervert vásárolsz, telepítesz és menedzselsz.
  • Serverless: az infrastruktúrát a szolgáltató kezeli, te a kódra koncentrálsz.

Hogyan működik a serverless? A hívásra megjelenő nindzsa

🐣 (hallgató) „Ez bonyolultnak hangzik. Miben más, mint egy normál szerver?”

🧙‍♂️ (professzor) „Valóban más. A serverless olyan, mint egy rövidtávfutó: csak akkor fut be, amikor hívod. Felbukkan, elvégzi a feladatot, majd azonnal eltűnik. Maratonra alkalmatlan.”

🐣 (hallgató) „Tehát ha azt mondom: »Most azonnal számolj!«, előbújik, és ha végzett, azonnal köddé válik?”

🧙‍♂️ (professzor) „Pontosan! Olyan, mint egy nindzsa, aki csak a hívásra jelenik meg. Alapesetben felhőbe burkolózik, így az üresjárat idejére nem fizetsz bérleti díjat.”

🐣 (hallgató) „De a nindzsák mindig más helyről bukkannak elő. Mi lesz az IP-címmel?”

🧙‍♂️ (professzor) „Éles szem! Nincs fix címe. Minden hívásnál másik szerver indul, ezért van API-gateway, amely a »nindzsafalu kapuőre«, és a bejövő kéréseket a megfelelő nindzsához irányítja.”

🐣 (hallgató) „Értem. De ha mindig másik nindzsa érkezik, akkor nincs meg az előző emléke, ugye?”

🧙‍♂️ (professzor) „Úgy bizony. Ezért kötelező a stateless, vagyis állapotmentes tervezés. Nem lesz olyan beszélgetés, hogy »ó, a tegnapi folytatása«. Minden alkalommal »örülök, hogy találkozunk« – aranyhal-memória.”

🐣 (hallgató) „Ez kényelmetlennek hangzik. Mi lesz a bejelentkezéssel vagy a munkamenetekkel?”

🧙‍♂️ (professzor) „A fontos adatokat külső adatbázisokba vagy Redis-be mentjük. A nindzsa nem őrzi meg az emlékeit, helyette »tekercsraktárba« (külső tárba) tesszük, ami számít.”

📌 Megjegyzés: miért fontos az állapotmentes tervezés A serverless függvények minden futáskor új konténerben indulnak, ezért a lokális állapot (változók, fájlok, session) nem marad meg.

  • Állapotkezelés: külső adatbázis, Redis, S3 és társaik.
  • Session: JWT-token vagy külső tárban tárolt munkamenet.
  • Fájlok: az átmeneti feldolgozáson túli adatokhoz mindenképpen külső tárhely szükséges.

Miben más a hagyományos szerver? Házi kedvenc kontra nindzsa

🐣 (hallgató) „Konkrétabban hogyan néz ki mindez?”

🧙‍♂️ (professzor) „Vegyünk egy példát: feltöltesz egy képet, és bélyegképet kell belőle készíteni. A hagyományos világban 24 órában futó szerver várakozik, hogy valaki végre jöjjön. Közben áramot zabál és bármikor megállhat.”

🐣 (hallgató) „Mint egy kapus, aki egész nap az ajtóban áll, hogy majd csak jön valaki.”

🧙‍♂️ (professzor) „Pont így! Ráadásul a kapus meg is fázhat és kidőlhet. Serverlessnél a csengő csak akkor szól, amikor tényleg jön kép: a nindzsa előugrik, megcsinálja a bélyegképet, aztán távozik.”

🐣 (hallgató) „Ez logikusan hangzik. De nem tart sokáig, mire a nindzsa megjelenik?”

🧙‍♂️ (professzor) „Ez a híres cold start probléma. Ha mélyen aludt, kell pár másodperc, míg felkel és felkészül. Különösen a nehézkes nyelveknél, például Java esetén olyan, mintha félálomban még jógaszőnyeget terítene és reggelit készítene.”

🐣 (hallgató) „Idegesítő lehet. Akkor nem való valós idejű feladatokra?”

🧙‍♂️ (professzor) „Van melegítési mechanizmus, de alapvetően a batch vagy aszinkron feladatokat szereti. Az »azonnal válaszolj!« típusú kérésekhez kevésbé ideális.”

Példával érthetőbb: fotómegosztó alkalmazás

🐣 (hallgató) „Mutasd meg egy konkrét példával! Mondjuk egy fotómegosztó appnál?”

🧙‍♂️ (professzor) „Szuper példa. A hagyományos módszer így néz ki:”

Hagyományos szerver esetén:

0-24-ben futó webszerver (havi 5000 jen)
↓
„Kép érkezett!”
↓
A szerveren belül bélyegkép-készítés
↓
Mentés az adatbázisba

🧙‍♂️ (professzor) „Itt akkor is fizetsz 5000 jent, ha senki sem tölt fel képet. Olyan, mintha egy üzlet után akkor is fizetnéd a bérleti díjat, ha nincs forgalom.”

🐣 (hallgató) „Pazarlás.”

🧙‍♂️ (professzor) „Serverlessnél így fest:”

Serverless verzió:

Kép érkezik egy S3 bucketbe
↓
Az S3 esemény elindítja a Lambda-függvényt
↓
A Lambda 0,1 másodperc alatt feláll
↓
Elkészíti a bélyegképet és egy másik S3 bucketbe menti

🧙‍♂️ (professzor) „Csak akkor fizetsz, amikor ténylegesen fut a kód. Ha épp senki sem használja az appot, nulla jen megy ki.”

🐣 (hallgató) „Ez elképesztően hatékony.”

📌 Megjegyzés: tipikus serverless-használati esetek

  • Képfeldolgozás, videó-átalakítás: esemény vezérelt, rövid futásidővel.
  • API-hívások vagy webhookok gyors feldolgozása.
  • Cron-jellegű batch feladatok.
  • Adatcsatornák (streaming) vagy logfeldolgozás.

Hol kerülhetünk bajba? A számlázási csapdák

🐣 (hallgató) „Ha ennyire jó, miért nem használja mindenki?”

🧙‍♂️ (professzor) „Mert könnyű elszállni a költségekkel. Képzeld el, hogy valaki véletlenül végtelen ciklust indít egy API Gateway-en. Milliárdnyi hívás generálódhat, és a hónap végén kiderül, hogy a számla horror.”

🐣 (hallgató) „Olyan, mint amikor valaki bekapcsolva hagyja a csapot, és elönti a fürdőt.”

🧙‍♂️ (professzor) „Pontosan. Ezért kell guardrail: fogyasztási riasztás, költségkeret, CloudWatch figyelés. A serverless nem azt jelenti, hogy nincs üzemeltetés, csak másra kell figyelned.”

📌 Megjegyzés: számlázási kockázatok elleni védelem

  • Használj költségriasztásokat (Budget, Billing Alarm).
  • Korlátozd az egyidejű futásokat (Concurrency limit), hogy ne lehessen elszállni.
  • Naplózz és monitorozz (CloudWatch, X-Ray) a szokatlan viselkedés kiszúrására.

Mikor válaszd a serverless megoldást?

🐣 (hallgató) „Összefoglalva: mikor érdemes serverlessre fogni egy feladatot?”

🧙‍♂️ (professzor) „Ha ingadozó terhelésed van, gyorsan kell reagálni az igényekre, és nem akarsz infrastruktúrát babusgatni, akkor aranyat ér. De ha alacsony késleltetésű, állandó terhelésű, állapotfüggő rendszert építesz, lehet, hogy egy konténer vagy VM lesz a jobb.”

🐣 (hallgató) „Tehát nincs univerzális válasz. Tudni kell, mire való.”

🧙‍♂️ (professzor) „Így van. A serverless egy nindzsa a fegyvertáradban. Ha jól használod, villámgyors és olcsó. Ha rosszul, akkor váratlan számlát és korlátokat kapsz.”

Zárszó

🐣 (hallgató) „Kezdem érteni. A varázs mögött nagyon is valós munka és rengeteg fegyelem van.”

🧙‍♂️ (professzor) „Pontosan. A lényeg, hogy a szerverek nem tűntek el – csak a háttérbe húzódtak, és mi a kódra koncentrálhatunk.”

🐣 (hallgató) „Rendben, professzor. Akkor most tanuljunk meg nindzsául fejleszteni.”

🧙‍♂️ (professzor) „Rajta! Elő a tekercsekkel, és indulhat a felhőszámla túlélőkurzus.”