Megjithëse teknologjitë pa server kanë fituar popullaritet të shpejtë për vitet e fundit, ende ekzistojnë shumë keqkuptime dhe shqetësime rreth tyre. Vështirësitë e varësisë nga ofruesi, mjetet, menaxhimi i shpenzimeve, fillimi i ftohtë, monitorimi dhe cikli i zhvillimit janë të gjitha tema që diskutohen kur bëhet fjalë për teknologjitë pa server. Në këtë artikull, ne do të shqyrtojmë disa nga këto tema dhe do të ndajmë këshilla dhe lidhje me burime të dobishme që do t'u ndihmojnë fillestarëve të krijojnë aplikacione pa server që janë të fuqishme, fleksibël dhe ekonomike.
Keqkuptimet rreth teknologjive pa server
Shumë njerëz mendojnë se pa server dhe përpunimi i të dhënave jashtë serverëve (, FaaS) janë pothuajse të njëjta. Kjo nënkupton se ndryshimi nuk është shumë të madh dhe është e arsyeshme të zbatoni këtë novitet. Edhe pse AWS Lambda ishte një nga "yjet" e rritjes së teknologjive pa server dhe një nga elementet më të njohura të arkitekturës pa server, kjo arkitekturë përfaqëson më shumë se sa FaaS.
Parimi kryesor i teknologjive pa server është se ju nuk duhet të shqetësoheni për menaxhimin dhe shkallëzimin e infrastrukturës, ju paguani vetëm për atë që përdorni. Nën këto kritere bën pjesë një mori shërbimesh — AWS DynamoDB, S3, SNS ose SQS, Graphcool, Auth0, Now, Netlify, Firebase dhe shumë të tjerë. Në përgjithësi, pa server nënkupton shfrytëzimin e të gjitha mundësive të llogaritjes në re pa pasur nevojë të menaxhoni infrastrukturën dhe optimizimin e saj për shkallëzim. Gjithashtu, kjo nënkupton se siguria në nivelin e infrastrukturës nuk është më shqetësimi juaj, dhe kjo është një avantazh i madh, duke qenë se është e vështirë dhe komplekse të respektohen standardet e sigurisë. E fundit, nuk keni nevojë të blini infrastrukturën që ju ofrohet për përdorim.
Mund ta shikoni pa server si një "gjak"; një mënyrë krijuese për të projektuar zgjidhje. Shmangni qasje që kërkojnë mirëmbajte të ndonjë infrastrukture. Me qasjen pa server, shpenzojmë kohë duke zgjidhur probleme që kanë ndikim të drejtpërdrejt në projekt dhe sjellin përfitime për përdoruesit tanë: krijojmë logjikë biznesi të qëndrueshme, zhvillojmë ndërfaqe përdoruesi dhe projektuar API të përshtatshme dhe të besueshme.
Për shembull, nëse është e mundur të shmangim menaxhimin dhe mbështetje e një platforme për kërkimin me tekst të lirë, atëherë pikërisht atë do të bëjmë. Kjo qasje për ndërtimin e aplikacioneve mund të shpejtojë dukshëm nxjerrjen e produktit në treg, sepse nuk keni më nevojë të mendoni për menaxhimin e një infrastrukture komplekse. Shkarkoni detyrat dhe shpenzimet për menaxhimin e infrastrukturës dhe përqendrohuni në krijimin e aplikacioneve dhe shërbimeve që i duhen klientëve tuaj. Patrick Debois e quajti këtë qasje , ky term është pranuar në komunitetin pa server. Funksionet duhet të shihen si lidhëse për shërbime në formën e moduleve të deployueshëm (në vend të deployimit të një biblioteke të tërë ose një aplikacioni web). Kjo siguron një menaxhim të pabesueshëm të granularitetit për deployimin dhe ndryshimet në aplikacion. Nëse nuk mund ta bëni këtë përmes deployimit të funksioneve, mund të tregojë se funksionet po kryejnë shumë detyra dhe duhet të ristrukturohen.
Disa njerëz shqetësohen për varësinë nga ofruesi kur zhvillojnë aplikacione në re. E njëjta gjë është e vërtetë dhe për teknologjitë pa server, dhe shumë mund të kenë paragjykime të gabuara. Nga përvoja jonë, krijimi i aplikacioneve pa server në AWS në kombinim me aftësinë e AWS Lambda për të integruar shërbje të tjera AWS ndihmon në formimin e vlerash të arkitekturave pa server. Ky është një shembull i mirë i sinergjisë, kur rezultati i kombinimit është më i madh se thjesht shuma e komponentëve. Duke u përpjekur të shmangni varësinë nga ofruesi, mund të përballeni me probleme edhe më të mëdha. Kur punoni me kontejnerë, është më e lehtë të menaxhoni nivelin tuaj të abstraksionit midis ofruesve të ndryshëm të cloud. Por kur bëhet fjalë për zgjidhjet pa server, përpjekjet nuk do të jenë të justifikuara, veçanërisht nëse konsideroni efektivitetin ekonomik që nga fillimi. Sigurohuni që të kuptoni se si ofruesit sigurojnë shërbimet. Disa shërbime të specializuara varen nga pikët e integrimit me ofrues të tjerë dhe mund të ofrojnë mundësi lidhjeje si plug-and-play nga kutia. Është më e lehtë të sigurosh thirrjen e Lambda nga një pikë fundore API gateway sesa të prokurosh një kërkesë në një kontejner ose instancë EC2. Graphcool siguron konfigurim të lehtë përmes Auth0, dhe kjo është më e lehtë sesa përdorimi i mjeteve të jashtme të autentifikimit.
Zgjedhja e ofruesit të duhur për aplikacionin tuaj pa server është një vendim me rëndësi arkitekturale. Kur krijoni një aplikacion, nuk prisni që një ditë të ktheheni në menaxhimin e serverëve. Zgjedhja e ofruesit të cloud-it nuk është ndryshe nga zgjedhja e përdorimit të kontejnerëve, një baze të dhënash, ose madje edhe një gjuhe programimi.
Mendoni:
- Çfarë shërbimesh ju nevojiten dhe pse.
- Cilat shërbime ofrojnë ofruesit e cloud-it dhe si mund t'i kombinoni ato me zgjidhjen tuaj të zgjedhur FaaS.
- Cilat gjuhë programimi mbështeten (me tipizim dinamik ose statik, të kompilueshme ose të interpretuara, cilat janë benchmark-et, cila është performanca gjatë nisjes së ftohtë, çfarë ekosistemi open source ekziston, etj.).
- Cilat janë kërkesat tuaja për siguri (SLA, 2FA, OAuth, HTTPS, SSL, etj.).
- Si ta menaxhoni CI/CD-në tuaj dhe ciklet e zhvillimit të softuerit.
- Cilat përfitime të zgjidhjeve të klasës infrastructure-as-code mund t’i shfrytëzoni.
Nëse po zgjeroni një aplikacion ekzistues dhe po shtoni funksione pa server në mënyrë graduale, kjo mund të kufizojë disi mundësitë e disponueshme. Megjithatë, pothuajse të gjitha teknologjitë pa server ofrojnë disa API (nëpërmjet REST ose radhëve të mesazheve), që lejojnë krijimin e zgjerimeve të pavarura nga bërthama e aplikacionit dhe me integrim të lehtë. Kërkoni shërbime me API të qarta, dokumentacion të shkëlqyer dhe një komunitet të fortë, dhe nuk do të gaboni. Lehtësia e integrimit shpesh mund të jetë një metrikë kyçe, dhe ndoshta kjo është një nga arsyet kryesore për suksesin e AWS që prej lançimit të Lambda në vitin 2015.
Kur është e dobishme pa server
Teknologjitë pa server mund të aplikohen praktikisht kudo. Megjithatë, avantazhet e tyre nuk kufizohen vetëm në mënyrat e aplikimit. Pika e hyrjes për llogaritjet në cloud sot është mjaft e ulët falë teknologjive pa server. Nëse zhvilluesit kanë një ide, por nuk e dinë se si të menaxhojnë infrastrukturën në cloud dhe të optimizojnë kostot, ata nuk kanë nevojë të kërkojnë ndonjë inxhinier për këtë. Nëse një startup dëshiron të krijojë një platformë, por frikësohet se kostot mund të dalin jashtë kontrollit, ai mund të kthehet lehtësisht në zgjidhjet pa server.
Falë kursimit të kostove dhe lehtësisë së shkallëzimit, zgjidhjet pa server janë po aq të aplikueshme për sistemet e brendshme si për të jashtmet, deri në një aplikacion web me një audiencë prej milionash. Faturat nuk matën më në euro, por në cent. Qiraja e instancës më të thjeshtë të AWS EC2 (t1.micro) për një muaj do të kushtojë €15, edhe nëse nuk bëni asgjë me të (kush nuk ka harruar ndonjëherë ta fikë?!). Për krahasim, për të arritur një nivel të tillë shpenzimesh për të njëjtin periudhë, do t’ju duhej të kryeni Lambda me madhësi 512 MB për 1 sekondë rreth 3 milion herë. Dhe nëse nuk e përdorni këtë funksion, nuk paguani asgjë.
Pasi teknologjia pa server varet kryesisht nga ngjarjet, është mjaft e lehtë të shtoni infrastrukturë pa server në sistemet e vjetra. Për shembull, me AWS S3, Lambda dhe Kinesis mund të krijoni një shërbim analitik për një sistem të vjetër shitjesh që mund të marrë të dhëna përmes API-së.
Shumica e platformave pa server mbështesin gjuhë të ndryshme. Më shpesh ato janë Python, JavaScript, C#, Java dhe Go. Në përgjithësi, nuk ka kufizime për përdorimin e bibliotekave në të gjitha gjuhët, prandaj mund të përdorni bibliotestat tuaja të preferuara open source. Megjithatë, është e preferueshme të mos abuzoni me varësitë, në mënyrë që funksionet tuaja të ekzekutoheshin në mënyrë optimale dhe të mos e humbnin përparësinë e shkallëzueshmërisë së madhe të aplikacioneve tuaja pa server. Sa më shumë paketa të duhet të ngarkosh në konteiner, aq më gjatë do të zgjasë nisja e ftohtë.
Nisja e ftohtë është kur duhet së pari të inicializoni konteinerin, mjedisin e ekzekutimit dhe trajtuesin e gabimeve para se t'i përdorni ato. Si rrjedhim, vonesa e ekzekutimit të funksioneve mund të arrijë deri në 3 sekonda, dhe kjo nuk është një mundësi e mirë për përdoruesit e padurueshëm. Megjithatë, nisjet e ftohta ndodhin kur bëhet një kërkesë për herë të parë pas disa minutash pushimi të funksionit. Prandaj, shumë e konsiderojnë këtë një shqetësim të vogël, që mund të anashkalohet me ping të rregullt të funksionit, për ta mbajtur atë në gjendje të papërdorur. Ose madje e injorojnë këtë aspekt.
Megjithëse AWS lëshoi, megjithatë SQL-të nuk janë ideale për këtë përdorim, pasi kur realizohen transaksionet ato varen nga lidhjet, të cilat mund të bëhen shpejt një vendngusht në trafik të madh në AWS Lambda. Po, zhvilluesit vazhdojnë të përmirësojnë Serverless Aurora, dhe duhet të eksperimentoni me të, megjithatë sot për sistemet pa server janë më të përshtatshme zgjidhjet NoSQL si. Megjithatë, padyshim, kjo situatë do të ndryshojë shumë shpejt.
Vegla gjithashtu imponon shumë kufizime, sidomos në fushën e testimit lokal. Edhe pse ka zgjidhje si Docker-Lambda, DynamoDB Local dhe LocalStack, ato kërkojnë punë të kujdesshme dhe një sasi të konsiderueshme konfigurimi. Megjithatë, të gjitha këto projekte janë duke u zhvilluar aktivisht, prandaj është vetëm çështje kohe kur vegla do të arrijë nivelin që na nevojitet.
Ndikimi i teknologjive pa server në ciklin e zhvillimit
Duke qenë se infrastruktura juaj përbën thjesht një konfigurim, mund të vishni dhe të shpërndani kodin me ndihmën e skripteve, si p.sh. skripte shell. Ose mund të përdorni zgjidhje të klasës configuration-as-code si . Edhe pse ky shërbim nuk ofron konfigurim për të gjitha fushat, ai lejon të përcaktoni burime specifike për t'u përdorur si funksione Lambda. Pra, aty ku CloudFormation ju lë pas, mund të shkruani burimin tuaj (funksionin Lambda), i cili do të mbulonte këtë boshllëk. Kështu mund të bëni çfarëdo, madje edhe të konfiguroni varësitë jashtë mjedisit tuaj AWS.
Duke qenë se gjithçka është thjesht konfigurim, mund të parametrizoni skriptet tuaja të shpërndarjes për ambiente specifike, rajone dhe përdorues, sidomos nëse aplikoni zgjidhje të klasës infrastructure-as-code si CloudFormation. Për shembull, mund të shpërndani një kopje të infrastrukturës për çdo degë në dep, në mënyrë që t'i testoni ato plotësisht të izoluara gjatë zhvillimit. Kjo e përshpejton radikalisht marrjen e feedback-ut nga zhvilluesit, kur duan të kuptojnë nëse kodi i tyre funksionon siç duhet në një mjedis të gjallë. Menaxherit nuk i nevojitet të shqetësohet për koston e shpërndarjes së shumë ambienteve, pasi paguhet vetëm për përdorimin aktual.
DevOps ka më pak brenga, pasi ata duhet vetëm të sigurohen që zhvilluesit kanë konfigurimin e duhur. Nuk është më e nevojshme të menaxhohen instancat, balansuesit e ngarkesës ose grupet e sigurisë. Prandaj, termin NoOps po e përdorin gjithnjë e më shumë, megjithatë ende është e rëndësishme të jeni në gjendje të konfiguroni infrastrukturën, sidomos kur bëhet fjalë për konfigurimin IAM dhe optimizimin e burimeve të cloud.
Ka mjete shumë të fuqishme për monitorimin dhe vizualizimin si Epsagon, Thundra, Dashbird dhe IOPipe. Ato lejojnë të ndjekin gjendjen aktuale të aplikacioneve pa server, ofrojnë regjistra dhe gjurmime, regjistrojnë metrikat e performancës dhe ngushticat e arkitekturës, kryejnë analiza dhe parashikime të shpenzimeve, dhe shumë më tepër. Ato jo vetëm se u japin inxhinierëve DevOps, zhvilluesve dhe arkitektëve një pamje të plotë mbi funksionimin e aplikacioneve, por gjithashtu u lejojnë menaxherëve të ndjekin situatën në kohë reale, me shpenzime për burimet dhe parashikimin e kostove në sekonda. Të organizosh diçka të tillë me infrastrukturë të menaxhuar është shumë më e vështirë.
Projektimi i aplikacioneve pa server është shumë më i lehtë, sepse nuk keni nevojë të shpërndani serverë web, të menaxhoni makina virtuale ose kontejnerë, të rregulloni serverët, sistemet operative, porta interneti etj. Abstraktimi nga të gjitha këto detyra lejon që architektura pa server të përqendrohet në të rëndësishme — në zgjidhjen e nevojave të biznesit dhe klientëve.
Megjithëse mjetet mund të ishin më të mira (ato përmirësohen çdo ditë), zhvilluesit mund të përqendrohen në zbatimin e logjikës së biznesit dhe shpërndarjen më të mirë të kompleksitetit të aplikacionit në shërbime të ndryshme brenda arkitekturës. Menaxhimi i aplikacioneve pa server bëhet në bazë të ngjarjeve dhe është i abstraktuar nga ofruesi i cloud (p.sh., SQS, ngjarjet S3 ose rrjedhat DynamoDB). Prandaj zhvilluesve u duhet vetëm të shkruajnë logjikën e biznesit për t'iu përgjigjur ngjarjeve të caktuara dhe nuk kanë nevojë të shqetësohen për mënyrën më të mirë për të implementuar bazat e të dhënave dhe radhët e mesazheve, ose si të organizojnë një punë optimale me të dhënat në ruajtjet specifike të harduerit.
Kodi mund të ekzekutohet dhe debugohet lokal, ashtu siç ndodh me çdo proces zhvillimi. Testimi modular mbetet i njëjtë. Mundësia për të implementuar një infrastrukturë të tërë aplikacionesh përmes një konfigurimi të personalizuar të stack-it, i lejon zhvilluesve të marrin shpejt feedback të rëndësishëm, pa menduar për kostot e testimit ose për ndikimin në mjediset e menaxhuara me kosto të lartë.
Mjetet dhe metodat për ndërtimin e aplikacioneve pa server
Nuk ka një mënyrë specifike për ndërtimin e aplikacioneve pa server. Po ashtu, asnjë grup shërbimesh për këtë detyrë. Lideri ndër zgjidhjet e fuqishme pa server sot është AWS, megjithatë, mos harroni edhe , dhe . Nëse përdorni AWS, si një qasje për ndërtimin e aplikacioneve mund të rekomandohet (SAM), veçanërisht kur përdorni C#, pasi në Visual Studio ka një instrumentar të shkëlqyer. SAM CLI mund të bëjë të njëjtat gjëra si Visual Studio, kështu që nuk do të humbisni asgjë nëse kaloni në IDE ose editor tjetër. Sigurisht, SAM punon edhe me gjuhë të tjera.
Nëse shkruani në gjuhë të tjera, Serverless Framework është një mjet fantastik open source që lejon konfigurimin e çdo gjëje përmes skedarëve të fuqishëm YAML. Gjithashtu, Serverless Framework mbështet shërbime të ndryshme në cloud, kështu që e rekomandojmë atyre që kërkojnë një zgjidhje multi-cloud. Ka një komunitet të madh që ka krijuar shumë plugins për çdo nevojë.
Për testim lokal, mjetet open source si Docker-Lambda, Serverless Local, DynamoDB Local dhe LocalStack janë të mira. Teknologjitë pa server janë ende në një fazë të hershme të zhvillimit, ashtu si dhe mjetet për to, kështu që gjatë konfigurimit për skenarë të ndërlikuar testimi do të duhet të punoni. Megjithatë, të implementoni një stack në një mjedis dhe të testoni atje është jashtëzakonisht e lirë. Dhe nuk keni nevojë të krijoni një kopje të saktë lokale të mjediseve cloud.
Përdorni AWS Lambda Layers për të zvogëluar përmasat e paketimeve të implementuara dhe për të përshpejtuar ngarkimin.
Përdorni gjuhët e programimit të duhura për detyrat specifike. Çdo gjuhë ka avantazhe dhe disavantazhe të saj. Ka shumë benchmarke, por JavaScript, Python dhe C# (.NET Core 2.1+) janë liderë në aspektin e performancës së AWS Lambda. Kohët e fundit, AWS Lambda ka sjellë Runtime API, i cili ju lejon të specifikoni gjuhën dhe ambientin e dëshiruar, prandaj eksperimentoni.
Mbani përmasat e vogla të paketimeve për implementim. Sa më të vogla të jenë, aq më shpejt ngarkohen. Shmangni përdorimin e bibliotekave të mëdha, veçanërisht nëse përdorni vetëm disa funksione nga to. Nëse programoni në JavaScript, përdorni mjete ndërtimi si Webpack për të optimizuar ndërtimin dhe përfshirë vetëm ato që ju nevojiten. Në .NET Core 3.0 ka QuickJit dhe Tiered Compilation, të cilat përmirësojnë performancën dhe ndihmojnë shumë në ngarkimet e ftohta.
Varësia e funksioneve pa server nga ngjarjet mund të komplikojë fillimisht koordinimin e logjikës së biznesit. Në këtë drejtim, radhët e mesazheve dhe automatet e fundi mund të jenë jashtëzakonisht të dobishme. Funksionet Lambda mund të thërrasin njëra-tjetrën, por bëni këtë vetëm nëse nuk prisni një përgjigje ("qëllove dhe harrove") — nuk doni të merrni faturë për pritjen e përfundimit të ndonjë funksioni tjetër. Radhët e mesazheve janë të dobishme për izolimin e pjesëve të logjikës së biznesit, menaxhimin e ngushticave të aplikacioneve dhe përpunimin e transaksioneve (përmes radhëve FIFO). Funksionet AWS Lambda mund të lidhen me radhët SQS si radhë "të ngecura" mesazhesh, që ndjekin mesazhet e dështuara për analizë të mëvonshme. Funksionet AWS Step Functions (automatet e fundi) janë shumë të dobishme për menaxhimin e proceseve komplekse që kërkojnë krijimin e zinxhirëve të funksioneve. Në vend që një funksion Lambda të thërrasë një funksion tjetër, funksionet e fundit mund të koordinojnë kalimet e gjendjeve, të transmetojnë të dhëna midis funksioneve dhe të menaxhojnë gjendjen globale të funksioneve. Kjo lejon përcaktimin e kushteve për provat e përsëritura, ose se çfarë duhet bërë në rastin e një gabimi specifik — në kushte të caktuara, një mjet shumë fuqishëm.
Përfundimi
Në disa vitet e fundit, teknologjitë pa server janë zhvilluar me një ritëm të paimagjinueshëm. Kjo ndërrim paradigme ka sjellë disa keqkuptime. Falë abstragimit të infrastrukturës dhe menaxhimit të shkallëzimit, zgjidhjet pa server ofrojnë përfitime të konsiderueshme: nga thjeshtimi i zhvillimit dhe proceseve DevOps, deri te një ulje të madhe të kostove operative.
Edhe pse qasja pa server ka disavantazhe, ekzistojnë metoda të besueshme dhe modele dizajni për të krijuar aplikacione pa server ose për të integruar elemente pa server në arkitektonitë ekzistuese.
Burimi: habr.com
