Főbb pontok
- Már több éve ígéretet kapunk, hogy a szerver nélküli számítástechnika (szerver nélküli) új korszakot nyit meg az alkalmazások futtatására szolgáló konkrét operációs rendszer nélkül. Azt mondták nekünk, hogy egy ilyen struktúra sok skálázhatósági problémát megoldana. Valójában minden más.
- Bár sokan új ötletnek tekintik a szerver nélküli technológiát, gyökerei 2006-ig nyúlnak vissza a Zimki PaaS-hez és a Google App Engine-hez, amelyek egyaránt szerver nélküli architektúrát használnak.
- A kiszolgáló nélküli forradalom megtorpanásának négy oka van, a korlátozott programozási nyelv támogatástól a teljesítményproblémákig.
- A szerver nélküli számítástechnika nem is olyan haszontalan. Messze van tőle. Nem szabad azonban úgy tekinteni, mint a szerverek közvetlen helyettesítésére. Egyes alkalmazásoknál praktikus eszköz lehet.
A szerver meghalt, éljen a szerver!
Ez a szerver nélküli forradalom híveinek csatakiáltása. Egy gyors pillantás az iparági sajtóban az elmúlt néhány évben elég ahhoz, hogy megállapítsuk, a hagyományos szervermodell halott, és néhány éven belül mindannyian szerver nélküli architektúrákat fogunk használni.
Amint azt a szakmában bárki tudja, és amint arra a cikkünkben is rámutattunk , ez rossz. A sok érdemi cikk ellenére , soha nem történt meg. Valójában, hogy ez a forradalom zsákutcába jutott.
A szerver nélküli modellekre vonatkozó ígéretek egy része biztosan bevált, de nem minden. Nem mindenki.
Ebben a cikkben szeretném megvizsgálni ennek az állapotnak az okait. Miért akadályozza még mindig a szerver nélküli modellek rugalmasságának hiánya szélesebb körű alkalmazásukat, jóllehet konkrét, jól meghatározott körülmények között továbbra is hasznosak maradnak.
Amit a szerver nélküli számítástechnika adeptusai ígértek
Mielőtt rátérnénk a kiszolgáló nélküli számítástechnika problémáira, nézzük meg, mit kellett biztosítaniuk. számos volt, és időnként nagyon ambiciózus.
Azok számára, akik nem ismerik a kifejezést, itt egy rövid meghatározás. A kiszolgáló nélküli számítástechnika olyan architektúrát határoz meg, amelyben az alkalmazások (vagy az alkalmazások részei) igény szerint futnak olyan futási környezetekben, amelyeket jellemzően távolról üzemeltetnek. Ezen kívül szerver nélküli rendszerek is üzemeltethetők. Az elmúlt néhány évben a rendszergazdák és a SaaS-cégek fő gondja volt a robusztus szerver nélküli rendszerek kiépítése, mivel (állítólag) ez az architektúra számos kulcsfontosságú előnyt kínál a "hagyományos" kliens/szerver modellel szemben:
- A kiszolgáló nélküli modelleknél nincs szükség arra, hogy a felhasználók saját operációs rendszereiket karbantartsák, vagy akár konkrét operációs rendszerekkel kompatibilis alkalmazásokat készítsenek. Ehelyett a fejlesztők megosztott kódot hoznak létre, feltöltik egy szerver nélküli platformra, és figyelik, ahogy fut.
- A szerver nélküli keretrendszerek erőforrásait általában percenként (vagy akár másodpercenként) számlázzuk ki. Ez azt jelenti, hogy az ügyfelek csak a kód tényleges végrehajtásának idejéért fizetnek. Ez kedvező a hagyományos felhő virtuális géphez képest, ahol a gép legtöbbször tétlen, de fizetni kell érte.
- A skálázhatóság problémája is megoldódott. A szerver nélküli keretrendszerekben az erőforrások dinamikusan vannak hozzárendelve, így a rendszer könnyen megbirkózik a hirtelen megugrott keresletekkel.
Röviden: a szerver nélküli modellek rugalmas, olcsó, méretezhető megoldásokat kínálnak. Csodálom, hogy ez az ötlet nem jutott eszünkbe korábban.
Ez tényleg új ötlet?
Valójában az ötlet nem új. Az a koncepció, hogy a felhasználók csak a kód tényleges futásának idejéért fizessenek, azóta létezik, hogy a kódot bevezették 2006-ban, és nagyjából ugyanebben az időben a Google App Engine egy nagyon hasonló megoldással állt elő.
Valójában az, amit ma "szerver nélküli" modellnek hívunk, régebbi, mint sok olyan technológia, amelyet ma "natív felhőnek" neveznek, és amelyek szinte ugyanezt biztosítják. Mint már említettük, a kiszolgáló nélküli modellek lényegében csak az évtizedek óta létező SaaS üzleti modell kiterjesztését jelentik.
Azt is érdemes felismerni, hogy a szerver nélküli modell nem FaaS architektúra, bár a kettő között van kapcsolat. A FaaS lényegében a kiszolgáló nélküli architektúra számításközpontú része, de nem képviseli a teljes rendszert.
Akkor miért ez a sok hype? Nos, ahogy az internet elterjedtsége a fejlődő országokban továbbra is az egekbe szökik, úgy nő a számítási erőforrások iránti kereslet is. Például sok gyorsan növekvő e-kereskedelmi ágazattal rendelkező országban egyszerűen nem áll rendelkezésre az ezeken a platformokon történő alkalmazásokhoz szükséges számítási infrastruktúra. Itt jönnek be a fizetett szerver nélküli platformok.
Problémák a szerver nélküli modellekkel
A bökkenő az, hogy a szerver nélküli modelleknek… problémák vannak. Félreértés ne essék: nem azt mondom, hogy önmagukban rosszak, vagy bizonyos körülmények között nem biztosítanak jelentős értéket egyes vállalatok számára. De a "forradalom" fő állítása - hogy a szerver nélküli architektúra gyorsan felváltja a hagyományosat - soha nem válik be.
Ezért.
Programozási nyelvek korlátozott támogatása
A legtöbb szerver nélküli platform csak bizonyos nyelveken írt alkalmazások futtatását teszi lehetővé. Ez súlyosan korlátozza e rendszerek rugalmasságát és alkalmazkodóképességét.
A szerver nélküli platformok a legtöbb fő nyelvet támogatják. Az AWS Lambda és az Azure Functions a nem támogatott nyelveken futó alkalmazások és funkciók burkolóját is biztosítja, bár ez gyakran teljesítményköltséggel jár. Tehát a legtöbb szervezet számára ez a korlátozás általában nem jelent nagy problémát. De itt a lényeg. Állítólag a szerver nélküli modellek egyik előnye, hogy a homályos, ritkán használt programokat olcsóbban lehet használni, mert csak a futási időért kell fizetni. A homályos, ritkán használt programokat pedig gyakran... homályos, ritkán használt programozási nyelveken írják.
Ez aláássa a szerver nélküli modell egyik legfontosabb előnyét.
Eladóhoz kötés
A második probléma a szerver nélküli platformokkal, vagy legalábbis a jelenlegi megvalósításukkal az, hogy működési szinten általában nem hasonlítanak egymásra. Gyakorlatilag nincs szabványosítás az írási funkciók, a telepítés és a kezelés tekintetében. Ez azt jelenti, hogy a szolgáltatások egyik platformról a másikra való áttelepítése rendkívül időigényes.
A szerver nélküli modellre való átállás legnehezebb része nem a számítási funkciók, amelyek általában csak kódrészletek, hanem az, hogy az alkalmazások hogyan kommunikálnak a csatlakoztatott rendszerekkel, például az objektumtárolókkal, az identitáskezeléssel és a sorokkal. A funkciók áthelyezhetők, de az alkalmazás többi része nem. Ez pont az ellentéte az ígért olcsó és rugalmas platformoknak.
Egyesek azzal érvelnek, hogy a szerver nélküli modellek újak, és nem volt idő a működésük szabványosítására. De ezek nem annyira újak, ahogy fentebb megjegyeztem, és sok más felhőtechnológia, például a konténerek már sokkal kényelmesebbé váltak a jó szabványok fejlesztésének és széles körű elfogadásának köszönhetően.
termelékenység
A szerver nélküli platformok számítási teljesítményét nehéz mérni, részben azért, mert a szállítók hajlamosak titokban tartani az információkat. A legtöbben azzal érvelnek, hogy a távoli, kiszolgáló nélküli platformok szolgáltatásai ugyanolyan gyorsan futnak, mint a belső szervereken, néhány elkerülhetetlen késleltetési probléma kivételével.
Néhány bizonyíték azonban ennek ellenkezőjére utal. Azok a funkciók, amelyek korábban nem futottak egy adott platformon, vagy egy ideje nem futottak, némi időt vesz igénybe az inicializáláshoz. Ez valószínűleg annak tudható be, hogy a kódjukat valamilyen kevésbé könnyen elérhető adathordozóra vitték át, bár – akárcsak a benchmarkoknál – a legtöbb gyártó nem árul el az adatok hordozásáról.
Természetesen ezt többféleképpen is megkerülhetjük. Az egyik a szolgáltatások optimalizálása bármely felhőnyelvhez, amelyen a szerver nélküli platform fut, de ez némileg aláássa azt az állítást, hogy ezek a platformok „agilisak”.
Egy másik megközelítés annak biztosítása, hogy a teljesítménykritikus programok rendszeresen fussanak, hogy "frissek" maradjanak. Ez a második megközelítés természetesen kissé ellentétes azzal az állítással, hogy a kiszolgáló nélküli platformok költséghatékonyabbak, mivel csak a programok futásának idejéért kell fizetni. A felhőszolgáltatók új módszereket vezettek be a hidegindítások csökkentésére, de sok közülük „egyhez skálát” (egyhez skálát) igényel, ami aláássa a FaaS eredeti értékét.
A hidegindítási probléma részben megoldható szerver nélküli rendszerek házon belüli futtatásával, de ez saját költségen történik, és továbbra is a jól felszerelt csapatok számára hiányzó lehetőség marad.
Nem futtathat teljes alkalmazásokat
Végül talán a legfontosabb ok, amiért a szerver nélküli architektúrák egyhamar nem váltják fel a hagyományos modelleket, az az, hogy (általában) nem tudnak teljes alkalmazásokat futtatni.
Pontosabban költségszempontból nem praktikus. A sikeres monolitot valószínűleg nem kellene négy tucat függvényből álló halmazzá alakítani, amelyeket nyolc átjáró, negyven sor és egy tucat adatbázispéldány köt össze. Emiatt a szerver nélküli jobban megfelel az új fejlesztéseknek. Gyakorlatilag egyetlen meglévő alkalmazás (architektúra) sem portolható át. Lehet migrálni, de elölről kell kezdeni.
Ez azt jelenti, hogy az esetek túlnyomó többségében a kiszolgáló nélküli platformokat a háttérkiszolgálók kiegészítéseként használják a számításigényes feladatok elvégzésére. Ez nagyon eltér a felhőalapú számítástechnika másik két formájától, a konténerektől és a virtuális gépektől, amelyek holisztikus módot kínálnak a távoli számítástechnika végrehajtására. Ez szemlélteti a mikroszolgáltatásokról a szerver nélküli rendszerekre való átállás egyik kihívását.
Természetesen ez nem mindig probléma. A hatalmas számítási erőforrások rendszeres használatának lehetősége saját hardver vásárlása nélkül valós és tartós előnyökkel járhat számos szervezet számára. De ha egyes alkalmazások belső szervereken, mások pedig szerver nélküli felhőarchitektúrákon találhatók, akkor a menedzsment a bonyolultság új szintjére lép.
Éljen a forradalom?
Mindezen panaszok ellenére nem ellenzem a szerver nélküli megoldásokat önmagában. Őszintén. Csupán a fejlesztőknek meg kell érteniük – különösen, ha először vizsgálják a szerver nélküli modelleket –, hogy ez a technológia nem helyettesíti közvetlenül a szervereket. Ehelyett tekintse meg tippjeinket és forrásainkat és döntse el, hogyan alkalmazza a legjobban ezt a modellt.
Forrás: will.com