Deși tehnologiile serverless au câștigat rapid popularitate în ultimii ani, există încă multe neînțelegeri și temeri asociate cu acestea. Dependența de furnizor, instrumentele, gestionarea costurilor, pornirea la rece, monitorizarea și ciclul de viață al dezvoltării - toate aceste subiecte sunt discutate activ atunci când se vorbește despre tehnologiile serverless. În acest articol, vom explora câteva dintre temele menționate și vom împărtăși sfaturi și linkuri către surse de informații utile, care vor ajuta începătorii să creeze aplicații serverless puternice, flexible și economice.
Neînțelegeri legate de tehnologiile serverless
Mulți consideră că serverlessness și procesarea datelor non-server (, FaaS) sunt aproape același lucru. Asta înseamnă că diferența nu este mare și ar merita să implementăm inovația. Deși AWS Lambda a fost una dintre «stelele» ascensiunii tehnologiilor serverless și unul dintre cele mai populare elemente ale arhitecturii serverless, această arhitectură reprezintă mai mult decât FaaS.
Principiul de bază al tehnologiilor serverless este că nu trebuie să vă faceți griji cu privire la gestionarea și scalarea infrastructurii, plătiți doar pentru ceea ce folosiți. Aceste criterii se potrivesc cu numeroase servicii - AWS DynamoDB, S3, SNS sau SQS, Graphcool, Auth0, Now, Netlify, Firebase și multe altele. În general, serverlessness implică utilizarea tuturor posibilităților de calcul în cloud fără a fi necesară gestionarea infrastructurii și optimizarea acesteia pentru scalare. De asemenea, aceasta înseamnă că securitatea la nivel de infrastructură nu mai este problema dumneavoastră, ceea ce reprezintă un avantaj enorm, având în vedere dificultatea și complexitatea respectării standardelor de securitate. În sfârșit, nu trebuie să cumpărați infrastructura pusă la dispoziția dumneavoastră.
Serverlessness poate fi considerată «o stare de spirit»: o anumită mentalitate în proiectarea soluțiilor. Evitați abordările care necesită întreținerea oricărei infrastrucuri. Cu o abordare serverless, ne petrecem timpul rezolvând probleme care influențează direct proiectul și aduc beneficii utilizatorilor noștri: creăm o logică de afaceri robustă, dezvoltam interfețe utilizator și scriem API-uri adaptative și fiabile.
De exemplu, dacă putem evita gestionarea și întreținerea platformei de căutare pe text liber, așa vom proceda. Această abordare a construcției aplicațiilor poate accelera semnificativ lansarea produsului pe piață, deoarece nu mai trebuie să vă faceți griji cu privire la gestionarea unei infrastructuri complexe. Eliminați responsabilitățile și costurile de gestionare a infrastructurii și concentrați-vă pe crearea aplicațiilor și serviciilor de care au nevoie clienții dumneavoastră. Patrick Debois a numit această abordare , acest termen fiind acceptat în comunitatea serverless. Funcțiile trebuie considerate ca un liant pentru servicii sub formă de module implementabile (în locul implementării unei biblioteci întregi sau a unei aplicații web). Aceasta asigură o granularitate incredibilă în gestionarea implementării și modificărilor din aplicație. Dacă nu puteți implementa funcțiile în acest mod, ar putea însemna că funcțiile au prea multe sarcini și ar trebui refactorizate.
Unii se simt incomodați de dependența de furnizor în dezvoltarea aplicațiilor cloud. Aceleași lucruri se aplică și tehnologiilor serverless, iar puțin probabil ca aceasta să fie rezultatul unei confuzii. Din experiența noastră, crearea de aplicații serverless pe AWS, în combinație cu capacitatea AWS Lambda de a unifica alte servicii AWS - toate acestea contribuie, în oarecare măsură, la beneficiile arhitecturilor serverless. Este un exemplu bun de sinergie, când rezultatul combinării este mai mare decât suma părților. Încercând să evitați dependența de furnizor, s-ar putea să vă confruntați cu probleme și mai mari. Când lucrați cu containere, este mai ușor să gestionați propriul nivel de abstractizare între furnizorii cloud. Dar când vine vorba despre soluții serverless, eforturile nu se vor justifica, mai ales dacă luați în considerare eficiența economică de la început. Asigurați-vă că înțelegeți cum oferă furnizorii servicii. Unele servicii specializate depind de puncte de integrare cu alți furnizori și pot oferi din cutie posibilitatea de conectare în stil plug-and-play. Este mai simplu să invocați Lambda dintr-un punct final API Gateway decât să intermediați o cerere într-un container sau un exemplu EC2. Graphcool oferă o configurare ușoară cu Auth0, ceea ce este mai simplu decât utilizarea unor instrumente externe de autentificare.
Alegerea furnizorului potrivit pentru aplicația dumneavoastră serverless este o decizie la nivel de arhitectură. Când creați o aplicație, nu vă așteptați să reveniți vreodată la gestionarea serverelor. Alegerea unui furnizor cloud nu diferă de alegerea utilizării containerelor sau a unei baze de date, sau chiar a unui limbaj de programare.
Reflectați la:
- Ce servicii aveți nevoie și de ce.
- Ce servicii oferă furnizorii cloud și cum le puteți integra cu soluția dvs. FaaS aleasă.
- Ce limbaje de programare sunt suportate (cu tipizare dinamică sau statică, compilate sau interpretate, ce benchmark-uri există, ce performanțe la pornire rece, care este ecosistemul open source etc.).
- Care sunt cerințele dvs. de securitate (SLA, 2FA, OAuth, HTTPS, SSL etc.).
- Cum să gestionați CI/CD-ul și ciclurile de dezvoltare software.
- Ce soluții din clasa infrastructure-as-code puteți utiliza.
Dacă extindeți o aplicație existentă și adăugați funcții serverless în mod incremental, acest lucru poate restricționa oarecum funcționalitățile disponibile. Cu toate acestea, aproape toate tehnologiile serverless oferă anumite API-uri (prin REST sau cozi de mesaje) care permit crearea de extensii independent de nucleul aplicației și cu integrare simplă. Căutați servicii cu API-uri clare, documentație bună și o comunitate puternică, și nu veți da greș. Simplitatea integrării poate fi adesea o metrică cheie și, probabil, aceasta este una dintre principalele motive pentru succesul AWS de când a fost lansată Lambda în 2015.
Când este util serverless
Tehnologiile serverless pot fi aplicate practic oriunde. Cu toate acestea, avantajele lor nu se limitează doar la metodele de aplicare. Pragul de intrare pentru calculul în cloud este astăzi atât de scăzut datorită tehnologiilor serverless. Dacă dezvoltatorii au o idee, dar nu știu cum să gestioneze infrastructura cloud și să optimizeze costurile, nu trebuie să caute un inginer pentru asta. Dacă o start-up vrea să creeze o platformă, dar se teme că cheltuielile ar putea scăpa de sub control, poate apela cu ușurință la soluții serverless.
Datorită economiei de costuri și a ușurinței în scalare, soluțiile serverless sunt la fel de aplicabile atât pentru sistemele interne, cât și pentru cele externe, până la aplicații web cu milioane de utilizatori. Facturile sunt măsurate mai degrabă în cenți decât în euro. Închirierea celui mai simplu exemplu de AWS EC2 (t1.micro) pe parcursul unei luni va costa €15, chiar dacă nu faceți nimic cu el (cine nu a uitat vreodată să-l oprească?). Spre comparație, pentru a atinge un nivel similar de cheltuieli în aceeași perioadă, ar trebui să rulați Lambda cu 512 MB timp de 1 secundă de aproximativ 3 milioane de ori. Și dacă nu folosiți această funcție, atunci nu plătiți nimic.
Deoarece tehnologia serverless depinde în principal de evenimente, este destul de simplu să adăugați o infrastructură serverless în sisteme mai vechi. De exemplu, folosind AWS S3, Lambda și Kinesis, puteți crea un serviciu de analiză pentru un sistem de retail vechi care să poată primi date prin API.
Cele mai multe platforme fără server suportă diverse limbaje. De obicei, sunt Python, JavaScript, C#, Java și Go. În general, nu există limitări în utilizarea bibliotecilor pentru aceste limbaje, așa că puteți folosi bibliotecile open source preferate. Totuși, este recomandat să nu abuzați de dependențe, astfel încât funcțiile dvs. să ruleze optim și să nu anuleze avantajele scalabilității uriașe a aplicațiilor dvs. fără server. Cu cât trebuie să încărcați mai multe pachete în container, cu atât mai lungă va fi durata de pornire rece.
Pornirea rece se referă la situația în care este necesară inițializarea containerului, a mediului de execuție și a gestionării erorilor înainte de a putea fi utilizate. Din această cauză, întârzierea în executarea funcțiilor poate ajunge la 3 secunde, ceea ce nu este ideal pentru utilizatorii nerăbdători. Totuși, pornirile reci apar la prima accesare după câteva minute de inactivitate a funcției. Așadar, mulți consideră că aceasta este o neplăcere minoră ce poate fi ocolită prin ping-uirea regulată a funcției, pentru a o menține activă. Sau o ignoră complet.
Deși AWS a lansat, totuși bazele de date SQL nu sunt ideale pentru astfel de aplicații, deoarece la executarea tranzacțiilor depind de conexiuni, care pot deveni rapid un punct critic în cazul unui trafic mare pe AWS Lambda. Da, dezvoltatorii îmbunătățesc constant Serverless Aurora și merită să experimentați cu ea, însă astăzi soluțiile NoSQL precumsunt mult mai potrivite pentru sistemele fără server. Cu toate acestea, este fără îndoială că această situație se va schimba foarte curând.
Instrumentele impun, de asemenea, numeroase limitări, în special în ceea ce privește testarea locală. Deși există soluții precum Docker-Lambda, DynamoDB Local și LocalStack, acestea necesită muncă minuțioasă și o cantitate semnificativă de configurare. Totuși, toate aceste proiecte sunt în continuă dezvoltare, așa că este doar o chestiune de timp până când instrumentele vor atinge nivelul necesar.
Impactul tehnologiilor fără server asupra ciclului de dezvoltare
Deoarece infrastructura dvs. este doar o configurație, puteți scrie și desfășura codul folosind scripturi, cum ar fi scripturile shell. Sau puteți folosi soluții de tip configuration-as-code precum . Deși acest serviciu nu oferă o configurare pentru toate domeniile, permite totuși specificarea de resurse concrete pentru utilizarea ca funcții Lambda. Acolo unde CloudFormation eșuează, poți scrie propria resursă (funcție Lambda) care să umple acest gol. Astfel, poți face orice, chiar să configurezi dependențe în afara mediu AWS.
Deoarece totul este doar o configurare, poți parametriza scripturile tale de desfășurare pentru medii, regiuni și utilizatori specifici, mai ales dacă aplici soluții de tip infrastructure-as-code, cum ar fi CloudFormation. De exemplu, poți desfășura o copie a infrastructurii pentru fiecare ramură din depozit, pentru a o testa complet izolat în timpul dezvoltării. Aceasta accelerează radical feedbackul dezvoltatorilor atunci când doresc să înțeleagă dacă codul lor funcționează corect în mediu live. Managerii nu trebuie să-și facă griji cu privire la costul desfășurării mai multor medii, deoarece se plătește doar utilizarea efectivă.
DevOps se confruntă cu mai puține griji, deoarece trebuie doar să se asigure că dezvoltatorii au configurația corectă. Nu mai este necesară gestionarea instanțelor, a echilibratoarelor de sarcină sau a grupurilor de securitate. De aceea, termenul NoOps este din ce în ce mai des folosit, deși este încă important să știi cum să configurezi infrastructura, mai ales în ceea ce privește configurația IAM și optimizarea resurselor de cloud.
Există instrumente foarte puternice pentru monitorizare și vizualizare, cum ar fi Epsagon, Thundra, Dashbird și IOPipe. Acestea permit urmărirea stării curente a aplicațiilor fără server, oferind jurnale și trasări, înregistrând metrici de performanță și puncte slabe ale arhitecturii, realizând analize și previziuni de costuri, și multe altele. Ele nu doar că oferă inginerilor DevOps, dezvoltatorilor și arhitecților o imagine detaliată asupra performanței aplicațiilor, ci permit și managerilor să urmărească situația în timp real, cu costuri pe resurse pe secunde și previziuni de cheltuieli. Organizarea acestuia într-o infrastructură gestionată este mult mai dificilă.
Proiectarea aplicațiilor fără server este mult mai simplă, deoarece nu este necesar să desfășurați servere web, să gestionați mașini virtuale sau containere, să actualizați servere, sisteme de operare, gateway-uri de internet etc. Abstractizarea de toate aceste responsabilități permite arhitecturii fără server să se concentreze pe ceea ce este esențial — satisfacerea nevoilor afacerii și clienților.
Deși instrumentarul ar putea fi mai bun (se îmbunătățește în fiecare zi), dezvoltatorii pot să se concentreze pe implementarea logicii de afaceri și pe distribuirea optimă a complexității aplicației între diferite servicii în cadrul arhitecturii. Gestionarea aplicațiilor fără server se efectuează pe baza evenimentelor și este abstractizată de furnizorul de cloud (de exemplu, SQS, evenimente S3 sau fluxuri DynamoDB). Prin urmare, dezvoltatorii trebuie să scrie doar logica de afaceri pentru a reacționa la anumite evenimente, fără a-și face griji cu privire la modul de implementare a bazelor de date și a cozilor de mesaje sau cum să organizeze lucrul optim cu datele în spațiile de stocare hardware specifice.
Codul poate fi executat și depanat local, la fel ca în orice proces de dezvoltare. Testarea modulară rămâne neschimbată. Posibilitatea de a desfășura întreaga infrastructură a aplicației folosind o configurație personalizată a stivei permite dezvoltatorilor să primească rapid feedback important, fără a se gândi la costul testării sau impactul asupra mediilor gestionate costisitoare.
Instrumente și metode pentru construirea aplicațiilor fără server
Nu există o modalitate specifică de a construi aplicații fără server, la fel cum nu există un set de servicii pentru această sarcină. Liderul dintre soluțiile puternice fără server astăzi este AWS, dar acordați atenție și , și . Dacă utilizați AWS, ca abordare pentru construirea aplicațiilor, se poate recomanda (SAM), în special atunci când utilizați C#, deoarece în Visual Studio există un instrumentar excelent. SAM CLI poate face tot ce face Visual Studio, așa că nu veți pierde nimic dacă treceți la un alt IDE sau editor de text. Desigur, SAM funcționează și cu alte limbaje.
Dacă scrieți în alte limbi, atunci Serverless Framework este un instrument open source excelent, care permite configurarea oricăror aspecte prin intermediul unor fișiere YAML foarte puternice. De asemenea, Serverless Framework suportă diferite servicii cloud, așa că îl recomandăm celor care caută o soluție multi-cloud. Are o comunitate vastă, care a creat o mulțime de pluginuri pentru orice necesitate.
Pentru testarea locală, instrumentele open source Docker-Lambda, Serverless Local, DynamoDB Local și LocalStack sunt foarte potrivite. Tehnologiile serverless sunt încă în stadiu incipient de dezvoltare, la fel ca și instrumentele pentru acestea, așa că, la configurarea unor scenarii de testare complexe, va trebui să depuneți eforturi considerabile. Totuși, desfășurarea unui stack în mediu și testarea acolo sunt incredibil de ieftine. Și nu trebuie să faceți o copie locală exactă a mediilor cloud.
Pentru a reduce dimensiunile pachetelor desfășurate și a accelera încărcarea, utilizați AWS Lambda Layers.
Folosiți limbajele de programare potrivite pentru sarcinile specifice. Fiecare limbaj are propriile sale 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. Recent, AWS Lambda a introdus Runtime API, care permite specificarea limbajului dorit și a mediului de execuție, așa că experimentați.
Mențineți o dimensiune mică a pachetelor pentru desfășurare. Cu cât sunt mai mici, cu atât se încarcă mai rapid. Evitați utilizarea bibliotecilor mari, mai ales dacă utilizați doar câteva funcționalități din ele. Dacă programați în JavaScript, folosiți instrumente de construire precum Webpack pentru a optimiza construcția și a include doar ceea ce aveți cu adevărat nevoie. În .NET Core 3.0 există QuickJit și Compilare în Pași, care îmbunătățesc performanța și ajută mult la lansările reci.
Dependența funcțiilor fără server de evenimente poate îngreuna inițial coordonarea logicii de afaceri. În acest sens, cozii de mesaje și finite automate pot fi extrem de utile. Funcțiile Lambda pot invoca unele dintre ele, dar faceți asta doar dacă nu așteptați un răspuns („lansat și uitat”) — nu doriți să primiți o factură pentru a aștepta finalizarea unei alte funcții. Cozile de mesaje sunt utile pentru a izola părțile logicii de afaceri, pentru a gestiona punctele de congestie ale aplicațiilor și pentru a procesa tranzacții (prin cozi FIFO). Funcțiile AWS Lambda pot fi asociate cu cozi SQS ca și cozi „suspendate” de mesaje, care urmăresc mesajele eșuate pentru o analiză ulterioară. Funcțiile AWS Step Functions (finite automate) sunt foarte utile pentru gestionarea proceselor complexe care necesită crearea de lanțuri de funcții. În loc ca o funcție Lambda să invoce o altă funcție, funcțiile Step pot coordona tranzițiile de stare, pot transfera date între funcții și pot gestiona starea globală a funcțiilor. Acest lucru permite definirea condițiilor de retry sau ce trebuie să faceți în cazul unei erori specifice — un instrument extrem de puternic în anumite condiții.
Concluzie
În ultimii ani, tehnologiile fără server au evoluat cu o viteză nemaivăzută. Această schimbare de paradigmă este însoțită de anumite concepții greșite. Datorită abstractizării infrastructurii și gestionării scalării, soluțiile fără server oferă beneficii semnificative: de la simplificarea dezvoltării și a proceselor DevOps, până la o reducere considerabilă a cheltuielilor operaționale.
Și deși abordarea fără server nu este lipsită de dezavantaje, există metode de încredere și modele de proiectare prin care pot fi create aplicații rezistente fără server sau integrate elemente fără server în arhitecturi existente.
Sursa: habr.com
