Serverless nu înseamnă absența fizică a serverelor. Nu este un „ucigaș” al containerelor și nici o modă trecătoare. Este o nouă abordare pentru construirea sistemelor în cloud. În articolul de astăzi vom discuta despre arhitectura aplicațiilor Serverless, vom analiza rolul furnizorului de servicii Serverless și proiectele open-source. La final, vom aborda întrebările legate de aplicarea Serverless.
Vreau să scriu partea de server a aplicației (chiar dacă este vorba despre un magazin online). Poate fi un chat, un serviciu pentru publicarea de conținut sau un echilibrator de încărcare. În orice caz, va fi destul de complicat: va trebui să pregătesc infrastructura, să definesc dependențele aplicației și să mă gândesc la sistemul de operare al gazdei. Apoi, va fi necesar să actualizez componentele mici care nu afectează funcționarea restului monolitului. Și să nu uităm de scalarea sub încărcare.
Dar ce ar fi dacă am lua containere efemere, în care dependențele necesare sunt deja preinstalate, iar containerele sunt izolate unul de celălalt și de OS-ul gazdei? Monolitul va fi împărțit în microservicii, fiecare dintre care poate fi actualizat și scalat independent de ceilalți. Punând codul într-un astfel de container, voi putea să-l rulez pe orice infrastructură. Este deja mai bine.
Dar dacă nu vreau să configurez containere? Dacă nu vreau să mă gândesc la scalarea aplicației. Dacă nu vreau să plătesc pentru perioada în care containerele sunt pornite, când încărcătura pe serviciu este minimă. Vreau să scriu cod. Să mă concentrez pe logica de afaceri și să lansez produse pe piață cu viteza luminii.
Aceste gânduri m-au dus la computația fără server. Serverless, în acest caz, înseamnă nu absența fizică a serverelor, ci absența grijilor legate de gestionarea infrastructurii.
Ideea este că logica aplicației este împărțită în funcții independente. Acestea au o structură bazată pe evenimente. Fiecare funcție îndeplinește o „microsarcină”. Tot ce se cere de la dezvoltator este să încarce funcțiile în consola oferită de furnizorul de servicii cloud și să le asocieze cu sursele de evenimente. Codul va fi executat la cerere într-un container pregătit automat, iar eu voi plăti doar pentru timpul de execuție.
Să vedem acum cum va arăta procesul de dezvoltare a aplicației.
Din perspectiva dezvoltatorului
Anterior, am început să vorbim despre aplicația pentru un magazin online. În abordarea tradițională, logica principală a sistemului este gestionată de o aplicație monolitică. Iar serverul cu aplicația este pornit constant, chiar dacă nu există sarcini.
Pentru a trece la serverless, împărțim aplicația în microsarcini. Pentru fiecare dintre ele scriem funcția sa. Funcțiile sunt independente una de alta și nu păstrează informații despre stare (stateless). Ele pot fi scrise chiar și în limbi diferite. Dacă una dintre ele „cade”, aplicația în ansamblu nu se va opri. Arhitectura aplicației va arăta astfel:
Împărțirea pe funcții în Serverless este similară cu lucrul cu microservicii. Dar microserviciul poate efectua mai multe sarcini, în timp ce funcția, în ideal, ar trebui să efectueze una singură. Să presupunem că avem sarcina de a aduna statistici și a le afisa la cererea utilizatorului. În abordarea microserviciilor, sarcina este realizată de un singur serviciu cu două puncte de intrare: pentru scriere și pentru citire. În calculul serverless, acestea vor fi două funcții diferite, nelegate între ele. Dezvoltatorul economisește resurse de calcul dacă, de exemplu, statistica se actualizează mai des decât este descărcată.
Funcțiile Serverless trebuie să fie executate într-un interval scurt de timp (timeout), care este definit de furnizorul de serviciu. De exemplu, pentru AWS, timeout-ul este de 15 minute. Asta înseamnă că funcțiile de lungă durată (long-lived) trebuie adaptate la cerințe - acesta este un aspect care diferențiază Serverless de alte tehnologii populare de astăzi (containere și Platform as a Service).
Fiecărei funcții îi atribuim un eveniment. Evenimentul este un trigger pentru acțiune:
Eveniment
Acțiunea pe care o execută funcția
În stocare a fost încărcată o imagine a produsului
Comprimă imaginea și o descarcă în catalog
În baza de date s-a actualizat adresa magazinului fizic
Încărcați pe hărți noua locație
Clientul plătește produsul
Lansați procesarea plății
Evenimentele pot fi cereri HTTP, date în flux, cozi de mesaje și așa mai departe. Sursele de evenimente sunt modificarea sau apariția de date. În plus, funcțiile pot fi activate de un temporizator.
Arhitectura a fost lucrată, iar aplicația a devenit aproape serverless. Următorul pas este să ne îndreptăm către furnizorul de servicii.
Din partea furnizorului
De obicei, computația serverless este oferită de furnizorii de servicii cloud. Aceștia folosesc denumiri diferite: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Vom folosi serviciul prin intermediul consolei sau al contului personal al furnizorului. Codul funcțiilor poate fi încărcat prin una dintre următoarele metode:
- scriend codul în editorii încorporați prin consola web,
- încărcând un arhivă cu codul,
- lucrând cu repozitorii git publice sau private.
Aici configurăm evenimentele care declanșează funcția. La diferiți furnizori, seturile de evenimente pot varia.
Furnizorul a construit și automatizat un sistem Function as a Service (FaaS) pe infrastructura sa:
- Codul funcțiilor ajunge într-un depozit de partea furnizorului.
- Când apare un eveniment, containerele cu mediu pregătit se desfășoară automat pe server. Fiecărui exemplar de funcție îi corespunde un container izolat.
- Din depozit, funcția este trimisă în container, calculată și returnează rezultatul.
- Numărul de evenimente paralele crește - odată cu el, numărul de containere. Sistemul se scalează automat. Dacă utilizatorii nu accesează funcția, aceasta va fi inactivă.
- Furnizorul stabilește timpul de nefuncționare pentru containere - dacă funcțiile nu apar în container în acest interval, acesta este distrus.
Astfel obținem Serverless „din cutie”. Vom plăti pentru serviciu pe baza modelului pay-as-you-go și doar pentru funcțiile utilizate și doar pentru timpul în care au fost utilizate.
Pentru a familiariza dezvoltatorii cu serviciul, furnizorii oferă până la 12 luni de testare gratuită, dar limitează timpul total de calcul, numărul de solicitări pe lună, fondurile sau puterea consumată.
Principalul avantaj al lucrului cu furnizorul este posibilitatea de a nu te îngrijora de infrastructură (servers, mașini virtuale, containere). Din partea sa, furnizorul poate implementa FaaS atât prin dezvoltările proprii, cât și cu ajutorul instrumentelor open-source. Despre ele vom discuta mai departe.
Din partea open source
În ultimii câțiva ani, comunitatea open-source a lucrat activ la instrumentele Serverless. Printre care, cei mai mari jucători de pe piață contribuie la dezvoltarea platformelor fără server:
- Google oferă dezvoltatorilor instrumentul său open-source - . În dezvoltarea sa au participat IBM, RedHat, Pivotal și SAP;
- IBM au lucrat la platforma Serverless , care a devenit apoi un proiect al Apache Foundation;
- de Microsoft au deschis parțial codul platformei .
Dezvoltările sunt în curs și în direcția framework-urilor serverless. și se desfășoară în cadrul clusterelor Kubernetes pregătite anterior, funcționează atât cu Kubernetes, cât și cu Docker Swarm. Framework-ul acționează ca un fel de controler - la cerere pregătește un mediu de execuție în interiorul clusterului, apoi rulează funcția acolo.
Framework-urile lasă loc pentru configurarea instrumentului conform nevoilor proprii. Astfel, în Kubeless, dezvoltatorul poate seta timeout-ul execuției funcției (valoarea implicită este de 180 de secunde). Fission, în încercarea de a rezolva problema pornirii reci, sugerează să mențină o parte a containerelor mereu pornite (deși acest lucru duce la costuri pe resursele inactive). OpenFaaS oferă un set variat de declanșatoare pentru toate gusturile: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs și altele.
Instrucțiunile pentru început pot fi găsite în documentația oficială a framework-urilor. Lucrul cu ele implică un set ceva mai mare de abilități decât atunci când lucrezi cu un furnizor - asta presupune cel puțin abilitatea de a lansa un cluster Kubernetes prin CLI. La maxim, încorporarea altor instrumente open-source (de exemplu, managerul de cozi Kafka).
Indiferent de metoda prin care vom lucra cu Serverless - fie prin intermediul unui furnizor, fie cu ajutorul open-source, vom obține o serie de avantaje și dezavantaje ale abordării Serverless.
Din perspectiva avantajelor și dezavantajelor
Serverless dezvoltă ideile infrastructurii pe containere și abordării microservicii, prin care echipele pot lucra în mod multilingv, fără a fi legate de o singură platformă. Construirea sistemului este simplificată, iar corectarea erorilor devine mai ușoară. Arhitectura microservicii permite adăugarea de noi funcționalități în sistem mult mai repede decât în cazul unei aplicații monolitice.
Serverless reduce și mai mult timpul de dezvoltare, permițând dezvoltatorului să se concentreze exclusiv pe logica de afaceri a aplicației și pe scrierea codului. Ca urmare, timpul de lansare al dezvoltărilor pe piață este redus.
Bonus, obținem scalare automată în funcție de încărcare, iar plătim doar pentru resursele utilizate și doar în perioada în care acestea sunt folosite.
Ca orice tehnologie, Serverless are dezavantaje.
De exemplu, un astfel de dezavantaj poate fi timpul de pornire rece (în medie până la 1 secundă pentru limbaje precum JavaScript, Python, Go, Java, Ruby).
Pe de o parte, durata reală a unui start la rece depinde de multe variabile: limbajul în care a fost scrisă funcția, numărul de biblioteci, volumul de cod, comunicarea cu resurse externe (baze de date sau servere de autentificare). Deoarece dezvoltatorul controlează aceste variabile, el poate reduce timpul de pornire. Dar, pe de altă parte, dezvoltatorul nu poate controla timpul de pornire al containerului - aici totul depinde de furnizor.
Startul la rece poate deveni unul cald atunci când funcția reutilizează un container care a fost început de un eveniment anterior. Această situație va apărea în trei cazuri:
- dacă clienții folosesc frecvent serviciul și numărul de apeluri către funcție crește;
- dacă furnizorul, platforma sau cadrul permit menținerea anumitor containere pornite tot timpul;
- dacă dezvoltatorul rulează funcții la un anumit interval (de exemplu, la fiecare 3 minute).
Pentru multe aplicații, startul la rece nu este o problemă. Aici trebuie să ne bazăm pe tipul și obiectivele serviciului. O întârziere de pornire de o secundă nu este întotdeauna critică pentru o aplicație de afaceri, dar poate deveni critică pentru serviciile medicale. Probabil, în acest caz, abordarea serverless nu mai este potrivită.
Următoarea disfuncționalitate menționată la Serverless este durata scurtă de viață a funcției (timeout-ul în care funcția trebuie să fie executată).
Însă, dacă este necesar să lucrăm cu sarcini de lungă durată, putem utiliza o arhitectură hibridă - combinând Serverless cu o altă tehnologie.
Nu toate sistemele vor putea funcționa pe baza schema Serverless.
Unele aplicații vor continua să stocheze date și starea în timpul execuției. Unele arhitecturi vor rămâne monolitice iar unele funcții vor fi de lungă durată. Totuși (la fel cum s-a întâmplat odată cu tehnologiile cloud, și apoi cu containerele), Serverless este o tehnologie cu un viitor promițător.
În această cheie, mi-ar plăcea să trec treptat la subiectul aplicării abordării Serverless.
Din perspectiva aplicării
În anul 2018, procentul de utilizare a Serverless . Printre companiile care au implementat deja tehnologia în serviciile lor se numără giganți ai pieței precum Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Totuși, trebuie să înțelegem că Serverless nu este o panacee, ci un instrument pentru rezolvarea unui anumit set de probleme:
- Reducerea timpului de inactivitate al resurselor. Nu este necesar să mențineți constant o mașină virtuală pentru servicii la care se apelează rar.
- A procesa datele „în timp real”. A comprima imagini, a tăia fundalul, a schimba codificarea video, a lucra cu senzorii IoT, a efectua operații matematice.
- A „lipi” între ele alte servicii. Un repository Git cu programe interne, un chatbot în Slack cu Jira și cu calendarul.
- A echilibra sarcina. Aici ne vom opri mai în detaliu.
Să presupunem că există un serviciu care primește 50 de persoane. Acesta are o mașină virtuală cu hardware slab. Perioadele de sarcină pe serviciu cresc sporadic. Atunci hardware-ul slab nu poate face față.
Se poate adăuga un echilibror de sarcină în sistem, care va distribui sarcina, să zicem, pe trei mașini virtuale. La acest moment nu putem prognoza cu exactitate sarcina, așadar păstrăm un anumit număr de resurse active „de rezervă”. Și plătim în plus pentru inactivitate.
În această situație putem optimiza sistemul printr-o abordare hibridă: lăsăm o mașină virtuală în spatele echilibrorului de sarcină și punem un link la Serverless Endpoint cu funcții. Dacă sarcina depășește un anumit prag, echilibrorul va porni instanțe de funcții care vor prelua o parte din procesarea solicitărilor.
Astfel, Serverless poate fi utilizat acolo unde este necesară o procesare rară, dar intensă a unui mare număr de solicitări. În acest caz, este mai costisitor să pornești mai multe funcții timp de 15 minute decât să menții constant o mașină virtuală sau un server.
În ciuda tuturor avantajelor calculului fără server, înainte de implementare este important să evaluăm logica aplicației și să înțelegem ce reguli poate rezolva Serverless în cazul concret.
Serverless și Selectel
La Selectel deja prin intermediul panoului nostru de control. Acum construim propria noastră platformă FaaS. Vrem ca dezvoltatorii să poată rezolva sarcinile lor cu ajutorul Serverless printr-o interfață convenabilă și flexibilă.
Dacă aveți idei despre cum ar trebui să fie platforma ideală FaaS și cum doriți să folosiți Serverless în proiectele dumneavoastră, împărtășiți-le în comentarii. Vom lua în considerare sugestiile dumneavoastră în timpul dezvoltării platformei.
Materialele utilizate în articol:
Sursa: habr.com
