A lecke végére el tudod magyarázni, mit jelent a serverless, miben tér el az architektúrastílusoktól, és milyen kompromisszumokat jelent a minőségi jellemzők szempontjából.
Miért kell külön tárgyalni?
A serverless gyakran szerepel az architektúrák között, pedig elsősorban azt írja le, ki üzemelteti a futtatást, nem azt, hogyan bontják a rendszert. Ugyanaz a rendszer monolitként és szolgáltatásokra bontva is futhat serverless környezetben. A fogalmat azért kell érteni, mert gyakran keverik a mikroszervizekkel.
Mi a serverless?
Mike Roberts (Martin Fowler oldalán megjelent) cikke szerint a serverless architektúra harmadik fél által üzemeltetett BaaS (Backend as a Service, kész háttérszolgáltatások, például azonosítás vagy adatbázis) és/vagy FaaS (Functions as a Service) platformon futó egyedi kód használatát jelenti, ami csökkenti az állandóan futó szerverek szükségességét. A FaaS-ban a kód állapotmentes, eseményvezérelt, rövid életű futtatási környezetekben fut, amelyeket a szolgáltató kezel.
Az AWS Lambda dokumentációja ezt a modellt így írja le: a kód szerverek létesítése és kezelése nélkül fut; a szolgáltató kezeli a kapacitást, a skálázást és a javításokat; a kód eseményre (például API-hívásra vagy üzenetre) indul; minden hívás önállóan fut, és a fizetés használat alapú.
flowchart LR
E["Esemény:<br/>kérés, üzenet, időzítő"] --> F["Függvény<br/>(a szolgáltató indítja)"]
F --> S[("Külső tár")]
F --> R["Eredmény"]
Szempontok szerint
Szempont
Serverless (FaaS)
Csatolás
A függvények eseményekkel és szolgáltatásokkal kapcsolódnak; a platformhoz való kötődés erős lehet
Deployolhatóság
Függvényenként könnyű kiadás
Skálázás
Automatikus, a platform kezeli
Adatkezelés
A függvény állapotmentes; az állapot külső tárban van
Hibakezelés
A platform kezeli a futtatási hibákat; az időtúllépés és az ismétlés a tervezés része
Költség
Használat alapú; ritka vagy ingadozó terhelésnél előnyös
Roberts a következő hátrányokat említi: a szolgáltatótól való függés, az állapotmentesség (az állapotot kívül kell tárolni), a futási idő korlátja, a hidegindítás késleltetése és a nehezebb integrációs tesztelés, mert a felhőt helyben nem lehet teljesen szimulálni. A futási idő korlátját a cikk a megírása idején érvényes értékkel (öt perc az AWS Lambdánál) adta meg; a szolgáltatók korlátai változnak (az AWS Lambda jelenlegi dokumentációja szerint egy hívás legfeljebb 15 percig tarthat), ezért konkrét értéket mindig a szolgáltató aktuális dokumentációjából kell venni.
Hogyan viszonyul a többi stílushoz?
A serverless futtatási modell: a telepítés és a skálázás felelőssége a szolgáltatóra kerül.
Ettől még a szerkezet kérdése nyitott: egy serverless rendszer is lehet jól vagy rosszul határolt, és elosztott monolittá is válhat, ha a függvények szorosan egymásra épülnek.
A hálózati hívás, a végső konzisztencia és a hibakezelés kérdései ugyanúgy megjelennek, mint a mikroszervizeknél.
Gyakori tévhitek
Állítás
Pontosítás
„A serverless egyenlő a mikroszervizekkel.”
A serverless futtatási modell, a mikroszerviz felbontási stílus.
„A serverlessben nincs szerver.”
Van, de a szolgáltató üzemelteti.
„A serverless mindig olcsóbb.”
A használat alapú díjazás ritka terhelésnél előnyös; állandó nagy terhelésnél nem biztos.
„A függvényekre bontás megoldja a határokat.”
A jó határokat ettől még meg kell tervezni.
Röviden
A serverless futtatási modell: a szolgáltató kezeli a szervereket és a skálázást.
FaaS esetén a kód eseményvezérelt, állapotmentes és rövid életű.
Serverless: futtatási modell, nem szerkezet
Célok
A lecke végére el tudod magyarázni, mit jelent a serverless, miben tér el az architektúrastílusoktól, és milyen kompromisszumokat jelent a minőségi jellemzők szempontjából.
Miért kell külön tárgyalni?
A serverless gyakran szerepel az architektúrák között, pedig elsősorban azt írja le, ki üzemelteti a futtatást, nem azt, hogyan bontják a rendszert. Ugyanaz a rendszer monolitként és szolgáltatásokra bontva is futhat serverless környezetben. A fogalmat azért kell érteni, mert gyakran keverik a mikroszervizekkel.
Mi a serverless?
Mike Roberts (Martin Fowler oldalán megjelent) cikke szerint a serverless architektúra harmadik fél által üzemeltetett BaaS (Backend as a Service, kész háttérszolgáltatások, például azonosítás vagy adatbázis) és/vagy FaaS (Functions as a Service) platformon futó egyedi kód használatát jelenti, ami csökkenti az állandóan futó szerverek szükségességét. A FaaS-ban a kód állapotmentes, eseményvezérelt, rövid életű futtatási környezetekben fut, amelyeket a szolgáltató kezel.
Az AWS Lambda dokumentációja ezt a modellt így írja le: a kód szerverek létesítése és kezelése nélkül fut; a szolgáltató kezeli a kapacitást, a skálázást és a javításokat; a kód eseményre (például API-hívásra vagy üzenetre) indul; minden hívás önállóan fut, és a fizetés használat alapú.
flowchart LR E["Esemény:<br/>kérés, üzenet, időzítő"] --> F["Függvény<br/>(a szolgáltató indítja)"] F --> S[("Külső tár")] F --> R["Eredmény"]Szempontok szerint
Roberts a következő hátrányokat említi: a szolgáltatótól való függés, az állapotmentesség (az állapotot kívül kell tárolni), a futási idő korlátja, a hidegindítás késleltetése és a nehezebb integrációs tesztelés, mert a felhőt helyben nem lehet teljesen szimulálni. A futási idő korlátját a cikk a megírása idején érvényes értékkel (öt perc az AWS Lambdánál) adta meg; a szolgáltatók korlátai változnak (az AWS Lambda jelenlegi dokumentációja szerint egy hívás legfeljebb 15 percig tarthat), ezért konkrét értéket mindig a szolgáltató aktuális dokumentációjából kell venni.
Hogyan viszonyul a többi stílushoz?
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források