Serverless nu este despre absența fizică a serverelor. Acesta nu este un ucigaș de containere sau o tendință trecătoare. Aceasta este o nouă abordare a construirii sistemelor în cloud. În articolul de astăzi vom aborda arhitectura aplicațiilor Serverless, să vedem ce rol joacă furnizorul de servicii Serverless și proiectele open-source. În cele din urmă, să vorbim despre problemele legate de utilizarea Serverless.
Vreau să scriu o parte server a unei aplicații (sau chiar un magazin online). Acesta ar putea fi un chat, un serviciu de publicare de conținut sau un echilibrator de încărcare. În orice caz, vor fi multe bătăi de cap: va trebui să pregătiți infrastructura, să determinați dependențele aplicației și să vă gândiți la sistemul de operare gazdă. Apoi va trebui să actualizați componente mici care nu afectează funcționarea restului monolitului. Ei bine, să nu uităm de scalarea sub sarcină.
Ce se întâmplă dacă luăm containere efemere, în care dependențele necesare sunt deja preinstalate, iar containerele în sine sunt izolate unul de celălalt și de sistemul de operare gazdă? Vom împărți monolitul în microservicii, fiecare dintre acestea putând fi actualizat și scalat independent de celelalte. Punând codul într-un astfel de container, îl pot rula pe orice infrastructură. Deja mai bine.
Ce se întâmplă dacă nu doriți să configurați containere? Nu vreau să mă gândesc la scalarea aplicației. Nu vreau să plătesc pentru containerele care funcționează inactiv atunci când sarcina serviciului este minimă. Vreau să scriu cod. Concentrați-vă pe logica de afaceri și aduceți produse pe piață cu viteza luminii.
Asemenea gânduri m-au condus la calcularea fără server. Serverless în acest caz înseamnă nu absența fizică a serverelor, ci absența durerilor de cap în managementul infrastructurii.
Ideea este că logica aplicației este împărțită în funcții independente. Au o structură de eveniment. Fiecare funcție îndeplinește o „microsarcină”. Tot ceea ce este necesar de la dezvoltator este să încarce funcțiile în consola furnizată de furnizorul de cloud și să le coreleze cu sursele de evenimente. Codul va fi executat la cerere într-un container pregătit automat și voi plăti doar pentru timpul de execuție.
Să vedem cum va arăta acum procesul de dezvoltare a aplicației.
Din partea dezvoltatorului
Mai devreme am început să vorbim despre o aplicație pentru un magazin online. În abordarea tradițională, logica principală a sistemului este realizată de o aplicație monolitică. Și serverul cu aplicația rulează constant, chiar dacă nu există încărcare.
Pentru a trece la serverless, împărțim aplicația în microtask-uri. Scriem propria noastră funcție pentru fiecare dintre ele. Funcțiile sunt independente una de cealaltă și nu stochează informații de stare (stateless). Ele pot fi chiar scrise în diferite limbi. Dacă unul dintre ele „cade”, întreaga aplicație nu se va opri. Arhitectura aplicației va arăta astfel:
Împărțirea în funcții în Serverless este similară cu lucrul cu microservicii. Dar un microserviciu poate îndeplini mai multe sarcini și, în mod ideal, o funcție ar trebui să îndeplinească una. Să ne imaginăm că sarcina este de a colecta statistici și de a le afișa la cererea utilizatorului. În abordarea cu microservicii, o sarcină este efectuată de un serviciu cu două puncte de intrare: scriere și citire. În calculul fără server, acestea vor fi două funcții diferite care nu sunt legate între ele. Dezvoltatorul economisește resurse de calcul dacă, de exemplu, statisticile sunt actualizate mai des decât sunt descărcate.
Funcțiile serverless trebuie executate într-o perioadă scurtă de timp (timeout), care este determinată de furnizorul de servicii. De exemplu, pentru AWS, timpul de expirare este de 15 minute. Aceasta înseamnă că funcțiile cu durată lungă de viață vor trebui modificate pentru a se potrivi cerințelor - acesta este ceea ce distinge Serverless de alte tehnologii populare astăzi (containere și Platform as a Service).
Atribuim un eveniment fiecărei funcții. Un eveniment este un declanșator pentru o acțiune:
eveniment
Acțiunea pe care o îndeplinește funcția
O imagine a produsului a fost încărcată în depozit.
Comprimați imaginea și încărcați într-un director
Adresa fizică a magazinului a fost actualizată în baza de date
Încărcați o nouă locație în hărți
Clientul plateste marfa
Începeți procesarea plății
Evenimentele pot fi solicitări HTTP, date în flux, cozi de mesaje și așa mai departe. Sursele evenimentelor sunt modificări sau apariții ale datelor. În plus, funcțiile pot fi declanșate de un temporizator.
Arhitectura a fost elaborată, iar aplicația aproape că a devenit fără server. Apoi mergem la furnizorul de servicii.
Din partea furnizorului
De obicei, calcularea fără server este oferită de furnizorii de servicii cloud. Ele sunt numite diferit: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Vom folosi serviciul prin consola sau contul personal al furnizorului. Codul funcției poate fi descărcat în unul dintre următoarele moduri:
- scrie codul în editoarele încorporate prin consola web,
- descărcați arhiva cu codul,
- lucrați cu depozite git publice sau private.
Aici setăm evenimentele care apelează funcția. Seturile de evenimente pot diferi de la diferiți furnizori.
Furnizorul a construit și automatizat sistemul Function as a Service (FaaS) pe infrastructura sa:
- Codul funcției ajunge în stocare pe partea furnizorului.
- Când are loc un eveniment, containerele cu un mediu pregătit sunt implementate automat pe server. Fiecare instanță de funcție are propriul său container izolat.
- Din stocare, funcția este trimisă în container, calculată și returnează rezultatul.
- Numărul de evenimente paralele este în creștere - numărul de containere este în creștere. Sistemul se scalează automat. Dacă utilizatorii nu accesează funcția, aceasta va fi inactivă.
- Furnizorul stabilește timpul de inactivitate pentru containere - dacă în acest timp funcțiile nu apar în container, acesta este distrus.
În acest fel, scoatem Serverless din cutie. Vom plăti pentru serviciu folosind modelul pay-as-you-go și numai pentru acele funcții care sunt utilizate și numai pentru timpul în care au fost utilizate.
Pentru a introduce dezvoltatorii în acest serviciu, 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 consumul de energie.
Principalul avantaj al lucrului cu un furnizor este abilitatea de a nu vă face griji cu privire la infrastructură (servere, mașini virtuale, containere). La rândul său, furnizorul poate implementa FaaS atât folosind propriile dezvoltări, cât și folosind instrumente open-source. Să vorbim mai departe despre ele.
Din partea open source
Comunitatea open-source a lucrat activ la instrumentele Serverless în ultimii doi ani. Cei mai mari jucători de pe piață contribuie și la dezvoltarea platformelor fără server:
- Google oferă dezvoltatorilor instrumentul său open-source - . IBM, RedHat, Pivotal și SAP au participat la dezvoltarea sa;
- IBM a lucrat pe o platformă Serverless , care a devenit apoi un proiect al Fundației Apache;
- Microsoft a deschis parțial codul platformei .
De asemenea, sunt în curs de dezvoltare în direcția cadrelor fără server. и implementat în clustere Kubernetes pregătite în prealabil, 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 rulare în interiorul clusterului, apoi lansează o funcție acolo.
Framework-urile lasă loc pentru configurarea instrumentului în funcție de nevoile dvs. Deci, în Kubeless, un dezvoltator poate configura timpul de expirare a execuției funcției (valoarea implicită este de 180 de secunde). Fisiune, în încercarea de a rezolva problema pornirii la rece, sugerează menținerea unor containere în funcțiune tot timpul (deși acest lucru implică costuri de oprire a resurselor). Iar OpenFaaS oferă un set de declanșatori pentru fiecare gust și culoare: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT și altele.
Instrucțiunile pentru începere pot fi găsite în documentația oficială a cadrelor. Lucrul cu ei necesită să aveți puțin mai multe abilități decât atunci când lucrați cu un furnizor - aceasta este cel puțin capacitatea de a lansa un cluster Kubernetes prin intermediul CLI. Cel mult, includeți alte instrumente open-source (de exemplu, managerul de cozi Kafka).
Indiferent de modul în care lucrăm cu Serverless - printr-un furnizor sau folosind open-source, vom primi o serie de avantaje și dezavantaje ale abordării Serverless.
Din punct de vedere al avantajelor și dezavantajelor
Serverless dezvoltă ideile unei infrastructuri de containere și o abordare cu microservicii, în care echipele pot lucra într-un mod multilingv fără a fi legate de o singură platformă. Construirea unui sistem este simplificată și erorile sunt mai ușor de corectat. Arhitectura microservicii vă permite să adăugați noi funcționalități sistemului mult mai rapid decât în cazul unei aplicații monolitice.
Serverless reduce timpul de dezvoltare și mai mult, permițând dezvoltatorului să se concentreze exclusiv pe logica de afaceri și codificarea aplicației. Ca urmare, timpul de lansare pe piață pentru dezvoltări este redus.
Ca bonus, obținem scalare automată pentru încărcare, si platim doar pentru resursele folosite si numai in momentul in care acestea sunt folosite.
Ca orice tehnologie, Serverless are dezavantaje.
De exemplu, un astfel de dezavantaj poate fi timpul de pornire la rece (în medie până la 1 secundă pentru limbi precum JavaScript, Python, Go, Java, Ruby).
Pe de o parte, în realitate, timpul de pornire la rece depinde de multe variabile: limba în care este scrisă funcția, numărul de biblioteci, cantitatea de cod, comunicarea cu resurse suplimentare (aceleași 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 - totul depinde de furnizor.
O pornire la rece se poate transforma într-o pornire la cald atunci când o funcție reutiliza un container lansat 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 vă permite să mențineți unele containere în funcțiune tot timpul;
- dacă dezvoltatorul rulează funcții pe un cronometru (să zicem la fiecare 3 minute).
Pentru multe aplicații, pornirea la rece nu este o problemă. Aici trebuie să vă bazați pe tipul și sarcinile 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. În acest caz, abordarea fără server probabil nu va mai fi potrivită.
Următorul dezavantaj al Serverless este durata scurtă de viață a unei funcții (timeout în care funcția trebuie să fie executată).
Dar, dacă trebuie să lucrați cu sarcini de lungă durată, puteți utiliza o arhitectură hibridă - combinați Serverless cu o altă tehnologie.
Nu toate sistemele vor putea funcționa folosind schema Serverless.
Unele aplicații vor stoca în continuare date și stare în timpul execuției. Unele arhitecturi vor rămâne monolitice, iar unele caracteristici vor fi de lungă durată. Cu toate acestea (ca tehnologiile cloud și apoi containerele), Serverless este o tehnologie cu un viitor mare.
În acest sens, aș dori să trec fără probleme la problema utilizării abordării Serverless.
Din partea aplicației
Pentru 2018, procentul de utilizare fără server . Printre companiile care au implementat deja tehnologia în serviciile lor se numără giganți de piață precum Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. În același timp, trebuie să înțelegeți că Serverless nu este un panaceu, ci un instrument pentru rezolvarea unei anumite game de probleme:
- Reduceți timpul de nefuncționare al resurselor. Nu este nevoie să păstrați constant o mașină virtuală pentru serviciile care au puține apeluri.
- Procesați datele din mers. Comprimați imagini, decupați fundalurile, schimbați codarea video, lucrați cu senzori IoT, efectuați operații matematice.
- „Lipiți” alte servicii împreună. Depozitul Git cu programe interne, bot de chat în Slack cu Jira și calendar.
- Echilibrați sarcina. Să aruncăm o privire mai atentă aici.
Să presupunem că există un serviciu care atrage 50 de persoane. Sub ea se află o mașină virtuală cu hardware slab. Din când în când, sarcina serviciului crește semnificativ. Atunci hardware-ul slab nu poate face față.
Puteți include un echilibrator în sistem care va distribui încărcarea, să zicem, pe trei mașini virtuale. În această etapă, nu putem prezice cu exactitate sarcina, așa că păstrăm o anumită cantitate de resurse care rulează „în rezervă”. Și plătim în plus pentru timpul de nefuncționare.
Într-o astfel de situație, putem optimiza sistemul printr-o abordare hibridă: lăsăm o mașină virtuală în spatele echilibratorului de încărcare și punem o legătură către Endpoint-ul Serverless cu funcții. Dacă sarcina depășește pragul, echilibrerul lansează instanțe de funcție care preiau o parte din procesarea cererii.
Astfel, Serverless poate fi folosit acolo unde este necesar să se proceseze un număr mare de solicitări nu prea des, dar intens. În acest caz, rularea mai multor funcții timp de 15 minute este mai profitabilă decât întreținerea unei mașini virtuale sau a unui server tot timpul.
Având toate avantajele computerului fără server, înainte de implementare, ar trebui să evaluați mai întâi logica aplicației și să înțelegeți ce probleme le poate rezolva fără server într-un anumit caz.
Serverless și Selectel
La Selectel suntem deja prin panoul nostru de control. Acum construim propria noastră platformă FaaS. Dorim ca dezvoltatorii să-și poată rezolva problemele folosind Serverless printr-o interfață convenabilă și flexibilă.
Dacă aveți idei despre care ar trebui să fie platforma FaaS ideală și despre cum doriți să utilizați Serverless în proiectele dvs., împărtășiți-le în comentarii. Vom ține cont de dorințele tale atunci când dezvoltăm platforma.
Materiale folosite în articol:
Sursa: www.habr.com