[Videó] Serverless technológiák a gyakorlatban

Ugyan a videot nem neztem meg, de az amazon lambdaval van tapasztalatom.

Megirsz egy programot, azon a kornyezetben amit az amazon lambda tamogat (pl. nodejs). Tegyuk fel, hogy ez egy ritkan hasznalt dolog, pl. kepfeltoltesnel atmeretezi a kepet, vagy szamlanal a szamlakepen ocr-t futtat.

A lambda igazabol egy elore bekonfigolt virtualis gep, ami valamilyen eventre (http request vagy timer) triggelerodik, es ez a gep elinditja a programodat, majd miutan vegzett (vagy timeout letelt), leallitja a gepet.

Ennyi idod van egy http keresre valaszt adni.

Nem kell torodnod kontenerek ezreivel, nem futnak folyamatosan, nem hasznaljak a memoriat (ami szerveren a szuk keresztmetszet).

Nem kell foglalkoznod a kornyezet frissen tartasaval (ez nem egy kesz docker kontener, amibol ujat kene forgatnod), a kornyezetet az amazon frissen tartja.

Van par fajl amit ki kell toltened az amazon fele, hogy a tudja a programodrol, hogy kell inditani, de ennyi.

Az elonye? Nem fizetsz csak a futasidoert. Nem kell frissen tartanod a kornyezetet.

Baromi gyorsan elinditjak a lambda szervert ami elinditja a programodat, valami 3 masodperc a cold start, de ha sokszor hivod meg, akkor boven masodperc alatt van az inditas.

Erdemes egy status funkciot implementalni ami hamar visszater a valasszal , igy cacheban tarthatod a programodat az amazonnal.

Egy minimalis programot osszerakni pl. dockerban nekem olyan 50-60MB ramot eszik meg ha jol emlekszem, es akkor egy hello worldrol beszelunk. Nem tudsz realisan minden funkciot sajat kontenerbe pakolni, mert elfogy a ram. A lambdaval ez lehetseges.

Semmi közöm a szoftver fejlesztéshez (hivatalosan, hobbiból van) és a felhős/elosztott rendszerekhez sem értek

Ezzel nagyjából meg is válaszoltad az összes kérdésedet, mert ha lenne tapasztaladod benne akkor ezeket a kérdéseket fel sem tetted volna.

devops helyett egy óriási multinak fizetni mindenért (aki a nyereségért csinálja, ergo csak nagyon nagy méreteknél lesz költséghatékony

Pontosan azért lesz lehet költséghatékonyabb kiszervezni public cloudba az infrát, mert a multi mondjuk egymillió ügyfélnek szolgáltat, a házon belüli IT department meg csak magatoknak. Más problémára ad megoldást a kettő, egyik sem feltétlenül rossz megoldás.

A megspórolt devops fizetéséből kitelik a különbözet?

már a fejlesztési fázisban sincs olyan, hogy a fejlesztő a saját gépén tesztel, tehát már a fejlesztés alatt is viszi szépen a pénzt?

Azt megbecsülte-e valaki, hogy tényleg rövidebb lesz-e a fejlesztési idő, ha az felsorolt sok dologgal nem kell a fejlesztőnek foglalkozni?

Szerintem ne azon gondolkodj, hogy mennyit lehet a fizetésekből spórolni.

Mennyivel korábban tudsz belépni egy piacra, ha az embereid nem a kereket találják fel épp újra, hanem a konkrét problémán dolgoznak? Mennyi pénzt vagy hajlandó parkoltatni évekig a saját infrastruktúrában, és nézni, ahogy csökken az értéke? Stb.

Nem ilyen területen dolgozom, ezért én is csak laikusként mondom, de vannak válaszaim a kérdéseidre:

1. A szolgáltatás nincsen fixen szerverhez rendelve, hanem automatikusan indul el "valahol". Ezért nevezik így.

2. Másodperc alapú számlázás van. Ha nem használod nem kerül semmibe - vagy legalábbis nagyon olcsó. Tehát ha Magyarország a célcsoportod és munkaidőben használják a szolgáltatásod, akkor az éjszakákat máris megspóroltad. De ha mégis jön egy csúcsterhelés, akkor a rendszer automatikusan felskálázza a szolgáltatásodat, így nagyon nagy potenciális igényt ki tudsz szolgálni olcsón.

3. Tippem: Ha eleve konténerekben fejlesztesz, akkor elég lesz késői fázisban az igazi infrastruktúrán tesztelni, mert a fejlesztői gépen futó konténered pont ugyanazt tudja. Lásd 10. pontot!

Mibe kerül a fejlesztés, ha már közben több cloudban fut? Ameddig nem stressz-tesztet futtatunk, addig szinte semmibe, az a néhány futás, amit a fejlesztő csinál nem lesz drága. Összemérve a bérköltséggel semmi. De nem kötelező a cloudban futni, a fejlesztői gépünkön is fejleszthetünk.

5. Szerintem többfélére redundánsan feltenni a szolgáltatást mindigis drága lesz a tervezés szintjén, de ez független attól, hogy milyen technológia van alatta.

6. A másodperc alapú számlázás miatt elméletben olcsóbb lehet, ha a terhelés ingadozik, vagy nem tudjuk előre.

7. Én úgy tudom, hogy az iparban hatalmas pofáraesések vannak a sima cloudos fejlesztéssel is. De az is igaz, hogy mindigis óriási pofáraesések voltak az iparban, az elinduló projektek jelentős része sosem készül el :-)

