EnterpriseTales malé, menšie, AWS Lambda
Od tej doby, čo sa stalo najmodernejším procesom rozdelenia monolitov na čisté malé moduly - aka mikroslužby -, sme si zvykli na to, že tradičný aplikačný server sa považuje za vyradený. Namiesto toho, aby sa spoliehali na ťažký runtime, sú teraz potrebné fragmenty servera dodávané priamo s technickým kódom, čo mu dodáva akési integrované runtime prostredie. Celé je to zabalené v niekoľkých kontajneroch, ktoré sú vybavené malou funkciou správy a monitorovania a aplikácia je pripravená.
Akoby to nestačilo, výraz serverové aplikácie sa v nedávnej minulosti objavoval čoraz viac. Amazon je opäť priekopníkom v AWS Lambda. V počiatočných blokoch sú ale konkurenti ako IBM s openWhisk, Google s Cloud Functions alebo Microsoft s Azure Functions. Je teda možné v budúcnosti úplne upustiť od serverov a infraštruktúry? Ak áno, ako by to malo fungovať? A pre koho je to vlastne zaujímavé? Je potrebné objasnenie. Prípad pre Enterprise Tales!
Čo je to aplikácia bez servera?
Pojem aplikácia bez servera je trochu dráždivý, pretože naznačuje, že pre svoj vlastný aplikačný kód sa môžete zaobísť bez runtime prostredia. Toto nie je ten prípad. Termín chce skôr vyjadriť, že aplikácie bez servera intenzívne využívajú služby tretích strán, ako sú cloudové databázy, súborové systémy a brány API (backend ako služba, alebo skrátene BaaS) alebo váš vlastný aplikačný kód v rovnako externom, nestabilnom počítači Platnosť kontajnera vyprší (funkcia ako služba, skrátene FaaS). Kombinácie oboch prístupov sú samozrejme tiež povolené. Google píše: „Functions je ľahké, na udalostiach založené asynchrónne výpočtové riešenie, ktoré vám umožňuje vytvárať malé, jednoúčelové funkcie, ktoré reagujú na cloudové udalosti bez nutnosti spravovať server alebo runtime prostredie.“
Serverové zameranie
Aktuálny časopis Java sa intenzívne venuje programovaniu bez serverov.
Aplikácie bez nádychu: Architektúra bez servera
Problematiku zameranú na JAXenter sprevádzame ďalšími článkami na túto tému.
Zatiaľ zverejnené:
PaaS, BaaS alebo FaaS?
S mnohými skratkami môžete byť zmätení. Zatiaľ čo PaaS (Platform as a Service) chce byť chápaná viac ako platforma pre vývoj a nasadenie, t. J. Je zodpovedná za správu, vykonávanie a monitorovanie aplikácií a ich kódu, BaaS poskytuje užitočné backendové systémy, ako sú databázy, systémy súborov alebo autentifikácia. Služby, ktoré môžu vývojári priamo osloviť z ich aplikácií.
Ako však zapadá FaaS do obrazu? Myšlienka FaaS je, že vývojár aplikácií implementuje kód na strane servera (funkcie), ale ako runtime sa nepoužíva žiadny aplikačný server alebo zabudovaný server, ale cloudový „bezstavový výpočtový kontajner“. Inými slovami, vývojári jednoducho nasadia svoje funkcie načítaním súvisiaceho kódu priamo do cloudu a definovaním spúšťača, teda udalosti, ktorá spúšťa vykonávanie kódu. Takáto udalosť môže napr. B. uloženie súboru v cloudovom súborovom systéme, pridanie dátového záznamu do cloudovej databázy alebo požiadavka proti cloudovej bráne API. Len čo sa spustí vhodná udalosť, spustí sa funkcia FaaS a vykoná sa v samostatnom procese. Runtime prostriedky ako CPU alebo pamäť sa používajú iba v prípade, že je to skutočne potrebné.
Hlavným jedinečným miestom predaja FaaS je to, že môžete nechať spustiť koncový kód bez nutnosti spravovať svoje vlastné aplikačné servery alebo serverové aplikácie. Rovnako nie je potrebné spravovať kontajnery. Mierka je daná poskytovateľom FaaS. Zadarmo? No nie úplne. Účty sú spravidla založené na hovoroch alebo na čase procesora - s AWS Lambda v krokoch po 100 ms. Čím viac alebo viac výpočtovo náročnejších hovorov, tým je funkcia za behu nákladnejšia.
Príklad prosím?
Typickým príkladom funkcie FaaS by bola služba spracovania backendu na spracovanie zdrojov, napr. B. Obrázky. Ak používateľ načíta obrázok do cloudu, udalosť by sa mohla spustiť uložením obrázka do cloudového súborového systému, ktorý spustí funkciu FaaS, ktorá potom automaticky generuje miniatúry alebo alternatívne formáty obrázkov. Tieto sú zase uložené aj v cloudovom súborovom systéme.
Čo však s aplikáciami založenými na používateľskom rozhraní, napr. B. webový obchod? Tiež si tu možno predstaviť aplikáciu bez servera. Predpokladajme ako východisko, že používateľské rozhranie webového obchodu bolo implementované ako jednostránková aplikácia (SPA), t. J. Časť obchodnej logiky je v klientovi. Autentifikáciu je možné vykonať prostredníctvom cloudovej služby BaaS; jednoduché, prečítajte si dotazy aj v databáze, napr. B. zoznam dostupných produktov. Mohli by sme implementovať zložitejšie akcie, ako je napríklad parametrizovateľné vyhľadávanie, pomocou funkcie FaaS, ktorá zapuzdruje prístup k základnej cloudovej databáze. Ako sa to však aktivuje? Tu vstupuje do hry brána API, teda akýsi konfigurovateľný server HTTP, ktorý prijíma náš vyhľadávací dopyt ako požiadavku http, transformuje prenesené parametre na vstupné parametre našej funkcie a neskôr vráti výsledok v podobe podobne transformovanej odpovede HTTP. Samotná brána API je samozrejme tiež cloudovým komponentom, ktorý je potrebné iba nakonfigurovať.
Na implementáciu funkcií FaaS ponúka Amazon Lambda podporu pre programovacie jazyky JavaScript, Python a Java. Plánované sú ďalšie jazyky. Funkcia Google Functions na druhej strane podporuje iba JavaScript, IBM OpenWhisk JavaScript a Swift. Najširšiu podporu v súčasnosti poskytujú Microsoft Azure Functions s JavaScriptom, C #, Pythonom a PHP.
Stav a výkonnosť
Podľa definície funkcie FaaS nezdieľajú pamäť, a preto by mali byť bez štátnej príslušnosti. Vykonávate iba transformácie alebo výpočty na prenesených parametroch alebo stav požadovaný na výpočet získate z cloudových databáz, súborových systémov alebo medzipamäťových medzipamäťí.
Spustí sa, vykoná sa a potom sa podľa potreby opäť ukončí funkcia FaaS. V závislosti od zvoleného programovacieho jazyka alebo základného runtime môže existovať určitá latencia spustenia. V prípade JavaScriptu alebo Pythonu to vo vzťahu k skutočnému kódu ťažko záleží. Vyzerá to trochu inak, keď sa kód vykonáva v prostredí JVM. Za nepriaznivých konštelácií to môže viesť k značnému oneskoreniu pri spustení. Toto je vždy prípad, ak medzi dvoma hovormi uplynie veľa času alebo vrcholy vedú k podstatne väčšiemu počtu hovorov ako obvykle. Spravidla však možno tento problém zanedbať, pokiaľ nie je potrebné implementovať aplikáciu s požiadavkami v reálnom čase.
Funkcie FaaS sú zvyčajne časovo obmedzené. Amazon Lambda má limit 300 sekúnd. Ak chcete modelovať dlhotrvajúce procesy, musíte navrhnúť zodpovedajúcu architektúru, ktorá ich rozdelí do niekoľkých funkcií FaaS.
Ako funguje testovanie bez servera?
Pretože kód funkcie FaaS zvyčajne nepotrebuje stav alebo ho získava zo ľahko zosmiešneného systému tretej strany, je veľmi ľahké implementovať jednotkové testy. Čo však integračné testy? Tu je to o niečo ťažšie, pretože tieto závisia vo veľkej miere od rôznych cloudových služieb. Vyvstáva teda otázka, ako dobre sú tieto systémy tretích strán vhodné pre testovacie scenáre. Je vôbec určený na použitie pri testoch? Existujú testovacie pahýly, proti ktorým sa dá vyvinúť? Ako ľahko je možné systémy naplniť zmysluplnými údajmi o testoch? A akú stratégiu používa poskytovateľ na testovacie procesy fakturácie v cloude? Iste, vo veľmi málo prípadoch bude možné vykonať integračné alebo akceptačné testy výlučne na vašom lokálnom počítači alebo na počítači, ktorý nie je pripojený k cloudu.
Povedzte to v stĺpci Enterprise Tales Lars Röwekamp, Sven Kölpin a Arne Limburg (otvorené vedomosti) zaujímavé príbehy a poskytuje informatívne informácie o prostredí Java EE a farebnom svete Enterprise Java.
Záver
Mimoriadne jednoduchý model treba hodnotiť kladne. Ako vývojár sa nemusím starať o nič iné ako o kód aplikácie. Nie je potrebné spravovať servery alebo kontajnery. Náklady vzniknú až vtedy, keď aplikácia vygeneruje záťaž, ktorá sa automaticky zmenší. Je to zvlášť viditeľné v prípade špičiek, pre ktoré by sa za normálnych okolností musela udržiavať pripravená ďalšia infraštruktúra. Nasadenie novej verzie funkcie FaaS je tiež veľmi ľahké. Jednoducho nahrajte kód alebo v prípade Java ho vopred zabalte a nová verzia je k dispozícii.
Zaistenie predajcu sa určite musí považovať za nevýhodu. Funkcie FaaS je možné písať v štandardných jazykoch, ako sú Java alebo JS, ale všetko ostatné je špecifické pre výrobcu, napr. B. spúšťače a pripojený BaaS. Prenos aplikácie z Amazonu na Google by bez ďalších okolkov nebol možný. Tento krok by predovšetkým znamenal, že by sa tiež museli portovať pripojené systémy, ako napríklad cloudové súborové systémy alebo cloudové databázy. Tu by boli žiaduce on-premise riešenia a rámce na abstrakciu na zvýšenie prenosnosti.
Zmeny API, nové významné vydania alebo zmenený cenový model sa môžu stať skutočným rizikom. Ďalšou nevýhodou môže byť presun obchodnej logiky na klienta. Ak chcete niekoľko rôznych klientov, musíte tento kód implementovať niekoľkokrát. Súčasné SLA rôznych poskytovateľov by sa tiež mohli v jednotlivých prípadoch javiť ako nevýhoda. Amazon povoľuje maximálne 1 000 paralelných popráv Lambdasa. To spočiatku znie ako veľa, ale podľa súčasného modelu to možno považovať za maximum nad všetkými funkciami lambda. Intenzívny test by mohol paralyzovať produktívne prostredie.
Aby sme boli spravodliví, je potrebné povedať, že sme stále vo veľmi rannej fáze, a preto sa dá predpokladať, že niektoré zo spomenutých problémov sú už v agende poskytovateľov. Majte na pamäti toto: Zostaňte naladení ...!