EnterpriseTales Kicsi, Kisebb, AWS Lambda
Amióta a legkorszerűbbé válik a monolitok apró, apró modulokra - más néven mikroszolgáltatásokra - történő felosztása, megszoktuk, hogy a hagyományos alkalmazásszervert selejtnek tekintik. Ahelyett, hogy bonyolult futási időre támaszkodna, a szükséges kiszolgáló töredékeket most közvetlenül a technikai kóddal csomagolják, ami egyfajta integrált futásidejű környezetet biztosít. Az egészet több konténerbe csomagolják, egy kis kezelési és felügyeleti funkcióval ellátva, és az alkalmazás készen áll.
Mintha ez nem lenne elég, a kiszolgáló nélküli alkalmazások kifejezés az utóbbi időben egyre gyakrabban jelenik meg. Ismételten az Amazon úttörő az AWS Lambda cégnél. De a versenytársak, mint például az IBM az OpenWhisk-szel, a Google a Cloud Functions-szel vagy a Microsoft az Azure Functions-el, a kezdő blokkokban vannak. Tehát a jövőben teljesen el lehet-e tekinteni a szerverektől és az infrastruktúrától? Ha igen, hogyan kell működnie? És kinek ez még érdekes? Pontosításra van szükség. Ügy az Enterprise Tales-hez!
Mi a szerver nélküli alkalmazás?
A kiszolgáló nélküli alkalmazás kifejezés kissé irritáló, mert azt sugallja, hogy futási környezet nélkül is megteheti saját alkalmazáskódját. Nem ez a helyzet. A kifejezés inkább azt akarja kifejezni, hogy a kiszolgáló nélküli alkalmazások intenzíven használják harmadik fél szolgáltatásait, például felhőalapú adatbázisokat, fájlrendszereket és API-átjárókat (backend szolgáltatásként, vagy röviden BaaS), vagy saját alkalmazáskódot egy ugyanolyan külső, ingatag számítógépen. A tároló lejár (Function as a Service, röviden FaaS). Természetesen mindkét megközelítés kombinációja is megengedett. A Google írja: "A Functions egy könnyű, eseményalapú, aszinkron számítási megoldás, amely lehetővé teszi, hogy kicsi, egycélú funkciókat hozzon létre, amelyek válaszolnak a felhő eseményeire, anélkül, hogy szervert vagy futásidejű környezetet kellene kezelnie."
Szerver nélküli fókuszban
A jelenlegi Java magazin kiterjedten foglalkozik szerver nélküli programozással.
Alkalmazások egy kis semmivel: Szerver nélküli architektúra
A témát a JAXenterre összpontosítva további cikkekkel kísérjük.
Eddig publikálva:
PaaS, BaaS vagy FaaS?
A sok betűszóval összezavarodhat. Míg a PaaS-t (Platform mint szolgáltatás) inkább fejlesztési és telepítési platformként akarják érteni, azaz felelős az alkalmazások és kódjaik kezeléséért, végrehajtásáért és felügyeletéért, a BaaS hasznos háttérrendszereket kínál, mint például adatbázisok, fájlrendszerek vagy hitelesítés Szolgáltatások, amelyeket a fejlesztők közvetlenül megcímezhetnek az alkalmazásaikból.
De hogyan illik a képbe a FaaS? A FaaS ötlete az, hogy az alkalmazásfejlesztő szerveroldali kódot (funkciókat) valósít meg, de futásidejűleg nem alkalmazáskiszolgálót vagy beágyazott szervert használnak, hanem felhőalapú "hontalan számítási konténert". Más szavakkal, a fejlesztő egyszerűen úgy telepíti a funkcióját, hogy a hozzárendelt kódot közvetlenül a felhőbe tölti, és meghatároz egy ravaszt, vagyis egy eseményt, amely kiváltja a kód végrehajtását. Egy ilyen esemény pl. B. egy fájl tárolása a felhő fájlrendszerében, adatrögzítés hozzáadása a felhő adatbázisban vagy egy kérés egy felhő API átjáróval szemben. Amint egy megfelelő esemény elindult, a FaaS funkció külön folyamatban elindul és végrehajtásra kerül. A futásidejű erőforrásokat, például a CPU-t vagy a memóriát, csak tényleges szükség esetén használják.
A FaaS legfőbb egyedi eladási pontja, hogy a háttérkódot futtathatja anélkül, hogy kezelnie kellene saját alkalmazáskiszolgálóit vagy kiszolgálóalkalmazásait. Nincs szükség a konténerek kezelésére sem. A méretezést az FaaS szolgáltató adja. Ingyen? Nos, nem pontosan. A számlák általában hívásokon vagy CPU-időn alapulnak - az AWS Lambda 100 ms-os lépésekben. Minél több vagy annál nagyobb a számításigényes hívás, annál drágább a funkció futás közben.
Kérem, példa?
A FaaS függvény tipikus példája egy háttérfeldolgozó szolgáltatás az erőforrások feldolgozásához, pl. B. Képek. Ha a felhasználó betölti a képet a felhőbe, akkor egy esemény kiváltható a kép felhőalapú fájlrendszerben történő tárolásával, amely elindítja a FaaS funkciót, amely ezután automatikusan generál miniatűröket vagy alternatív képformátumokat. Ezeket a felhőalapú fájlrendszer is tárolja.
De mi a helyzet a felhasználói felület által vezérelt alkalmazásokkal, pl. B. webáruház? Szerver nélküli alkalmazás is elképzelhető itt. Tételezzük fel kiindulópontként, hogy a webáruház felhasználói felületét egyoldalas alkalmazásként (SPA) valósították meg, vagyis az üzleti logika egy része az ügyfélben található. A hitelesítés elvégezhető egy felhőalapú BaaS szolgáltatáson keresztül; egyszerű, olvasott lekérdezések az adatbázisban is, pl. B. a rendelkezésre álló termékek felsorolásához. Bonyolultabb műveleteket is megvalósíthatunk, például egy paraméterezhető keresést egy FaaS függvény segítségével, amely az alapul szolgáló felhő-adatbázis hozzáférését foglalja magában. De hogyan lehet ezt aktiválni? Itt lép működésbe egy API-átjáró, vagyis egyfajta konfigurálható HTTP-szerver, amely a keresési lekérdezést http-kérésként fogadja, az átvitt paramétereket átalakítja függvényünk bemeneti paramétereivé, és később az eredményt adja vissza hasonlóan átalakított HTTP-válasz formájában. Maga az API-átjáró természetesen felhőalapú összetevő is, amelyet csak konfigurálni kell.
A FaaS függvények megvalósításához az Amazon Lambda támogatást nyújt a JavaScript, Python és Java programozási nyelvekhez. További nyelveket tervezünk. A Google Functions viszont csak a JavaScript-et, az IBM OpenWhisk JavaScript-et és a Swift-et támogatja. A legszélesebb támogatást jelenleg a Microsoft Azure Functions biztosítja a JavaScript, C #, Python és PHP használatával.
Állapot és teljesítmény
Értelemszerűen a FaaS függvények nem osztják meg a memóriát, ezért hontalannak kell lenniük. Vagy átalakításokat vagy számításokat hajt végre az átvitt paramétereken, vagy felhőalapú adatbázisokból, fájlrendszerekből vagy keresztalkalmazások gyorsítótáraiból szerzi be a számításhoz szükséges állapotot.
A FaaS funkció elindul, végrehajtásra kerül, majd szükség esetén újra leáll. A kiválasztott programozási nyelvtől vagy a mögöttes futási időtől függően lehet bizonyos indítási késés. JavaScript vagy Python esetében ez alig számít a tényleges kódhoz képest. Kicsit másképp néz ki, amikor a kódot egy JVM-ben hajtják végre. Kedvezőtlen konstellációk esetén ez jelentős indulási késésekhez vezethet. Ez mindig így van, ha két hívás között sok idő telik el, vagy a csúcsok a szokásosnál lényegesen több híváshoz vezetnek. Általában azonban ez a probléma elhanyagolható, hacsak nem valós idejű követelményeket tartalmazó alkalmazást kell végrehajtani.
A FaaS függvények végrehajtási ideje általában korlátozott. Az Amazon Lambda korlátja 300 másodperc. Ha régóta futó folyamatokat szeretne modellezni, meg kell terveznie egy megfelelő architektúrát, amely több FaaS-funkcióra osztja fel őket.
Hogyan működik a tesztelés szerver nélküli rendszerrel?
Mivel egy FaaS függvény kódjának általában nincs szüksége állapotra, vagy egy könnyen kigúnyolható harmadik fél rendszeréből szerzi be, az egységteszteket nagyon könnyű végrehajtani. De mi a helyzet az integrációs tesztekkel? Itt egy kicsit nehezebbé válik, mivel ezek nagymértékben függenek a különböző felhőszolgáltatásoktól. Felmerül tehát a kérdés, hogy ezek a harmadik féltől származó rendszerek mennyire alkalmasak a teszt forgatókönyvekre. Szánják-e még tesztekben is? Vannak olyan tesztcsonkok, amelyek ellen lehet fejleszteni? Mennyire könnyen tölthetők be a rendszerek értelmes vizsgálati adatokkal? És milyen stratégiát alkalmaz a szolgáltató a számlázási teszteken a felhőben? Nagyon kevés esetben biztos, hogy teljes egészében integrációs vagy elfogadási teszteket lehet végrehajtani a helyi számítógépen, vagy a felhőhöz nem csatlakozó számítógépen.
Mondja el az Enterprise Tales oszlopban Lars Röwekamp, Sven Kölpin és Arne Limburg (nyitott ismeretek) érdekes történeteket és informatív betekintést nyújt a Java EE-re és az Enterprise Java színes világára.
Következtetés
A rendkívül egyszerű modellt pozitívan kell értékelni. Fejlesztőként nem kell más miatt aggódnom, mint az alkalmazás kódja. Nincs szükség szerverek vagy tárolók kezelésére. Költségek csak akkor merülnek fel, amikor az alkalmazás terhelést generál, amely automatikusan skálázódik. Ez különösen észrevehető a csúcsok esetében, amelyekhez általában további infrastruktúrát kell készen tartani. A FaaS funkció új verziójának telepítése szintén nagyon egyszerű. Egyszerűen töltse fel a kódot, vagy Java esetén előzetesen csomagolja be, és elérhetővé válik az új verzió.
Az eladó bezárását minden bizonnyal hátránynak kell tekinteni. A FaaS függvények írhatók olyan szabványos nyelvekre, mint a Java vagy a JS, de minden más gyártóspecifikus, pl. B. a kiváltó okok és a csatlakoztatott BaaS. Alkalmazás Amazonról a Google-ra történő továbbadása minden további nélkül nem lehetséges. Ez a lépés különösen azt jelentené, hogy az összekapcsolt rendszereket, például a felhőfájl-rendszereket vagy a felhőalapú adatbázisokat is át kell hordozni. Helyi megoldásokra és absztrakciós keretekre lenne szükség a hordozhatóság növelése érdekében.
Az API-változások, az új jelentősebb kiadások vagy a megváltozott árképzési modell valós kockázattá válhat. Egy másik hátrány az üzleti logika ügyfélre történő áthelyezéséből származhat. Ha több különböző klienst szeretne, akkor ezt a kódot többször is végre kell hajtania. A különféle szolgáltatók jelenlegi SLA-jai szintén hátrányos helyzetbe kerülhetnek egyes esetekben. Az Amazon maximum 1000 párhuzamos végrehajtást engedélyez a Lambdas-ban. Ez eleinte soknak tűnik, de a jelenlegi modell szerint ez az összes lambda-függvény maximálisának tekinthető. Egy intenzív teszt megbéníthatja a termelő környezetet.
Igazságosság kedvéért el kell mondani, hogy még mindig nagyon korai szakaszban vagyunk, és ezért feltételezhető, hogy az említett problémák egy része már a szolgáltatók napirendjén van. Ezt szem előtt tartva: Maradjon velünk ...!