Serverless nuk është për mungesën fizike të serverëve. Nuk është një "vrasës" i konteinerëve dhe as një trend kalimtar. Është një qasje e re për ndërtimin e sistemeve në re. Në këtë artikull do të flasim për arkitekturën e aplikacioneve Serverless, duke parë rolin që luan ofruesi i shërbimeve Serverless dhe projektet open-source. Në fund do të diskutojmë për çështjet e aplikimit të Serverless.
Dua të shkruaj pjesën server të aplikacionit (madje ndonjë dyqan online). Mund të jetë një bisedë, një shërbim për publikimin e përmbajtjes, ose një balancues ngarkese. Në çdo rast, do të ketë shumë shqetësime: do të duhet të përgatisim infrastrukturën, të përcaktojmë varësitë e aplikacionit, dhe të mendojmë për sistemin operativ të hostit. Më pas do të nevojitet të përditësohen komponentët e vegjël që nuk prekin punën e monolit tjetër. Dhe mos ta harrojmë as skalimin nën ngarkesë.
E çfarë nëse të merrni konteinerë efemerë, në të cilët varësitë e kërkuara janë tashmë të instaluara, dhe këta konteinerë janë të izoluar nga njëri-tjetri dhe nga OS e hostit? Ne do të shndërrojmë monolitin në mikroshërbime, secili prej të cilave mund të përditësohet dhe të shkallëzohet në mënyrë të pavarur nga tjerët. Duke vendosur kodin në një konteiner të tillë, do të mund ta ekzekutoj atë në çdo infrastrukturë. Kjo tashmë është më mirë.
E nëse nuk dëshiroj të konfiguroj konteinerët? Nuk dua të mendoj për shkallëzimin e aplikacionit. Nuk dua të paguaj për pushimin e konteinerëve të aktivizuar kur ngarkesa në shërbim është minimale. Dua të shkruaj kod. Të përqendrohem në logjikën e biznesit dhe të nxjerr produktet në treg me shpejtësi dritë.
Këto mendime më çuan në llogaritjet pa server. Serverless në këtë rast do të thotë jo mungesën fizike të serverëve, por mungesën e dhimbjes së kokës nga menaxhimi i infrastrukturës.
Ideja është që logjika e aplikacionit të ndahet në funksione të pavarura. Këto kanë një strukturë ngjarjesh. Çdo funksion ekzekuton një "mikrodetyrë". Gjithçka që kërkohet nga zhvilluesi është të ngarkohet funksionet në konsolën e ofruar nga ofruesi i shërbimeve cloud dhe t'i lidhë ato me burimet e ngjarjeve. Kodi do të ekzekutohet me kërkesë në një container të përgatitur automatikisht, dhe unë do të paguaj vetëm për kohën e ekzekutimit.
Le të shohim se si do të duket tani procesi i zhvillimit të aplikacionit.
Nga pikëpamja e zhvilluesit
Më parë filluam të flasim për një aplikacion për një dyqan online. Në qasjen tradicionale, logjika kryesore e sistemit ekzekutohet nga një aplikacion monolitik. Dhe serveri me aplikacionin është gjithmonë aktiv, edhe nëse nuk ka ngarkesë.
Për të kaluar në serverless, e ndamë aplikacionin në mikrodetyra. Për secilën prej tyre shkruajmë funksionin tonë. Funksionet janë të pavarura nga njëra-tjetra dhe nuk ruajnë informacion në lidhje me gjendjen (stateless). Ato madje mund të jenë shkruar në gjuhë të ndryshme. Nëse njëra prej tyre "bën rënie", aplikacioni në tërësi nuk do të ndalojë. Arkitektura e aplikacionit do të duket kështu:
Shpërndarja e funksioneve në Serverless është e ngjashme me punën me mikroshërbime. Por një mikroshërbim mund të kryejë disa detyra, ndërsa funksioni në ideal duhet të kryejë vetëm një. Imagjinoni një rast ku duhen mbledhur statistika dhe paraqitur sipas kërkesës së përdoruesit. Në qasjen mikroshërbimore, detyra kryhet nga një shërbim me dy pika hyrjeje: për shkrim dhe për lexim. Në llogaritë pa server, këto do të ishin dy funksione të ndryshme, të pa lidhura me njëra-tjetrën. Zhvilluesi kursen burimet llogarike, nëse, për shembull, statistika përditësohet më shpesh sesa eksportohen.
Funksionet Serverless duhet të ekzekutohen brenda një periudhe të shkurtër kohore (timeout), e cila përcaktohet nga ofruesi i shërbimit. Për shembull, për AWS, timeout-i është 15 minuta. Kështu, funksionet e gjata (long-lived) do të duhet të ndryshojnë sipas kërkesave - kjo është çka e dallon Serverless nga teknologjitë e tjera të njohura sot (kontejnerët dhe Platform as a Service).
Çdo funksion i caktohet një ngjarje. Ngjarja është një aktivizues për veprimin:
Ngjarja
Veprimi që kryen funksioni
Në ruajtje është ngarkuar një imazh i produktit
Kompresoni imazhin dhe eksportoni në katalog
Në bazën e të dhënave është përditësuar adresa e dyqanit fizik
Ngarko një vendndodhje të re në mapa
K clienti paguan produktin
Filloni përpunimin e pagesës
Ngjarjet mund të jenë kërkesa HTTP, të dhëna të rrjedhshme, radhë mesazhesh etj. Burimet e ngjarjeve janë ndryshimi ose shfaqja e të dhënave. Për më tepër, funksionet mund të aktivizohen me një timer.
Arkitektura është punuar dhe aplicacioni pothuajse ka arritur statusin serverless. Të vazhdojmë me ofruesin e shërbimit.
Nga ana e ofruesit
Zakonisht, llogaritë pa server ofrohen nga ofruesit e shërbimeve cloud. I quajnë ndryshe: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ne do të përdorim shërbimin përmes konsolës ose llogarisë personale të ofruesit. Kodi i funksioneve mund të ngarkohet në një nga këto mënyra:
- të shkruajmë kodin në redaktorët e integruar përmes konsolës web,
- të ngarkojmë një arkiv me kodin,
- të punojmë me repozitoret git publike ose private.
Këtu gjithashtu konfiguroni ngjarjet që aktivizojnë funksionin. Grupi i ngjarjeve mund të ndryshojë nga ofruesi në ofrues.
Ofruesi ka ndërtuar dhe automatizuar një sistem Function as a Service (FaaS) në infrastrukturën e tij:
- Kodi i funksioneve arrin në një depo në anën e ofruesit.
- Kur ndodh një ngjarje, kontejnerët me ambientin e përgatitur krijohen automatikisht në server. Çdo ekzemplar funksioni ka kontejnerin e vet të izoluar.
- Nga depoja, funksioni dërgohet në kontejner, llogaritet dhe jep rezultatin.
- Numri i ngjarjeve paralele rritet — rritet edhe numri i kontejnerëve. Sistemi automatikisht shkallëzohet. Nëse përdoruesit nuk i japin funksionit, ai do të jetë joaktiv.
- Ofruesi përcakton kohën e pezullimit të kontejnerëve — nëse gjatë këtij kohë funksionet nuk shfaqen në kontejner, ai shkatërrohet.
Kështu, ne marrim Serverless «të gatshëm për përdorim». Do të paguajmë për shërbimin sipas modelit pay-as-you-go dhe vetëm për ato funksione që përdoren, dhe vetëm për kohën kur ato janë përdorur.
Për të njohur zhvilluesit me shërbimin, ofruesit ofrojnë deri në 12 muaj provë falas, por kufizojnë kohën totale të llogaritjeve, numrin e kërkesave në muaj, fondet ose kapacitetin e konsumuar.
Avantazhi kryesor i punës me ofruesit është mundësia për të mos u shqetësuar për infrastrukturën (serverët, makinat virtuale, kontejnerët). Nga ana e saj, ofruesi mund të implementojë FaaS si në zhvillimet e tij, ashtu edhe përmes mjeteve open-source. Këto do t'i diskutojmë më tej.
Nga ana e open source
Dy vitet e fundit, komuniteti open-source ka punuar aktivisht mbi mjete Serverless. Në këtë përfshihen edhe kontributet e lojtarëve më të mëdhenj të tregut:
- Google ofron zhvilluesve mjetin e tij open-source ― . Në zhvillimin e tij morën pjesë IBM, RedHat, Pivotal dhe SAP;
- IBM punuan mbi platformën Serverless , e cila më vonë u bë projekt i Fondacionit Apache;
- Microsoft pjesërisht hapën kodin e platformës .
Zhvillimet po bëhen gjithashtu në drejtim të framework-ëve serverless. dhe ndërtohen brenda klasterëve Kubernetes të përgatitur më parë, punon si me Kubernetes, ashtu edhe me Docker Swarm. Framework-u shërben si një lloj kontrolluesi ― sipas kërkesës përgatit mjedisin e ekzekutimit brenda klasterit, pastaj e nis atje funksionin.
Frameworket ofron hapësirë për konfigurimin e mjetit sipas nevojave të tij. Kështu, në Kubeless, zhvilluesi mund të konfigurojë kohën e skadencës për ekzekutimin e funksionit (vlera e paracaktuar është 180 sekonda). Fission, në përpjekje për të zgjidhur problemin e fillimit të ftohtë, ofron që disa kontejnerë të mbahen gjithmonë të aktivizuar (ndonëse kjo sjell kosto për burimet e papërdorura). Ndërsa OpenFaaS ofron një grup nxitësish për çdo shije dhe ngjyrë: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs dhe të tjerë.
Udhëzimet për të filluar mund të gjenden në dokumentacionin zyrtar të frameworkeve. Puna me to nënkupton njohuri disi më të mëdha sesa kur punojmë me një ofrues — kjo është minimalisht aftësia për të lançuar një cluster Kubernetes përmes CLI. Maksimumi, përfshirja e mjeteve të tjera open-source (p.sh., menaxhuesi i radhëve Kafka).
Pavarësisht mënyrës se si do të punojmë me Serverless — përmes një ofruesi ose nëpërmjet open-source, ne do të përfitojmë një sërë përparësish dhe mangësish të trendit Serverless.
Nga pozita e përparësive dhe mangësive
Serverless zhvillon ide të infrastrukturës me kontejnerë dhe qasjes mikroshërbimore, ku ekipet mund të punojnë në mënyrë multilinguale, pa u lidhur me një platformë të vetme. Ndërtimi i sistemit bëhet më i thjeshtë, dhe korrigjimi i gabimeve është më i lehtë. Arkitektura mikroshërbimore lejon shtimin e funksionaliteteve të reja në sistem shumë më shpejt se në rastin e një aplikacioni monolit.
Serverless e redukton akoma më shumë kohën e zhvillimit, duke i lejuar programuesit të fokusohet ekskluzivisht në logjikën e biznesit të aplikacionit dhe në shkrimin e kodit. Si pasojë, koha për hyrjen e zhvillimeve në treg reduktohet.
Si bonus, ne marrim shkallëzim automatik sipas ngarkesës, ndërsa paguajmë vetëm për burimet e përdorura dhe vetëm në kohën kur ato përdoren.
Si çdo teknologji tjetër, Serverless ka disavantazhe.
Për shembull, një prej disavantazheve do të ishte koha e nisjes së ftohtë (në mesatare deri në 1 sekondë për gjuhë si JavaScript, Python, Go, Java, Ruby).
Në njërën anë, koha e ftohtë e nisjes varet në të vërtetë nga shumë variabla: gjuha në të cilën është shkruar funksioni, numri i librarive, volume i kodit, ndërlidhja me burime të tjera (si databaza apo serverat e autentikimit). Duke qenë se zhvilluesi menaxhon këta variabla, ai mund ta zvogëlojë kohën e nisjes. Por nga ana tjetër, zhvilluesi nuk mund të kontrollojë kohën e nisjes së konteinerit — këtu gjithçka varet nga ofruesi.
Ftohja mund të bëhet e ngrohtë kur funksioni ripërdor një konteiner të nisur nga një ngjarje e mëparshme. Kjo situatë do të ndodhë në tre raste:
- nëse klientët përdorin shpesh shërbimin dhe rritet numri i thirrjeve për funksionin;
- nëse ofruesi, platforma ose framework-u lejojnë mbajtjen e disa konteinerëve të nisur gjithmonë;
- nëse zhvilluesi nis funksionet nëpërmjet një timeri (p.sh., çdo 3 minuta).
Për shumë aplikacione, nisja e ftohtë nuk është një problem. Këtu duhet të bazoheni në llojin dhe detyrat e shërbimit. Vonesa e nisjes për një sekondë nuk është gjithmonë kritike për aplikacionet biznesore, por mund të bëhet kritike për shërbimet mjekësore. Probabilisht, në këtë rast, qasja serverless nuk do të jetë e përshtatshme.
Një tjetër disavantazh i Serverless është koha e shkurtër e jetës së funksionit (timeout, për të cilin funksioni duhet të përfundojë).
Por, nëse do të punoni me detyra afatgjata, mund të përdorni një arkitekturë hibridike — të kombinoheni Serverless me një teknologji tjetër.
Jo të gjitha sistemet do të mund të punojnë në skemën Serverless.
Disa aplikacione ende do të ruajnë të dhëna dhe gjendje gjatë ekzekutimit. Disa arhitekturë do të mbeten monolitike, ndërsa disa funksione do të jenë afatgjata. Megjithatë (si dikur teknologjitë cloud dhe më pas kontejnerët), Serverless është një teknologji me një të ardhme të madhe.
Në këtë kuadër, do doja të kaloj në mënyrë të qetë në çështjen e aplikimit të qasjes Serverless.
Nga ana e aplikimit
Gjatë vitit 2018, përqindja e përdorimit të Serverless . Në mesin e kompanive që tashmë kanë implementuar teknologjinë në shërbimet e tyre, janë gjigandët e tregut si Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Megjithatë, është e rëndësishme të kuptohet se Serverless nuk është një panacee, por një instrument për zgjidhjen e një gamë të caktuar të detyrave:
- Të reduktojmë ndalesat e burimeve. Nuk është e nevojshme të mbash vazhdimisht një makinë virtuale për shërbime që kanë pak kërkesa.
- Të përpunosh të dhëna «në fluturi». Të kompresosh imazhe, të tërheqësh sfondin, të ndryshosh kodimin e videos, të punosh me sensorë IoT, të kryesh operacione matematikore.
- Të «lidhnim» së bashku shërbime të tjera. Git-repozitori me programet e brendshme, chatbot në Slack me Jira dhe kalendarin.
- Të balancosh ngarkesën. Këtu do të ndalemi më në detaje.
Supozoni, ka një shërbim, në të cilin vijnë 50 njerëz. Për të, ka një makinë virtuale me pajisje të dobëta. Periodikisht ngarkesa në shërbim rritet shumëfish. Atëherë pajisja e dobët nuk është në gjendje të përballojë.
Mund të implementoni një balancues ngarkese që do të shpërndajë ngarkesën, le të themi, në tre makina virtuale. Në këtë fazë, nuk mund të parashikojmë saktësisht ngarkesën, prandaj mbajmë disa burime aktive "për rezervë". Dhe paguajmë më shumë për inaktivitetin.
Në një situatë të tillë, ne mund ta optimizojmë sistemin nëpërmjet një qasjeje hibride: pas balancuesit të ngarkesës, lëmë një makinë virtuale dhe vendosim një lidhje me Serverless Endpoint me funksionet. Nëse ngarkesa tejkalon pragun, balancuesi aktivizon instancat e funksioneve që marrin përsipër një pjesë të përpunimit të kërkesave.
Në këtë mënyrë, Serverless mund të përdoret atje ku duhen përpunuar shpesh, por në mënyrë intensive, një numër i madh kërkesh. Në këtë rast, është më e dobishme të aktivizoni disa funksione për 15 minuta sesa të mbani aktiv një makinë virtuale ose një server gjatë gjithë kohës.
Pavarësisht të gjitha përfitimeve të përpunimit pa server, para se ta implementoni, në radhë të parë do të duhet të vlerësoni logjikën e aplikacionit dhe të kuptoni se cilat detyra mund të zgjidhë Serverless në rastin konkret.
Serverless dhe Selectel
Në Selectel ne tashmë përmes panelit tonë të menaxhimit. Tani po ndërtojmë platformën tonë FaaS. Duam që zhvilluesit të mund të zgjidhin problemet e tyre me Serverless përmes një ndërfaqeje të lehtë dhe fleksible.
Nëse keni ide se si duhet të duket platforma ideale FaaS dhe si dëshironi të përdorni Serverless në projektet tuaja, ndani ato në komentet më poshtë. Do të kemi parasysh dëshirat tuaja gjatë zhvillimit të platformës.
Materialet e përdorura në artikull:
Burimi: habr.com
