Serverless nuk ka të bëjë me mungesën fizike të serverëve. Nuk është një "vrasës" i konteinerëve dhe as një trend kalimtar. Ky është një qasje e re për ndërtimin e sistemeve në re. Në artikullin e sotëm do të trajtojmë arkitekturën e aplikacioneve Serverless, do të shohim se çfarë roli luan ofruesi i shërbimit Serverless dhe projektet open-source. Në fund do të flasim për çështjet e përdorimit të Serverless.
Dua të shkruaj pjesën serverike të aplikacionit (madje edhe një 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ë mjaft telashe: do të duhet të përgatis infrastrukturën, të përcaktoj varësitë e aplikacionit dhe të mendoj për sistemin operativ të host-it. Me pas, do të jetë e nevojshme të përditësoj disa komponente të vogla që nuk prekin funksionimin e pjesës tjetër monolite. Dhe nuk duhet të harrojmë për shkallëzimin nën ngarkesë.
Por, çfarë nëse marrim konteinerë efemerë, në të cilët varësitë e nevojshme janë tashmë të parainstaluara, dhe vetë konteinerët janë të izoluar nga njëri-tjetri dhe nga OS host? Ne do të ndajmë monolitin në mikroshërbime, secili nga të cilat mund të përditësohet dhe të shkallëzohet në mënyrë të pavarur nga të tjerët. Duke vendosur kodin në një konteiner të tillë, unë do të mund ta ekzekutoj atë në çdo infrastrukturë. Më mirë tani.
Por, nëse nuk dua 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ë nisur 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 të jashtëzakonshme.
Këto mendime më çuan në llogaritë pa serverë. Serverless në këtë rast do të thotë jo mungesë fizike të serverëve, por mungesë telash për menaxhimin e infrastrukturës.
Ideja është që logjika e aplikacionit ndahen në funksione të pavarura. Ato kanë një strukturë ngjarjesh. Çdo funksion kryen një "mikrosiht". Gjithçka që kërkohet nga zhvilluesi është të ngarkojë funksionet në konsolën e siguruar nga ofruesi i cloud dhe t'i lidhë ato me burimet e ngjarjeve. Kodi do të ekzekutohet sipas kërkesës në një konteiner të përgatitur automatikisht dhe unë do të paguaj vetëm për kohën e ekzekutimit.
Le të shohim si do të duket tani procesi i zhvillimit të aplikacioneve.
Nga këndvështrimi i zhvilluesit
Më parë, filluam të flasim për aplikacionin për dyqanin online. Në qasjen tradicionale, logjika kryesore e sistemit kryhet nga një aplikacion monolit. Dhe serveri me aplikacionin është gjithmonë aktiv, edhe nëse nuk ka ngarkesë.
Për të kaluar tek serverless, ne ndajmë aplikacionin në mikroshkëmbime. Për secilën prej tyre shkruajmë funksionin tonë. Funksionet janë të pavarura nga njëra-tjetra dhe nuk ruajnë informacion rreth gjendjes (stateless). Ato madje mund të shkruhen në gjuhë të ndryshme. Nëse njëra prej tyre "pëson dështim", aplikacioni në tërësi nuk do të ndalet. Arkitektura e aplikacionit do të duket kështu:
Ndarja në funksione në Serverless i ngjan punës me mikrosserviset. Por mikroservisi mund të kryejë disa detyra, ndërsa funksioni në ideal duhet të kryejë një të vetme. Le të imagjinojmë se kemi një detyrë për të mbledhur statistikë dhe për ta ofruar atë sipas kërkesës së përdoruesit. Në qasjen mikroservisë, detyrën e kryen një shërbim me dy pika hyrëse: 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 llogaritëse, nëse, për shembull, statistika përditësohet më shpesh se sa shkarkohet.
Funksionet Serverless duhet të ekzekutohen për një periudhë të shkurtër kohe (timeout), e cila përcaktohet nga ofruesi i shërbimit. P.sh., për AWS timeout-i është 15 minuta. Kështu, funksionet afatgjata (long-lived) do të duhet të përshtaten me kërkesat ― dhe kjo është ajo që e dallon Serverless nga teknologjitë e tjera popullore sot (kontejnerë dhe Platform as a Service).
Çdo funksioni i caktojmë një ngjarje. Ngjarja është një trigger për veprimin:
Ngjarja
Veprimi që kryen funksioni
Në ruajtje është ngarkuar një imazh i produktit
Të kompresohet imazhi dhe të ngarkohet në katalog
Në bazën e të dhënave është përditësuar adresa e dyqanit fizik
Të ngarkohet një vendndodhje e re në harta
Klienti paguan produktin
Të fillohet përpunimi i pagesës
Ngjarjet mund të përfshijnë kërkesa HTTP, të dhëna në rrjedhë, radhë mesazhesh, etj. Burimet e ngjarjeve janë ndryshimi ose shfaqja e të dhënave. Përveç kësaj, funksionet mund të ekzekutohen sipas orarit.
Arkitektura është përpunuar, dhe aplikacioni pothuajse është bërë serverless. Tani kalojmë te ofruesi i shërbimeve.
Nga ana e ofruesit
Zakoniçt, llogaritë pa server ofrohen nga ofruesit e shërbimeve në re. Shkruhen në mënyra të ndryshme: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Do ta përdorim shërbimin përmes konsolës ose panelit personal të ofruesit. Kodi i funksioneve mund të ngarkohet në disa mënyra:
- të shkruajmë kodin në redaktorët e integruar përmes konsolës në internet,
- të ngarkohet një arkiv me kodin,
- të punojmë me repozitarë git publikë ose privatë.
Këtu konfiguroni ngjarjet që shkaktojnë funksionin. Në ofrues të ndryshëm, grumbujt e ngjarjeve mund të ndryshojnë.
Ofruesi ndërtuar dhe automatizuar sistemin Function as a Service (FaaS) në infrastrukturen e tij:
- Kodi i funksioneve dërgohet në magazinën nga ana e ofruesit.
- Kur ndodh një ngjarje, kontenierët me ambientin e përgatitur zhvillohen automatikisht në server. Çdo instancë e funksionit ka një kontenier të izoluar.
- Nga magazina, funksioni dërgohet në kontenier, llogaritet dhe jep rezultatin.
- Numri i ngjarjeve paralele rritet - rritet numri i kontenierëve. Sistemi tërheq automatikisht burime. Nëse përdoruesit nuk e thërrasin funksionin, ai do të jetë joaktiv.
- Ofruesi përcakton kohën e papunësisë së kontenierëve - nëse gjatë kësaj periudhe nuk ndodhin funksione në kontenier, ai shkatërrohet.
Kështu, ne marrim Serverless "nga kutia". Do të paguajmë për shërbimin me modelin pay-as-you-go dhe vetëm për funksionet që përdoren, dhe vetëm për kohën që ato janë përdorur.
Për të njohur zhvilluesit me shërbimin, ofruesit ofrojnë deri në 12 muaj provë falas, por kufizojnë kohën e përgjithshme të llogaritjes, numrin e kërkesave në muaj, fondet ose kapacitetin e konsumuar.
Avantazhi kryesor i punës me ofruesin është mundësia për të mos u shqetësuar për infrastrukturën (serverat, makinat virtuale, kontenierët). Nga ana e tij, ofruesi mund ta realizojë FaaS si në zhvillimet e tij, ashtu edhe me mjete open-source. Këto do të diskutojmë më tej.
Nga ana e open-source
Dy vitet e fundit, komuniteti open-source ka punuar aktivisht për mjete Serverless. Gjithashtu, kontributi në zhvillimin e platformave pa server vjen nga lojtarët 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ë pas u bë projekt i Fondacionit Apache;
- Microsoft pjesërisht hapën kodin e platformës .
Zhvillimet po bëhen gjithashtu në drejtimin e frameworkeve pa server. dhe në kontenierët e përgatitur më parë brenda klasterëve Kubernetes, punon si me Kubernetes ashtu edhe me Docker Swarm. Framework-u vepron si një lloj kontrollori - sipas kërkesës përgatit brenda klasterit një mjedis ekzekutimi, pastaj e nis atje funksionin.
Framework-et ofrojnë hapësirë për konfigurimin e mjetit sipas nevojave të tyre. Kështu, në Kubeless, zhvilluesi mund të përcaktojë kohën e skadimit të ekzekutimit të funksionit (vlera e paracaktuar është 180 sekonda). Fission, në përpjekje për të zgjidhur problemin e nisjes së ftohtë, ofron një pjesë të kontenjerëve që të mbahen gjithmonë të ndezur (ndonëse kjo sjell kostot për përdorimin e të dhënave). Dhe OpenFaaS ofron një grup trigger-ash për çdo shije dhe ngjyrë: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs dhe të tjera.
Udhëzimet për të filluar punën mund të gjenden në dokumentacionin zyrtar të framework-eve. Puna me to nënkupton një sasi të vogël më shumë aftësish se puna me ofruesin - kjo është të paktën aftësia për të nisur një klaster Kubernetes përmes CLI. Maksimumi, të përfshijmë në punë mjete të tjera open-source (p.sh. menaxheri i radhëve Kafka).
Pavarësisht se me çfarë metode do të punojmë me Serverless - nëpërmjet ofruesit ose përmes open-source, do të arrijmë një sërë avantazhesh dhe disavantazhesh të qasjes Serverless.
Nga pozita e avantazheve dhe disavantazheve
Serverless zhvillon idetë e infrastrukturës së konteinerëve dhe qasjes mikro-shërbimore, ku ekipet mund të punojnë në një mënyrë shumëgjuhëshe, pa u lidhur me një platformë të vetme. Ndërtimi i sistemit bëhet më i thjeshtë, dhe rregullimi i gabimeve bëhet më e lehtë. Arkitektura mikro-shërbimore lejon shtimin e funksionaliteteve të reja në sistem shumë më shpejt se sa në rastin e një aplikacioni monolitik.
Serverless e shkurton kohën e zhvillimit edhe më shumë, duke i lejuar zhvilluesit të fokusohet ekskluzivisht në logjikën e biznesit të aplikacionit dhe në shkrimin e kodit. Si pasojë, koha e daljes së zhvillimeve në treg shkurtizohet.
Si bonus, ne marrim përmirësim automatik në shkallëzim nën ngarkesë, ndërsa paguajmë vetëm për burimet e përdorura dhe vetëm në atë kohë kur ato përdoren.
Si çdo teknologji, Serverless ka disavantazhe.
Për shembull, një nga këto disavantazhe mund të jetë koha e nisjes së ftohtë (në mesatare deri në 1 sekondë për gjuhët si JavaScript, Python, Go, Java, Ruby).
Nga njëra anë, në praktikë, koha e nisjes të ftohtë varet nga shumë variabla: gjuha në të cilën është shkruar funksioni, numri i bibliotekave, volumi i kodit, ndërveprimi me burime shtesë (p.sh. bazat e të dhënave ose serverët e autentikimit). Duke qenë se zhvilluesi menaxhon këto variabla, ai mund të shkurtëojë kohën e nisjes. Por nga ana tjetër, zhvilluesi nuk mund të kontrollojë kohën e nisjes së kontejnerit - këtu gjithçka varet nga ofruesi.
Nisja e ftohtë mund të kthehet në një të ngrohtë, kur funksioni ripërdor një konteiner të hapur nga një ngjarje e mëparshme. Ky rast do të ndodhë në tri raste:
- nëse klientët e përdorin shpesh shërbimin dhe rritet numri i thirrjeve për funksionin;
- nëse ofruesi, platforma ose korniza lejojnë mbajtjen e disa kontejnerëve të hapur gjatë gjithë kohës;
- nëse zhvilluesi aktivizon funksionet me një orar (p.sh. çdo 3 minuta).
Për shumë aplikacione, nisja e ftohtë nuk është një problem. Këtu duhet të fokusohemi në llojin dhe detyrat e shërbimit. Vonesa e nisjes për një sekondë nuk është gjithmonë kritike për një aplikacion biznesi, por mund të bëhet kritike për shërbimet mjekësore. Probabilisht, në këtë rast, qasja pa server nuk do të jetë e përshtatshme më.
Një nga disavantazhet e Serverless quhet koha e shkurtër e jetës së funksionit (koha e skadimit, brenda së cilës funksioni duhet të përfundojë).
Por, nëse pritet të punohet me detyra të gjata, mund të përdoret një arkitekturë hibride - të kombinohet Serverless me një teknologji tjetër.
Nuk të gjitha sistemet do të jenë në gjendje të punojnë sipas skemës Serverless.
Disa aplikacione ende do të ruajnë të dhënat dhe gjendjen gjatë performancës. Disa arkitektura do të mbeten monolitike, ndërsa disa funksione do të jenë me jetëgjatësi. Megjithatë, (siç ndodhi dikur me teknologjitë në re, dhe më vonë me kontejnerët), Serverless është një teknologji me një të ardhme të madhe.
Në këtë kontekst, do të doja të kaloj në pyetjes për aplikimin e qasjes Serverless.
Nga këndvështrimi i aplikimit
Gjatë vitit 2018, përqindja e përdorimit të Serverless . Ndërmjet kompanive që tashmë e kanë implementuar teknologjinë në shërbimet e tyre, janë gjigantët e tregut si Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Në të njëjtën kohë, duhet të kuptohet se Serverless nuk është një ilaç universal, por një mjet për zgjidhjen e një sërë problemi:
- Të pakësosh papunësinë e burimeve. Nuk duhet ta mbani vazhdimisht një makinë virtuale për shërbime, për të cilat bëhet pak kërkesë.
- Të обработoni të dhënat «në fluturim». Të kompresoni përmbajtjet e imazheve, të prerë sfondin, të ndryshoni kodimin e videove, të punoni me sensorët IoT, të kryeni operacione matematikore.
- Të «ngjiteni» shërbime të tjera së bashku. Git-repozitor me programe të brendshme, chatbot në Slack me Jira dhe me kalendarin.
- Të balanconi ngarkesën. Këtu do të ndalem më në hollësi.
Supozoni se ka një shërbim, në të cilin hynë 50 persona. Përdoret një makinë virtuale me harduer të dobët. Herë pas here, ngarkesa në shërbim rritet shumë herë. Atëherë, hardueri i dobët nuk arrin t'i përballojë.
Mund të aktivizoni një balancues ngarkesash në sistem, i cili do të shpërndajë ngarkesën, le të themi, në tri makina virtuale. Në këtë fazë nuk mund të parashikojmë saktësisht ngarkesën, prandaj mbajmë disa burime të aktivizuara «për rezervë». Dhe paguajmë më shumë për kohën e papunë.
Në këtë situatë, mund të optimizojmë sistemin përmes një qasjeje hibride: pas balancuesit të ngarkesës lëmë një makinë virtuale dhe vendosim një lidhje në Serverless Endpoint me funksione. Nëse ngarkesa kalon pragun - balancuesi aktivizon instanca funksionesh, të cilat marrin përsipër një pjesë të përpunimit të kërkesave.
Kështu, Serverless mund të përdoret atje ku duhet të përpunoni shpesh, por intensivisht, një numër të madh kërkesash. Në këtë rast, është më e lirë të aktivizoni disa funksione për 15 minuta sesa të mbani vazhdimisht një makinë virtuale ose një server.
Pavarësisht përfitimeve të llogaritjeve pa server, para se të implementoni duhet së pari të vlerësoni logjikën e aplikacionit dhe të kuptoni se cilat probleme mund të zgjidhë Serverless në rastin e veçantë.
Serverless dhe Selectel
Në Selectel ne tashmë nëpërmjet panelit tonë të menaxhimit. Tani po zhvillojmë platformën tonë FaaS. Duam që zhvilluesit të mund të zgjidhin problematikat e tyre përmes Serverless përmes një ndërfaqeje të përshtatshme dhe fleksibël.
Nëse keni ide se si duhet të jetë platforma ideale FaaS dhe si dëshironi të përdorni Serverless në projektet tuaja, ndani ato në komente. Ne do të marrim parasysh dëshirat tuaja gjatë zhvillimit të platformës.
Materialet e përdorura në artikull:
Burimi: habr.com