8. Ha rosszul skálázódik egy program, akkor fizikai vason, vagy VPS-en simán lassú lesz, vagy OOM-mel elszáll. Itt pedig baromi drága lesz. "Stop loss"-szerű védelmet be lehet állítani, ezt az előadó is említette. De tény, hogy ez felügyelet nélkül problémás lehet.

9. Szerződés kérdése, azt tippelném.

10. A konkrét technológia ismerete nélkül azt tippelném, hogy kompatibilis környezetet a fejlesztő a saját gépén is tud futtatni. Nincsen benne semmi mágia.

11. Igen. Illetve egymástól eltanulják a projekt folyamán. Architekt kell, aki jól tervezi meg a szolgáltatásokat és közöttük az API-t, a többi fejlesztő már csak lekódolja minták alapján.
 

1. A Serverless megnevezés valóban kicsit zavaró. Azért szeretik inkább Lambda vagy Function-as-a-Service-nek (FaaS) nevezni. A lényeg az, hogy nem ódvatú módon konténert image-et adsz és hozzá Helm chartot, hanem konkrétan egy meghívható függvényt. Megoldása válogatja, hogy hogyan működik pontosan, hogyan fogadsz és küldesz adatot, honnan szeded az útvonal paramétereket, HTTP headereket, hogyan állítod be a válasz HTTP státuszt. Máskülönben olyan, mint a régi microservice: eldobható, környezeti változóból veszi a beállításokat, felcsatolt volume-ból (K8s secret) a TLS certeket, stb. Viszont az csak elméletben igaz, hogy ha a függvényed kilép, akkor vége mindennek, mert pl. a HTTP v2 kapcsolatok meg adatbázis sessionök ezt megsínylenék.
2. Saját rendszert üzemeltetni szerintem felejtős. Annyi probléma van vele, támadások, skálázás, adatbázis redundancia, stb, hogy erre csak nagyon profik képesek. Ilyen "óriási multi" remélhetőleg magyar is van. Ha drágul, akkor átmész máshova.
3. Mindig cloud semlegesre készül minden cloud native kód. A FaaS pont itt okoz kis fejtörést, nem szabad cloud függő frameworkre hagyatkozni.
4. Ha a fejlesztő követi az alapszabályokat, hogy mocskosul egyszerű kódot ír, csak 1 dologgal foglalkozik, akkor piszkosul nehéz problémába ütközni.
5. Árazástól függ. De ha adatbázisod is van, azt hogyan tartod szinkronban 2 felhőszolgáltató közt? Pl. Azure és AWK felhőkben lévő Rediseidet összekötöd?
6. Szerintem mindenki magának számolja ki.
7. A FaaS csak kis mértékben gyorsíthat, ha már eddig is cloud native voltál. A különbség csak annyi, hogy függvényt adsz meg az API GW-nek, nem a K8s service URL-jét.
8. Az itthoni programozókkal semmi gond. Minden sarkon találsz vérprofi cloud native fejlesztőt. Ez nem véletlen, piszkosul egyszerű az egész.
9. FaaS-nál nem állítgatsz erőforrást. Meghívódik a függvényed, olvasol/írsz adatbázist, visszatérsz. A jó öreg Kubernetesnél sem nagy probléma, ha több példány fut, mint kéne, kivéve, ha a cluster lefoglalja a resource limitben megadott erőforrásokat. Meg az sem jó, ha 1 példányra tolsz 10000 kérés/s forgalmat.
10. A kód felhőfüggetlen, saját laptopon pl. minikube-ban vagy k3s-ben illik elfutnia, ha csak nem valami számításigényes (pl. videó, AI) cuccot fejlesztesz. De az igazi FaaS ezek nélkül is elmegy, ha kell DB, indítasz egyet és a proginak átadod a címét környezeti változóban.
11. A cloud native világ mocskosul egyszerű. Azok a 20 soros tutorialok, amik fenn vannak, valóban működőképes és élesben biztonságosan üzemeltethető alkalmazások. Helyette az eszköztár nőtt meg. Pl. HTTP hibakódokra odadobsz egy számlálót és felkelti az üzemeltetőt, ha csúnyák a számok. De ennek remélhetőleg nem nagyon kell a kódban megjelennie.
12. A magyarok eléggé elől járnak ezekben a technológiákban. A sok nagy multi, pl. IBM, telkók már rég behozták ezeket.
13. A multiknál dolgozó magyarok többsége itthon van.

