EnterpriseTales Small, Smaller, AWS Lambda
De când a devenit de ultimă oră împărțirea monolitilor în module mici, îngrijite - alias microservicii - ne-am obișnuit cu faptul că serverul tradițional de aplicații este considerat a fi abandonat. În loc să se bazeze pe un timp de rulare greu, fragmentele de server necesare sunt acum pachetate direct cu codul tehnic, oferindu-i un fel de mediu de rulare integrat. Întregul lucru este ambalat în mai multe containere, prevăzute cu puține funcționalități de gestionare și monitorizare, iar aplicația este gata.
De parcă nu ar fi fost de ajuns, termenul de aplicații fără server a apărut tot mai mult în trecutul recent. Din nou, Amazon este un pionier al AWS Lambda. Dar concurenții precum IBM cu openWhisk, Google cu Cloud Functions sau Microsoft cu Azure Functions se află în blocurile inițiale. Deci, se pot renunța complet la servere și infrastructură în viitor? Dacă da, cum ar trebui să funcționeze? Și pentru cine este chiar interesant? Este nevoie de clarificări. Un caz pentru Enterprise Tales!
Ce este o aplicație fără server?
Termenul de aplicație fără server este puțin iritant, deoarece sugerează că puteți face fără un mediu de rulare pentru propriul cod de aplicație. Nu este cazul. Mai degrabă, termenul vrea să exprime faptul că aplicațiile fără server utilizează intens serviciile terțe, cum ar fi bazele de date bazate pe cloud, sistemele de fișiere și gateway-urile API (backend ca serviciu sau BaaS pe scurt) sau propriul cod de aplicație într-un computer la fel de extern, volatil. Containerul expiră (funcționează ca serviciu, pe scurt, FaaS). Combinările ambelor abordări sunt, desigur, permise. Google scrie: „Functions este o soluție de calcul asincronă ușoară, bazată pe evenimente, care vă permite să creați funcții mici, cu un singur scop, care să răspundă la evenimentele din cloud fără a fi nevoie să gestionați un server sau un mediu de rulare.
Focalizare fără server
Actuala revistă Java tratează pe larg programarea fără server.
Aplicații cu o atingere de nimic: Arhitectură fără server
Însoțim accentul pe JAXenter cu alte articole pe această temă.
Publicat până acum:
PaaS, BaaS sau FaaS?
Cu numeroasele acronime vă puteți confunda. În timp ce PaaS (Platform as a Service) vrea să fie înțeles mai mult ca o platformă de dezvoltare și implementare, adică este responsabilă pentru gestionarea, executarea și monitorizarea aplicațiilor și a codului acestora, BaaS oferă sisteme utile de backend, cum ar fi baze de date, sisteme de fișiere sau autentificare. Servicii care pot fi adresate direct de dezvoltatori din aplicațiile lor.
Dar cum se încadrează FaaS în imagine? Ideea de la FaaS este că dezvoltatorul aplicației implementează codul (funcțiile) din partea serverului, dar niciun server de aplicație sau server încorporat nu este folosit ca runtime, ci un „container de calcul fără stat” bazat pe cloud. Cu alte cuvinte, dezvoltatorul își desfășoară pur și simplu funcția încărcând codul asociat direct în cloud și definind un declanșator, adică un eveniment care declanșează executarea codului. Un astfel de eveniment poate de ex. B. stocarea unui fișier în sistemul de fișiere cloud, adăugarea unei înregistrări de date în baza de date cloud sau o cerere împotriva unui gateway API cloud. De îndată ce a fost declanșat un eveniment adecvat, funcția FaaS este pornită și executată într-un proces separat. Resursele de execuție, cum ar fi CPU sau memorie, sunt, prin urmare, utilizate numai atunci când există o nevoie reală.
Principalul punct unic de vânzare al FaaS este că puteți executa codul backend fără a fi nevoie să vă gestionați propriile servere de aplicații sau aplicații de server. De asemenea, nu este nevoie să gestionați containerele. Scalarea este dată de furnizorul FaaS. Gratuit? Ei bine, nu exact. De regulă, facturile se bazează pe apeluri sau pe durata procesorului - cu AWS Lambda în trepte de 100 ms. Cu cât apelul este mai intens sau mai intens din punct de vedere al calculului, cu atât funcția în timpul rulării este mai scumpă.
Exemplu vă rog?
Un exemplu tipic de funcție FaaS ar fi un serviciu de procesare backend pentru procesarea resurselor, de ex. B. Imagini. Dacă un utilizator încarcă o imagine în cloud, un eveniment poate fi declanșat prin stocarea imaginii în sistemul de fișiere bazat pe cloud, care declanșează funcția FaaS, care apoi generează automat miniaturi sau formate de imagine alternative. La rândul lor, acestea sunt stocate și în sistemul de fișiere bazat pe cloud.
Dar ce zici de aplicațiile bazate pe interfața de utilizare, de ex. B. un magazin online? O aplicație fără server este de asemenea concepută aici. Să presupunem ca punct de plecare că interfața de utilizare a magazinului web a fost implementată ca o aplicație cu o singură pagină (SPA), adică o parte a logicii de afaceri se află în client. Autentificarea se poate face printr-un serviciu BaaS bazat pe cloud; interogări simple, citite și în baza de date, de ex. B. pentru a enumera produsele disponibile. Am putea implementa acțiuni mai complexe, cum ar fi o căutare parametrizabilă utilizând o funcție FaaS care încapsulează accesul la baza de date cloud subiacentă. Dar cum este activat acest lucru? Aici intră în joc un gateway API, adică un fel de server HTTP configurabil care primește interogarea noastră de căutare ca o cerere http, transformă parametrii transferați în parametrii de intrare ai funcției noastre și apoi returnează rezultatul sub forma unui răspuns HTTP transformat la fel. Gateway-ul API în sine este, desigur, și o componentă bazată pe cloud care trebuie configurată doar.
Pentru a implementa funcțiile FaaS, Amazon Lambda oferă suport pentru limbajele de programare JavaScript, Python și Java. Sunt planificate alte limbi. Funcțiile Google, pe de altă parte, acceptă numai JavaScript, IBM OpenWhisk JavaScript și Swift. Cel mai larg suport este oferit în prezent de Microsoft Azure Functions cu JavaScript, C #, Python și PHP.
Stare și performanță
Prin definiție, funcțiile FaaS nu împărtășesc memoria și, prin urmare, ar trebui să fie apatrizi. Fie efectuați doar transformări sau calcule asupra parametrilor transferați sau obțineți starea necesară pentru calcul din baze de date bazate pe cloud, sisteme de fișiere sau cache-uri cu aplicații încrucișate.
O funcție FaaS este pornită, executată și apoi terminată din nou atunci când este necesar. În funcție de limbajul de programare selectat sau de timpul de rulare subiacent, poate exista o anumită latență de pornire. În cazul JavaScript sau Python, acest lucru contează cu greu în raport cu codul propriu-zis. Arată puțin diferit atunci când codul este executat într-o JVM. În constelațiile nefavorabile, acest lucru poate duce la întârzieri considerabile la pornire. Acesta este întotdeauna cazul în care trece mult timp între două apeluri sau vârfuri, ducând la mai multe apeluri decât de obicei. Cu toate acestea, de regulă, această problemă poate fi neglijată dacă nu trebuie implementată o aplicație cu cerințe în timp real.
Funcțiile FaaS sunt de obicei limitate în timpul lor de execuție. Amazon Lambda are o limită de 300 de secunde. Dacă doriți să modelați procese de lungă durată, trebuie să proiectați o arhitectură corespunzătoare care să le împartă în mai multe funcții FaaS.
Cum funcționează testarea cu serverless?
Deoarece codul unei funcții FaaS de obicei nu are nevoie de o stare sau îl obține de la un sistem terț ușor de batjocorit, testele unitare sunt foarte ușor de implementat. Dar ce zici de testele de integrare? Devine puțin mai dificil aici, deoarece acestea depind în mare măsură de diferitele servicii cloud. Așadar, se pune întrebarea cât de bine sunt adecvate aceste sisteme terțe pentru scenarii de testare. Este chiar destinat să fie utilizat în teste? Există butoane de testare împotriva cărora se pot dezvolta? Cât de ușor pot fi completate sistemele cu date de test semnificative? Și ce strategie folosește furnizorul pentru testarea facturării în cloud? În foarte puține cazuri, cu siguranță va fi posibil să efectuați teste de integrare sau acceptare în întregime pe computerul dvs. local sau pe un computer care nu este conectat la cloud.
Spuneți în coloana Enterprise Tales Lars Röwekamp, Sven Kölpin și Arne Limburg (cunoștințe deschise) povești interesante și oferă informații informative despre Java EE și lumea colorată a Enterprise Java.
Concluzie
Modelul extrem de simplu trebuie evaluat pozitiv. Ca dezvoltator, nu trebuie să îmi fac griji cu privire la altceva decât codul aplicației. Nu este nevoie să gestionați servere sau containere. Costurile sunt suportate numai atunci când aplicația generează încărcare, care se modifică automat. Acest lucru se remarcă în special în cazul vârfurilor, pentru care ar trebui să fie menținute în mod normal o infrastructură suplimentară. Implementarea unei noi versiuni a unei funcții FaaS este, de asemenea, foarte ușoară. Pur și simplu încărcați codul sau, în cazul Java, împachetați-l în prealabil, iar noua versiune este disponibilă.
Blocarea furnizorului trebuie să fie văzută cu siguranță ca un dezavantaj. Funcțiile FaaS pot fi scrise în limbaje standard precum Java sau JS, dar orice altceva este specific producătorului, de ex. B. declanșatoarele și BaaS conectat. Portarea unei aplicații de la Amazon către Google nu ar fi posibilă fără alte întrebări. În special, acest pas ar însemna că sistemele conectate, cum ar fi sistemele de fișiere cloud sau bazele de date cloud, ar trebui, de asemenea, să fie portate. Soluții locale și cadre de abstractizare pentru creșterea portabilității ar fi de dorit aici.
Modificările API, noile versiuni majore sau un model de preț modificat pot deveni un risc real. Un alt dezavantaj poate rezulta din mutarea logicii de afaceri către client. Dacă doriți mai mulți clienți diferiți, trebuie să implementați acest cod de mai multe ori. SLA-urile actuale ale diferiților furnizori s-ar putea dovedi, de asemenea, a fi un dezavantaj în cazuri individuale. Amazon permite maxim 1.000 de execuții paralele ale Lambdas. La început, sună foarte mult, dar, conform modelului actual, poate fi văzut ca maxim pe toate funcțiile lambda. Un test intensiv ar putea paraliza mediul productiv.
Pentru a fi corect, trebuie spus că suntem încă într-o fază foarte timpurie și, prin urmare, se poate presupune că unele dintre problemele menționate sunt deja pe agenda furnizorilor. Având în vedere acest lucru: rămâneți la curent ...!