Kulcsfontosságú elemek
- Már évek óta ígérik, hogy a serverless számítások új korszakot nyitnak meg, ahol nem szükséges konkrét operációs rendszer az alkalmazások futtatásához. Azt mondták, hogy ez a struktúra megoldja a skálázhatóság számos problémáját. Az igazság azonban más.
- Bár sokan új ötletként tekintenek a serverless technológiára, gyökerei egészen 2006-ig nyúlnak vissza, amikor megjelent a Zimki PaaS és a Google App Engine — mindkét esetben serverless architektúrával dolgoznak.
- Négy oka van annak, hogy a serverless forradalom zsákutcába jutott: a programozási nyelvek korlátozott támogatásától a teljesítmény problémáiig.
- A serverless számítások nem annyira haszontalanok. Távolról sem. Azonban nem szabad közvetlen helyettesítőként tekinteni őket a szerverek számára. Bizonyos alkalmazások esetében kényelmes eszköz lehet.
A szerver halott, éljen a szerver!
Ez a serverless forradalom híveinek harci kiáltása. Elég, ha áttekintjük az ipari sajtót az elmúlt néhány évben, és könnyen arra a következtetésre juthatunk, hogy a hagyományos szervermodellek halottak, és néhány éven belül mindannyian serverless architektúrákat fogunk használni.
Mint azt bárki a szakmában tudja, és ahogy mi is jeleztük az , ez nem így van. Annak ellenére, hogy számos cikk szól a , valójában nem következett be. A valóság az, hogy , hogy ez a forradalom valószínűleg zsákutcába jutott.
Néhány ígéret a serverless modellek számára nyilvánvalóan megvalósult, de nem mindegyik. Messze nem mindegyik.
A cikkben szeretném megvizsgálni ennek okait. Miért jelent még mindig akadályt a serverless modellek rugalmasságának hiánya a szélesebb körű bevezetéshez, bár ezek hasznosak maradnak konkrét, jól meghatározott körülmények között.
Mit ígértek a serverless számítások hívei?
Mielőtt rátérnénk a serverless számítások problémáira, nézzük meg, hogy mit kellett volna nyújtaniuk. számtalanok voltak, és olykor nagyon ambiciózusak.
Azok számára, akik nem ismerik a kifejezést, itt van egy rövid meghatározás. A szerver nélküli számítások olyan architektúrát határoznak meg, ahol az alkalmazások (vagy alkalmazásrészek) igény szerint futnak olyan végrehajtási környezetekben, amelyek általában távoli helyeken kerülnek elhelyezésre. Ezen kívül a szerver nélküli rendszerek saját magunk is hosztolhatók. Az elmúlt években a tartós szerver nélküli rendszerek létrehozása volt a rendszergazdák és a SaaS cégek fő gondja, mivel (ahogy állítják) ez az architektúra számos kulcsfontosságú előnyt kínál a "hagyományos" kliens-szerver modellhez képest:
- A szerver nélküli modellek nem követelik meg, hogy a felhasználók fenntartsák a saját operációs rendszereiket, vagy akár olyan alkalmazásokat hozzanak létre, amelyek kompatibilisek bizonyos operációs rendszerekkel. Ahelyett, hogy ezt tennék, a fejlesztők közös kódot írnak, feltöltik azt egy szerver nélküli platformra, és figyelemmel kísérik a végrehajtását.
- A szerver nélküli keretrendszerekben az erőforrásokat általában percek (vagy akár másodpercek) alapján számolják el. Ez azt jelenti, hogy az ügyfelek csak az időt fizetik, amikor a kód valójában fut. Ez kedvezően eltér a hagyományos felhő VM-től, ahol a gép a legtöbb időt tétlenül tölti, de azért fizetni kell érte.
- A méretezhetőségi probléma is megoldódott. A szerver nélküli keretrendszerekben az erőforrások dinamikusan kerülnek kiosztásra, így a rendszer könnyen megbirkózik a váratlan keresleti csúcsokkal.
Röviden, a szerver nélküli modellek rugalmas, olcsó, méretezhető megoldásokat biztosítanak. Meglepő, hogy eddig nem jutottunk el erre az ötletre.
Valójában ez egy új ötlet?
Valójában az ötlet nem új. Az a koncepció, amely lehetővé teszi a felhasználók számára, hogy csak az időért fizessenek, amikor a kód valóban fut, azóta létezik, hogy bevezették a 2006-ban, és körülbelül abban az időben a Google App Engine is nagyon hasonló megoldást kínált.
Valójában az, amit ma "szerver nélküli" modellnek nevezünk, idősebb, mint sok olyan technológia, amelyet ma "natív felhőnek" neveznek és amelyek szinte ugyanazt biztosítják. Ahogy már említettük, a szerver nélküli modellek lényegében csak a már évtizedek óta létező SaaS üzleti modell folytatását jelentik.
Elismerni kell, hogy a szerver nélküli modell nem FaaS architektúra, bár van kapcsolat közöttük. A FaaS lényegében a számítási orientált része a szerver nélküli architektúrának, de nem képviseli az egész rendszert.
De mégis, miért is ez a felhajtás? Mivel az internet penetrációja a fejlődő országokban folyamatosan gyorsul, a számítási erőforrások iránti kereslet is növekszik. Például sok, gyorsan növekvő e-kereskedelmi szektorral rendelkező országban egyszerűen nincs számítási infrastruktúra ezen platformok alkalmazásaihoz. Itt jönnek be a fizetős szerver nélküli platformok.
A szerver nélküli modellek problémái
A gond az, hogy a szerver nélküli modelleknek vannak… problémái. Ne érts félre: nem azt mondom, hogy önállóan rosszak, vagy hogy nem nyújtanak jelentős értéket bizonyos cégeknek, bizonyos körülmények között. De a fő állítás, miszerint a szerver nélküli architektúra gyorsan felváltja a hagyományosat, sosem fog megvalósulni.
Éppen ezért.
Korlátozott programozási nyelvi támogatás
A legtöbb szerver nélküli platform csak bizonyos nyelveken írt alkalmazások futtatását engedi meg. Ez jelentősen korlátozza ezeknek a rendszereknek a rugalmasságát és alkalmazkodóképességét.
Azt tartják, hogy a szerver nélküli platformok a legtöbb elterjedt nyelvet támogatják. Az AWS Lambda és az Azure Functions is biztosít keretet az alkalmazások és funkciók futtatására nem támogatott nyelveken, bár ez gyakran teljesítménybeli költségekkel jár. Tehát a legtöbb szervezet általában nem tartja ezt a korlátozást jelentősnek. De itt a helyzet: az a szóbeszéd járja, hogy a szerver nélküli modellek egyik előnye, hogy a kevésbé ismert, ritkán használt programok olcsóbban használhatók, mivel csak a végrehajtásuk idejéért fizetünk. A kevésbé ismert, ritkán használt programok gyakran… kevésbé ismert, ritkán használt programozási nyelveken íródnak.
Ez aláássa a szerver nélküli modell egyik kulcsfontosságú előnyét.
Kötődés a szolgáltatóhoz
A második probléma a serverless platformokkal, vagy legalábbis azzal, ahogy manapság megvalósítják őket, az, hogy általában nem hasonlítanak egymásra az operációs szintjén. Szinte nincs standardizáció a funkciók írása, telepítése és kezelésében. Ez azt jelenti, hogy a funkciók migrálása egyik platformról a másikra rendkívül időigényes.
A serverless modellre való áttérés legnehezebb része nem a számítási funkciók, amelyek általában csak kódfragments, hanem az, hogyan kapcsolódnak az alkalmazások a csatlakoztatott rendszerekhez, mint például az objektumtárolók, az azonosítás kezelése és a sorok. A funkciókat át lehet helyezni, de az alkalmazás többi részét nem. Ez teljesen ellentétes a megígért olcsó és rugalmas platformokkal.
Egyesek azt állítják, hogy a serverless modellek nemrégiben jelentek meg, és nem volt idő standardizálni a működésüket. De nem olyan újok, mint ahogy azt már korábban is megjegyeztem, és sok más felhőtechnológia, mint például a konténerek, már sokkal használhatóbbá vált a jó standardok kifejlesztésével és széleskörű bevezetésével.
Teljesítmény
A serverless platformok számítási teljesítménye nehezen mérhető, részben azért, mert a szolgáltatók igyekeznek titokban tartani az információkat. A legtöbben azt állítják, hogy a távoli, serverless platformokon működő funkciók ugyanolyan gyorsan működnek, mint a helyi szervereken, néhány elkerülhetetlen késési probléma kivételével.
Azonban egyes tények éppen az ellenkezőjét mutatják. Azon funkciók, amelyek korábban nem futottak egy adott platformon, vagy nem futottak egy ideje, némi időt igényelnek az inicializáláshoz. Valószínűleg ez azért van, mert a kódjukat egy nehezen hozzáférhető tárolóba helyezték át, bár — ahogyan a benchmarkok esetében — a legtöbb szolgáltató nem mondja el Önnek az adatok áthelyezéséről.
Természetesen van néhány módja ennek megkerülésére. Az egyik az, hogy optimalizálja a funkciókat bármely felhőnyelvre, amelyen a serverless platformja működik, de ez egy kicsit aláássa azt az állítást, hogy ezek a platformok "rugalmasak".
Egy másik megközelítés az, hogy rendszeresen futtassuk a teljesítmény szempontjából kritikus programokat, így azok „frissen” maradnak. Ez a második megközelítés természetesen ellentmond annak az állításnak, hogy a szerver nélküli platformok költséghatékonyabbak, mivel csak az alkalmazásaid futási idejéért kell fizetned. A felhőszolgáltatók új módszereket vezettek be a hideg indítások csökkentésére, de sok esetben az „egyhez méretezés” (scale to one) követelménye a FaaS eredeti értékét kérdőjelezi meg.
A hideg indítás problémáját részben meg lehet oldani a szerver nélküli rendszerek saját kezű indításával, de ez saját költségekkel jár, és továbbra is niche megoldásként rendelkezésre áll, jól felszerelt csapatok számára.
Nem tudsz teljes alkalmazásokat futtatni
Végül, talán a legfontosabb ok, amiért a szerver nélküli architektúrák nem fogják helyettesíteni a hagyományos modelleket a közeljövőben: általában nem lehet rajtuk teljes alkalmazásokat futtatni.
Pontosabban, költséghatékonyság szempontjából nem ésszerű. A sikeres monolitodat valószínűleg nem éri meg négy tucat funkcióból álló összeállítássá alakítani, nyolc átjáró, negyven sor és tucatnyi DB példány mellett. Ebből a szempontból a serverless jobban illik az új fejlesztésekhez. Gyakorlatilag egyetlen létező alkalmazást (architektúrát) nem lehet átkonvertálni. Migrálhatsz, de újra kell kezdened az alapoktól.
Ez azt jelenti, hogy a túlnyomó többségében a szerver nélküli platformokat kiegészítő megoldásként használják a helyi szerverek mellett, hogy nagy számítási teljesítményt igénylő feladatokat hajtsanak végre. Ez nagyon eltéríti őket a felhőtechnológiák két másik formájától - a tartályoktól és a virtuális gépektől, amelyek átfogó módon kínálják a távoli számítástechnikát. Ez illusztrálja az egyik nehézséget a mikroszolgáltatásokról a szerver nélküli rendszerekre való áttérés során.
Természetesen ez nem mindig jelent problémát. A lehetőség, hogy időnként óriási számítástechnikai erőforrásokat használjunk anélkül, hogy saját hardvert kellene vásárolnunk, valódi és tartós előnyöket hozhat számos szervezet számára. De ha egyes alkalmazások helyi szervereken futnak, míg mások szerver nélküli felhőarchitektúrákon, akkor a kezelés egy új összetettségi szintre lép.
Éljen a forradalom?
Mindezek ellenére nem vagyok ellenfele a szerver nélküli megoldásoknak mint olyanoknak. Tényleg. Csak a fejlesztőknek meg kell érteniük - különösen, ha először fedezik fel a szerver nélküli modelleket - hogy ez a technológia nem közvetlen helyettesítése a szervereknek. Ehelyett nézze meg tanácsainkat és erőforrásainkat a és döntsön arról, hogy a legjobban hogyan alkalmazhatja ezt a modellt.
Forrás: habr.com