https://aws.amazon.com/blogs/compute/simplify-serverless-applications-w…

1. - a cloud már nem elég "trendy", kellett egy újabb clickbait buzzword

Ne lássunk már bele olyat ami nincs benne. Lambda és társai sok éve léteznek, pont ugyanígy hívták akkor is (serverless). És még csak az sem igaz, hogy most van ebből valami hype, vagy eddig nem érdekelt senkit, de most beindult. Ha valaki ezen a területen dolgozik, akkor nem újdonság neki, eléggé megkerülhetetlen téma már évek óta.

Igen, egyetértek. A legtöbb szoftver sokszoros erőforrást használ, mint ami az adott feladathoz minimálisan szükséges. Ha valami csak mondjuk 1000-szeres, akkor az már egész jónak számít, és simán mehet production-be. Itt is szoktam azzal sokkolni, hogy mikor olyan topik van, hogy adatbázist kell optimalizálni, mert lassú, akkor bemutatom, hogy az összes adat elférne ~100MB körüli RAM-ban, és ha végignyálazva keresnénk benne és minden tranzakció után egy új fájlba mentenénk az egészet, akkor is sokszor gyorsabb lenne mint az elvárt.

Ettől függetlenül, ahol _valóban szükség van rá_, ott ezek a modern dolgok tényleg hasznosak lehetnek. Véleményem szerint az igazán nagy adatmennyiségekkel dolgozó programoktól eltekintve mindent fejlesztési időre kell optimalizálni, viszont az iparban hallgatólagosan elfogadott 1000-szeres erőforrás használat helyett 10-50-szeresig érdemes mégis optimalizálni. Ha ezt megcsinálják, akkor máris kiderül, hogy a teljesítmény felskálázása sokkal olcsóbb is tud lenni. A fejlesztés során ha folyamatosan teljesítményben is gondolkodunk (azzal a népi bölcsességgel sem értek, hogy a túl korai optimalizálás mindig baj volna), illetve időnként profilozunk és az alapján szűk keresztmetszeteket javítunk, akkor sokszor egyszerűbb megoldások is születnek. Azért mert rákényszeríti a fejlesztőt arra, hogy gondoljon bele, hogy mégis amit csinált az _hogyan_ is működik? Mi a felesleges belőle?