Deși tehnologiile fără server au câștigat rapid popularitate în ultimii ani, există încă multe concepții greșite și temeri asociate cu acestea. Dependența furnizorilor, instrumentele, managementul costurilor, pornirea la rece, monitorizarea și ciclul de viață al dezvoltării sunt toate subiecte fierbinți când vine vorba de tehnologiile fără server. În acest articol, vom explora unele dintre subiectele menționate, precum și vom împărtăși sfaturi și link-uri către surse utile de informații pentru a ajuta începătorii să creeze aplicații fără server puternice, flexibile și rentabile.
Concepții greșite despre tehnologiile fără server
Mulți oameni cred că procesarea fără server și fără server (, FaaS) sunt aproape același lucru. Asta înseamnă că diferența nu este prea mare și merită să introduci o noutate. Deși AWS Lambda a fost una dintre vedetele perioadei de glorie fără server și unul dintre cele mai populare elemente ale arhitecturii fără server, totuși, această arhitectură este mult mai mult decât FaaS.
Principiul de bază din spatele tehnologiilor fără server este că nu trebuie să vă faceți griji cu privire la gestionarea și scalarea infrastructurii dvs., plătiți doar pentru ceea ce utilizați. Multe servicii îndeplinesc aceste criterii - AWS DynamoDB, S3, SNS sau SQS, Graphcool, Auth0, Now, Netlify, Firebase și multe altele. În general, serverless înseamnă folosirea întregii puteri a cloud computingului fără a fi nevoie de a gestiona infrastructura și de a o optimiza pentru scalare. De asemenea, înseamnă că securitatea la nivel de infrastructură nu mai este preocuparea ta, ceea ce reprezintă un beneficiu uriaș având în vedere dificultatea și complexitatea îndeplinirii standardelor de securitate. În cele din urmă, nu trebuie să cumpărați infrastructura care vi se oferă.
Serverless poate fi considerat o „stare de spirit”: o anumită mentalitate atunci când proiectăm soluții. Evitați abordările care necesită întreținere a oricărei infrastructuri. Cu o abordare fără server, petrecem timp rezolvând sarcini care afectează direct proiectul și aduc beneficii utilizatorilor noștri: creăm o logică de afaceri durabilă, dezvoltăm interfețe cu utilizatorul și dezvoltăm API-uri adaptabile și de încredere.
De exemplu, dacă este posibil să evitați gestionarea și menținerea unei platforme de căutare de text liber, atunci asta vom face. Această abordare a construirii aplicațiilor poate accelera foarte mult timpul de lansare pe piață, deoarece nu mai trebuie să vă gândiți la gestionarea infrastructurii complexe. Eliminați responsabilitățile și costurile gestionării infrastructurii și concentrați-vă pe construirea aplicațiilor și serviciilor de care clienții dvs. au nevoie. Patrick Debois a numit această abordare , termenul este adoptat în comunitatea fără server. Funcțiile ar trebui gândite ca o legătură către servicii ca module implementabile (în loc să implementeze o bibliotecă întreagă sau o aplicație web). Acest lucru oferă o granularitate incredibilă pentru gestionarea implementării și modificărilor aplicației. Dacă nu puteți implementa funcții în acest fel, atunci poate indica faptul că funcțiile îndeplinesc prea multe sarcini și trebuie refactorizate.
Unii sunt confuzi de dependența de furnizor atunci când dezvoltă aplicații cloud. Același lucru este valabil și cu tehnologiile fără server, iar aceasta nu este o concepție greșită. Din experiența noastră, construirea de aplicații fără server pe AWS, combinată cu capacitatea AWS Lambda de a combina alte servicii AWS, face parte din puterea arhitecturilor fără server. Acesta este un bun exemplu de sinergie, atunci când rezultatul combinației este mai mult decât suma termenilor. Încercarea de a evita dependența de furnizor poate întâmpina și mai multe probleme. Când lucrați cu containere, este mai ușor să vă gestionați propriul strat de abstractizare între furnizorii de cloud. Dar când vine vorba de soluții fără server, efortul nu va da roade, mai ales dacă se ia în considerare de la început rentabilitatea. Asigurați-vă că aflați cum furnizează furnizorii servicii. Unele servicii specializate se bazează pe puncte de integrare cu alți furnizori și pot oferi conectivitate plug-and-play imediată. Este mai ușor să oferiți un apel Lambda de la un punct final API gateway decât să trimiteți cererea prin proxy către un container sau o instanță EC2. Graphcool oferă o configurare ușoară cu Auth0, care este mai ușor decât utilizarea instrumentelor de autentificare terță parte.
Alegerea furnizorului potrivit pentru aplicația dvs. fără server este o decizie arhitecturală. Când creați o aplicație, nu vă așteptați să reveniți într-o zi la gestionarea serverelor. Alegerea unui furnizor de cloud nu este diferită de alegerea de a utiliza containere sau o bază de date sau chiar un limbaj de programare.
Considera:
- De ce servicii aveți nevoie și de ce.
- Ce servicii oferă furnizorii de cloud și cum le puteți combina cu soluția FaaS aleasă.
- Ce limbaje de programare sunt suportate (cu tastare dinamică sau statică, compilată sau interpretată, care sunt benchmark-urile, care este performanța la pornire la rece, ce este ecosistemul open source etc.).
- Care sunt cerințele dvs. de securitate (SLA, 2FA, OAuth, HTTPS, SSL etc.).
- Cum să vă gestionați CI/CD și ciclurile de dezvoltare software.
- De ce soluții de infrastructură ca cod puteți profita.
Dacă extindeți o aplicație existentă și adăugați treptat funcționalitate fără server, acest lucru poate limita oarecum capabilitățile disponibile. Cu toate acestea, aproape toate tehnologiile fără server oferă un fel de API (prin REST sau cozi de mesaje) care vă permite să creați extensii independente de nucleul aplicației și cu o integrare ușoară. Căutați servicii cu API-uri clare, documentație bună și o comunitate puternică și nu puteți greși. Ușurința de integrare poate fi adesea o măsură cheie și este probabil unul dintre principalele motive pentru care AWS a avut atât de mult succes de când Lambda a fost lansat în 2015.
Când Serverless este bun
Tehnologiile serverless pot fi aplicate aproape peste tot. Cu toate acestea, avantajele lor nu se limitează la un singur mod de aplicare. Bariera de intrare pentru cloud computing astăzi este atât de scăzută datorită tehnologiilor fără server. Dacă dezvoltatorii au o idee, dar nu știu cum să gestioneze infrastructura cloud și să optimizeze costurile, atunci nu trebuie să caute un fel de inginer care să o facă. Dacă un startup dorește să construiască o platformă, dar se teme că costurile ar putea scăpa de sub control, poate apela cu ușurință la soluții fără server.
Datorită economiilor de costuri și ușurinței de scalare, soluțiile serverless sunt aplicabile în mod egal atât pentru sistemele interne, cât și pentru cele externe, până la o aplicație web cu un public de mai multe milioane. Conturile sunt măsurate mai degrabă decât în euro, ci în cenți. Închirierea celei mai simple instanțe de AWS EC2 (t1.micro) pentru o lună va costa 15 EUR, chiar dacă nu faci nimic cu ea (cine nu a uitat niciodată să o dezactiveze?!). În comparație, pentru a atinge acest nivel de cheltuieli în aceeași perioadă de timp, ar trebui să rulați un Lambda de 512 MB timp de 1 secundă de aproximativ 3 milioane de ori. Și dacă nu folosești această funcție, atunci nu plătești nimic.
Deoarece serverless este în principal bazat pe evenimente, este destul de ușor să adăugați o infrastructură fără server la sistemele mai vechi. De exemplu, folosind AWS S3, Lambda și Kinesis, puteți crea un serviciu de analiză pentru un sistem vechi de vânzare cu amănuntul care poate primi date printr-un API.
Majoritatea platformelor fără server acceptă mai multe limbi. Cel mai adesea este Python, JavaScript, C#, Java și Go. De obicei, nu există restricții privind utilizarea bibliotecilor în toate limbile, așa că puteți utiliza bibliotecile open source preferate. Cu toate acestea, este recomandabil să nu abuzați de dependențe, astfel încât funcțiile dumneavoastră să funcționeze optim și să nu anuleze beneficiile scalabilității uriașe a aplicațiilor dumneavoastră fără server. Cu cât mai multe pachete trebuie încărcate în container, cu atât va dura mai mult pornirea la rece.
O pornire la rece este atunci când trebuie să inițializați containerul, timpul de execuție și gestionarea erorilor înainte de a le utiliza. Din acest motiv, întârzierea în execuția funcțiilor poate fi de până la 3 secunde, iar aceasta nu este cea mai bună opțiune pentru utilizatorii nerăbdători. Cu toate acestea, pornirile la rece au loc la primul apel, după câteva minute de funcționare inactiv. Mulți consideră că aceasta este o supărare minoră care poate fi rezolvată prin ping-ul regulat al funcției pentru a o menține inactiv. Sau ignoră cu totul acest aspect.
Deși AWS a lansatCu toate acestea, bazele de date SQL nu sunt ideale pentru această aplicație, deoarece depind de conexiuni pentru a efectua tranzacții, care pot deveni rapid un blocaj cu trafic intens pe AWS Lambda. Da, dezvoltatorii îmbunătățesc în mod constant Aurora fără server și ar trebui să experimentați cu ea, dar astăzi soluții NoSQL precum. Cu toate acestea, nu există nicio îndoială că această situație se va schimba foarte curând.
Setul de instrumente impune și o mulțime de restricții, în special în domeniul testării locale. Deși există soluții precum Docker-Lambda, DynamoDB Local și LocalStack, acestea necesită multă muncă și o cantitate semnificativă de configurare. Cu toate acestea, toate aceste proiecte sunt dezvoltate în mod activ, așa că este doar o chestiune de timp până când setul de instrumente să atingă nivelul de care avem nevoie.
Impactul tehnologiilor fără server asupra ciclului de dezvoltare
Deoarece infrastructura dvs. este doar o configurație, puteți defini și implementa cod folosind scripturi, cum ar fi scripturi shell. Sau puteți recurge la soluții de clasă configurație ca cod, cum ar fi . Deși acest serviciu nu oferă configurație pentru toate zonele, vă permite să definiți resurse specifice de utilizat ca funcții Lambda. Adică, acolo unde CloudFormation te defectează, poți scrie propria ta resursă (funcția Lambda) care va închide acest decalaj. În acest fel, puteți face orice, chiar și să configurați dependențe în afara mediului dvs. AWS.
Deoarece totul este doar configurație, vă puteți personaliza scripturile de implementare pentru anumite medii, regiuni și utilizatori, mai ales dacă utilizați soluții de infrastructură ca cod precum CloudFormation. De exemplu, puteți implementa o copie a infrastructurii pentru fiecare ramură din depozit, astfel încât să le puteți testa complet izolat în timpul dezvoltării. Acest lucru accelerează drastic feedback-ul pentru dezvoltatori atunci când doresc să înțeleagă dacă codul lor funcționează adecvat într-un mediu live. Managerii nu trebuie să-și facă griji cu privire la costul implementării mai multor medii, deoarece plătesc doar pentru utilizarea reală.
DevOps are mai puține griji, deoarece trebuie doar să se asigure că dezvoltatorii au configurația corectă. Nu mai trebuie să gestionați instanțele, echilibratorii sau grupurile de securitate. Prin urmare, termenul NoOps este din ce în ce mai folosit, deși este încă important să poți configura infrastructura, mai ales când vine vorba de configurarea IAM și optimizarea resurselor cloud.
Există instrumente de monitorizare și vizualizare foarte puternice precum Epsagon, Thundra, Dashbird și IOPipe. Acestea vă permit să monitorizați starea actuală a aplicațiilor dvs. fără server, să furnizați înregistrare și urmărire, să captați valorile de performanță și blocajele arhitecturii, să efectuați analize și prognoze ale costurilor și multe altele. Acestea nu numai că oferă inginerilor, dezvoltatorilor și arhitecților DevOps o vedere cuprinzătoare asupra performanței aplicațiilor, dar permit și managerilor să monitorizeze situația în timp real, cu costuri de resurse pe secundă și previziuni ale costurilor. Este mult mai dificil să organizezi asta cu o infrastructură gestionată.
Proiectarea aplicațiilor fără server este mult mai ușoară, deoarece nu trebuie să implementați servere web, să gestionați mașini sau containere virtuale, servere de corecție, sisteme de operare, gateway-uri de internet etc. Prin abstracția tuturor acestor responsabilități, o arhitectură fără server se poate concentra asupra nucleului - soluţia.nevoile afacerii şi ale clienţilor.
În timp ce setul de instrumente ar putea fi mai bun (se îmbunătățește în fiecare zi), dezvoltatorii se pot concentra pe implementarea logicii de afaceri și pe cea mai bună distribuție a complexității aplicației în diferite servicii din cadrul arhitecturii. Gestionarea aplicațiilor fără server se bazează pe evenimente și este extrasă de furnizorul de cloud (de exemplu, SQS, evenimente S3 sau fluxuri DynamoDB). Prin urmare, dezvoltatorii trebuie doar să scrie logica de afaceri pentru a răspunde la anumite evenimente și nu trebuie să-și facă griji despre cum să implementeze cel mai bine bazele de date și cozile de mesaje sau cum să organizeze lucrul optim cu datele în anumite stocări hardware.
Codul poate fi rulat și depanat local, ca în orice proces de dezvoltare. Testarea unitară rămâne aceeași. Capacitatea de a implementa o întreagă infrastructură de aplicații cu o configurație de stivă personalizată permite dezvoltatorilor să obțină rapid feedback important, fără a se gândi la costul testării sau la impactul asupra mediilor costisitoare gestionate.
Instrumente și tehnici pentru construirea de aplicații fără server
Nu există o modalitate specifică de a construi aplicații fără server. Precum și un set de servicii pentru această sarcină. AWS este liderul soluțiilor puternice fără server astăzi, dar uitați-vă și la , и . Dacă utilizați AWS, abordarea recomandată pentru colectarea aplicațiilor este (SAM), mai ales atunci când utilizați C#, deoarece Visual Studio are instrumente grozave. SAM CLI poate face tot ceea ce poate face Visual Studio, astfel încât nu veți pierde nimic dacă treceți la alt IDE sau editor de text. Desigur, SAM funcționează și cu alte limbi.
Dacă scrieți în alte limbi, Serverless Framework este un excelent instrument open source care vă permite să configurați orice cu fișiere de configurare YAML foarte puternice. Framework-ul Serverless acceptă și diverse servicii cloud, așa că îl recomandăm celor care caută o soluție multi-cloud. Are o comunitate imensă care a creat o grămadă de pluginuri pentru orice nevoie.
Pentru testarea locală, instrumentele open source Docker-Lambda, Serverless Local, DynamoDB Local și LocalStack sunt potrivite. Tehnologiile fără server sunt încă în stadiile incipiente de dezvoltare, la fel ca și instrumentele pentru ele, așa că atunci când vă configurați pentru scenarii complexe de testare, va trebui să lucrați din greu. Cu toate acestea, simpla implementare a stivei într-un mediu și testarea acolo este incredibil de ieftină. Și nu trebuie să faceți o copie locală exactă a mediilor cloud.
Utilizați AWS Lambda Layers pentru a reduce dimensiunea pachetelor implementate și pentru a accelera descărcările.
Utilizați limbajele de programare potrivite pentru sarcini specifice. Diferite limbi au propriile avantaje și dezavantaje. Există multe benchmark-uri, dar JavaScript, Python și C# (.NET Core 2.1+) sunt lideri în ceea ce privește performanța AWS Lambda. AWS Lambda a introdus recent API-ul Runtime, care vă permite să specificați limbajul și mediul dorit de rulare, deci experimentați.
Păstrați dimensiunile pachetelor mici pentru implementare. Cu cât sunt mai mici, cu atât se încarcă mai repede. Evitați să utilizați biblioteci mari, mai ales dacă utilizați câteva funcții din ele. Dacă programați în JavaScript, utilizați un instrument de compilare precum Webpack pentru a vă optimiza construcția și pentru a include doar ceea ce aveți cu adevărat nevoie. .NET Core 3.0 are QuickJit și Tired Compilation care îmbunătățește performanța și ajută foarte mult la pornirile la rece.
Dependența funcțiilor fără server pe evenimente poate face dificilă coordonarea logicii de afaceri la început. În acest sens, cozile de mesaje și mașinile de stare pot fi incredibil de utile. Funcțiile Lambda se pot apela între ele, dar faceți acest lucru numai dacă nu vă așteptați la un răspuns ("declanșați și uitați") - nu doriți să fiți facturat pentru așteptarea finalizării unei alte funcții. Cozile de mesaje sunt utile pentru izolarea părților logicii de afaceri, gestionarea blocajelor aplicațiilor și procesarea tranzacțiilor (folosind cozile FIFO). Funcțiile AWS Lambda pot fi atribuite cozilor SQS ca cozi de mesaje blocate care țin evidența mesajelor eșuate pentru analize ulterioare. Funcțiile AWS Step (mașini de stat) sunt foarte utile pentru gestionarea proceselor complexe care necesită înlănțuirea funcțiilor. În loc ca o funcție Lambda să apeleze o altă funcție, funcțiile pas pot coordona tranzițiile de stare, pot transmite date între funcții și pot gestiona starea globală a funcțiilor. Acest lucru vă permite să definiți condițiile de reîncercare sau ce să faceți când apare o anumită eroare - un instrument foarte puternic în anumite condiții.
Concluzie
În ultimii ani, tehnologiile fără server s-au dezvoltat într-un ritm fără precedent. Există anumite concepții greșite asociate cu această schimbare de paradigmă. Prin abstracția infrastructurii și gestionarea scalarii, soluțiile fără server oferă beneficii semnificative, de la procese simplificate de dezvoltare și DevOps până la reduceri masive ale costurilor operaționale.
Deși abordarea fără server nu este lipsită de dezavantaje, există modele de design robuste care pot fi utilizate pentru a construi aplicații robuste fără server sau pentru a integra elemente fără server în arhitecturile existente.
Sursa: www.habr.com