Ndryshe nga teknologjitë pa server që kanë fituar popullaritet në vitet e fundit, ka akoma shumë keqkuptime dhe shqetësime në lidhje me to. Varësia nga furnizuesi, mjete të ndryshme, menaxhimi i shpenzimeve, fillimi i ftohtë, monitorimi dhe cikli i jetës së zhvillimit - të gjitha këto tema diskutohet aktivisht kur flitet për teknologjitë pa server. Në këtë artikull do të shqyrtojmë disa nga temat e përmendura dhe do të ndajmë këshilla dhe lidhje për burime të dobishme, me ndihmën e të cilave fillestarët mund 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 trajtimi i dhënave jashtë serverit (, FaaS) janë pothuajse të njëjta. Kështu, diferenca nuk është aq e madhe dhe ia vlen të implementohet risi. Ndërsa AWS Lambda ka qenë një nga "yjet" e arritjes së teknologjive pa server dhe një nga elementët më të njohur të arkitekturës pa server, megjithatë, kjo arkitekturë përbën më shumë se sa FaaS.
Princpi kryesor i teknologjive pa server është se nuk keni nevojë të shqetësoheni për menaxhimin dhe shkallëzimin e infrastrukturës, paguani vetëm për atë që përdorni. Nën këto kritere në të vërtetë përfshihen shumë shërbime - AWS DynamoDB, S3, SNS ose SQS, Graphcool, Auth0, Now, Netlify, Firebase dhe shumë të tjera. Në përgjithësi, pa server nënkupton shfrytëzimin e të gjitha mundësive të llogarive në cloud pa nevojën e menaxhimit dhe optimizimit të infrastrukturës për shkak të shkallëzimit. Po ashtu, kjo do të thotë se siguria në nivelin e infrastrukturës më nuk është problemi juaj, që është një përparësi e madhe, duke marrë parasysh vështirësinë dhe kompleksitetin e ruajtjes së standardeve të sigurisë. Më në fund, nuk keni nevojë të bleni infrastrukturën që ju ofrohet për përdorim.
Pa serverin mund ta konsideroni si "një gjendje mendimi": një mendësi të veçantë në projektimin e zgjidhjeve. Shmangni qasjet që kërkojnë mirëmbajtjen e çdo infrastrukture. Me qasjen pa server, ne i kushtojmë kohë zgjidhjeve që ndikojnë drejtpërdrejt në projekt dhe sjellin përfitime për përdoruesit tanë: krijojmë logjikë të qëndrueshme të biznesit, zhvillojmë ndërfaqet e përdoruesit dhe krijojmë API të adaptueshme dhe të besueshme.
Për shembull, nëse është e mundur të shmangni menaxhimin dhe mbështetje e platformës së kërkimit të lirë të tekstit, kështu do të veprojmë. Ky qasje ndaj ndërtimit të aplikacioneve është në gjendje të përshpejtojë shumë nxjerrjen e produktit në treg, sepse nuk keni më nevojë të mendoni për menaxhimin e një infrastrukture të ndërlikuar. Shkëputuni nga detyrat dhe shpenzimet për menaxhimin e infrastrukturës dhe përqendrohuni në krijimin e aplikacioneve dhe shërbimeve që i nevojiten klientëve tuaj. Patrick Debois e quajti këtë qasje , ky term është pranuar në komunitetin pa serverë. Funksionet duhet të merren në konsideratë si një lidhës për shërbimet në formën e moduleve të zhvilluara (në vend të zhvillimit të gjithë bibliotekës ose aplikacionit web). Kjo siguron një granularitet të pabesueshëm në menaxhimin e implementimit dhe ndryshimeve në aplikacion. Nëse nuk mund të zhvilloni funksionet në këtë mënyrë, atëherë kjo mund të tregojë që funksionet po kryejnë shumë detyra dhe duhet të refaktorizohen.
Disa disa njerëz shqetësohen për varësinë nga ofruesit gjatë zhvillimit të aplikacioneve në re. E njëjta gjë vlen për teknologjitë pa server, dhe ndoshta këtë e shkakton një keqkuptim. Sipas përvojës sonë, krijimi i aplikacioneve pa server në AWS, duke bashkuar me aftësinë e AWS Lambda për të integruar shërbime të tjera AWS — gjithçka kjo formon pjesërisht avantazhet e arkitekturave pa server. Kjo është një shembull i mirë i sinergjisë, ku rezultati i bashkimit është më i madh se thjesht shuma e elementeve të saj. 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ë shërbimeve në re. Por kur vjen puna te zgjidhjet pa server, përpjekjet nuk do të kompensohen, veçanërisht nëse nga fillimi merrni parasysh efikasitetin ekonomik. Sigurohuni të kuptoni si ofruesit sigurojnë shërbimet. Disa shërbime të specializuara varen nga pikat e integrimit me ofrues të tjerë dhe mund të ofrojnë mundësinë e lidhjes plug-and-play që nga kutia. Është më e lehtë të sigurohet thirrja e Lambda nga një pikë finale e API-së sesa të prokurohet një kërkesë në ndonjë kontejner ose instancë EC2. Graphcool ofron konfigurim të lehtë me Auth0, dhe kjo është më e lehtë se përdorimi i mjeteve të jashtme të autentifikimit.
Zgjedhja e ofruesit të duhur për aplikacionin tuaj pa server është një vendim në nivel arkitektonik. Kur zhvilloni një aplikacion, nuk prisni që një ditë të ktheheni në menaxhimin e serverëve. Zgjedhja e ofruesit në re nuk është ndryshe nga zgjedhja e përdorimit të kontejnerëve, bazës së të dhënave, ose madje edhe gjuhës së programimit.
Mendoni:
- Cilat shërbime keni nevojë dhe pse.
- Cilat shërbime ofrohen nga ofruesit e shërbimeve në re dhe si mund t'i bashkoni ato me zgjidhjen tuaj të FaaS-it të zgjedhur.
- Cilat gjuhë programimi mbështeten (me tipar dinamik ose statik, të kompiluara ose të interpretuara, cilat janë benchmark-et, cila është performanca gjatë nisjes së ftohtë, si është ekosistemi open source, etj.).
- Cilat janë kërkesat tuaja për sigurinë (SLA, 2FA, OAuth, HTTPS, SSL, etj.).
- Si të menaxhoni CI/CD tuaj dhe ciklet e zhvillimit të softuerit.
- Cilat avantazhe mund të përfitoni nga zgjidhjet e klasës infrastructure-as-code.
Nëse po zgjerohet një aplikacion ekzistues dhe po shtoni funksionalitete pa serverë në mënyrë inçremtale, kjo mund të kufizojë disi mundësitë e disponueshme. Megjithatë, pothuajse të gjitha teknologjitë pa server ofrojnë disa API (përmes REST ose radhëve të mesazheve), që lejojnë krijimin e zgjerimeve në mënyrë të pavarur nga thelbi i aplikacionit dhe me integrim të thjeshtë. Kërkoni shërbime me API të kuptueshme, dokumentacion të mirë dhe një komunitet të fortë, dhe nuk do gaboni. Thjeshtësia e integrimit shpesh mund të jetë një metrikë kyçe, dhe ndoshta kjo është një nga arsyet kryesore të suksesit të AWS që nga lançimi i Lambda në vitin 2015.
Kur është e dobishme pa serverë
Teknologjitë pa server mund të përdoren pothuajse kudo. Megjithatë, avantazhet e tyre nuk kufizohen vetëm në mënyrat e përdorimit. Pika e hyrjes për kompjuterët në re është sot aq e ulët pikërisht për shkak të teknologjive pa server. Nëse zhvilluesit kanë një ide, por nuk e dinë si të menaxhojnë infrastrukturën e re dhe të optimizojnë shpenzimet, 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 shpenzimet mund t'i dalin jashtë kontrollit, ata lehtësisht mund të drejtohen drejt zgjidhjeve pa server.
Falë kursimit të shpenzimeve dhe thjeshtësisë së shkallëzimit, zgjidhjet pa server janë po aq të aplikueshme për sistemet e brendshme ashtu si për ato të jashtme, deri në një aplikacion web me një audiencë shumë milionëshe. Faturat maten më shumë jo në euro, por në centë. Qiraja e exemplarit më të thjeshtë të AWS EC2 (t1.micro) për një muaj do t'ju kushtojë €15, pavarësisht nëse nuk bëni asgjë me të (kush nuk ka harruar ndonjëherë ta mbyllë?!). Për krahasim, për të arritur një nivel të tillë shpenzimesh për të njëjtin periudhë kohore, do t'ju nevojitet të startoni Lambda e madhësisë 512 MB për 1 sekondë rreth 3 milion herë. Dhe nëse nuk e përdorni këtë funksion, atëherë nuk paguani asgjë.
Duke qenë se teknologjia pa server varet kryesisht nga ngjarjet, është mjaft e lehtë të shtoni infrastrukturë pa server në sistemet e vjetra. Për shembull, me anë të AWS S3, Lambda dhe Kinesis mund të krijoni një shërbim analitik për një sistem të vjetër shitjesh, i cili do të mund të merrte të dhënat përmes API.
Shumica e platformave pa server mbështesin gjuhë të ndryshme. Më së shpeshti, këto janë Python, JavaScript, C#, Java dhe Go. Zakonisht, në të gjitha gjuhët nuk ka asnjë kufizim lidhur me përdorimin e biblioteka, kështu që mund të aplikoni bibliotekat tuaja të preferuara open source. Megjithatë, preferohet të mos abuzoni me varësitë, në mënyrë që funksionet tuaja të ekzekutohen optimalisht dhe të mos eliminojnë përfitimet e shkallëzueshmërisë së madhe të aplikacioneve tuaja pa server. Sa më shumë paketa të nevojiten për t'u ngarkuar në kontejner, aq më gjatë do të zgjasë fillimi i ftohtë.
Fillimi i ftohtë është ai kur është e nevojshme fillimisht të inicializoni kontejnerin, mjedisin e ekzekutimit dhe trajtuesin e gabimeve, përpara se t'i përdorni ato. Për shkak të kësaj, vonesa në ekzekutimin e funksioneve mund të arrijë deri në 3 sekonda, dhe kjo nuk është opsioni më i mirë për përdoruesit e padurueshëm. Megjithatë, fillimet e ftohta ndodhin pas vizitës së parë pas disa minutash pushimi të funksionit. Prandaj, shumë e konsiderojnë këtë një shqetësim të parëndësishëm, që mund të kalojë me ndihmën e pingimit të rregullt të funksionit për ta mbajtur atë në gjendje gatishmërie. Ose madje e injorojnë këtë aspekt tërësisht.
Megjithëse AWS ka lëshuar, prapëseprapë, bazat e të dhënave SQL nuk janë ideale për përdorim të tillë, pasi gjatë ekzekutimit të transaksioneve ato varen nga lidhjet, të cilat mund të shndërrohen shpejt në një ngushticë në rast të trafikut të madh në AWS Lambda. Po, zhvilluesit vazhdimisht po përmirësojnë Serverless Aurora, dhe do t'ju rekomandojmë të eksperimentoni me të, megjithatë sot, për sistemet pa server, zgjidhjet NoSQL sijanë shumë më të përshtatshme. Megjithatë, është e padiskutueshme se kjo situatë do të ndryshojë shumë shpejt.
Mjetet gjithashtu vendosin shumë kufizime, veçanërisht në fushën e testimit lokal. Edhe pse ekzistojnë zgjidhje si Docker-Lambda, DynamoDB Local dhe LocalStack, ato kërkojnë punë të përkushtuar dhe një sasi të konsiderueshme konfigurimi. Megjithatë, të gjitha këto projekte janë duke u zhvilluar aktivisht, kështu që është thjesht çështje kohe deri sa mjetet të arrijnë nivelin që na nevojitet.
Ndikimi i teknologjive pa server në ciklin e zhvillimit
Duke qenë se infrastruktura juaj paraqet thjesht një konfigurim, mund të vendosni dhe implementoni kodin përmes skriptove, si p.sh., skripteve shell. Apo mund të përdorni zgjidhje të klasës 'configuration-as-code' si . Megjithëse ky shërbim nuk ofron një konfigurim për të gjitha fushat, ai lejon të përcaktohen burime specifike për t'u përdorur si funksione Lambda. Do të thotë që aty ku CloudFormation do t'ju zhgënjejë, mund të shkruani burimin tuaj (funksionin Lambda) që do të mbulojë këtë boshllëk. Kështu, mund të bëni gjithçka, madje të konfiguroni varësi përtej mjedisit tuaj AWS.
Duke qenë se gjithçka është thjesht konfigurim, mund të parametrizoni skriptet tuaja të përdorimit për mjedise, rajone dhe përdorues specifikë, sidomos nëse përdorni 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ë repozitor, për të testuar ato në mënyrë plotësisht të izoluar 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ë. Drejtuesve nuk u duhet të shqetësohen për kostot e shpërndarjes së shumë mjediseve, pasi paguhet vetëm përdorimi aktual.
DevOps-it i bie më pak ngarkesë, pasi ata duhet vetëm të sigurojnë që zhvilluesit të kenë konfigurimin e saktë. Nuk është më e nevojshme të menaxhoni instancat, balancuesit e ngarkesës ose grupet e sigurisë. Prandaj, termini NoOps po përdoret gjithnjë e më shumë, ndonëse është ende e rëndësishme të dish si të konfiguroni infrastrukturën, veçanërisht kur bëhet fjalë për konfigurimin e IAM dhe optimizimin e burimeve në cloud.
Ekzistojnë mjete shumë të fuqishme për monitorimin dhe paraqitjen vizuale si Epsagon, Thundra, Dashbird dhe IOPipe. Ato lejojnë të ndjekin gjendjen aktuale të aplikacioneve pa server, ofrojnë regjistra dhe gjurmim, regjistrojnë metrika performancës dhe ngushticat e arkitekturës, kryejnë analiza dhe parashikimin e shpenzimeve, dhe shumë më tepër. Ato jo vetëm që u japin inxhinierëve DevOps, zhvilluesve dhe arkitektëve një pasqyrë të plotë të funksionimit të aplikacioneve, por gjithashtu u lejojnë drejtuesve të ndjekin situatën në kohë reale, me shpenzime për burimet për çdo sekondë dhe parashikimin e kostove. Të organizosh një gjë 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ë aplikoni patches për serverët, sistemet operative, portat e internetit, etj. Abstraktimi nga të gjitha këto detyra lejon arkitekturën pa server të përqendrohet në atë që është më kryesor — 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ë implementimin e logjikës së biznesit dhe në shpërndarjen më të mirë të kompleksitetit të aplikacionit në shërbime të ndryshme brenda arkitekturës. Menaxhimi i aplikacioneve pa server bëhet mbi baza të ngjarjeve dhe është i abstrahuar nga ofruesi i cloud (p.sh., SQS, ngjarjet S3 ose rrjedhat DynamoDB). Prandaj, zhvilluesit vetëm duhet të shkruajnë logjikën e biznesit për të reaguar ndaj ngjarjeve të caktuara dhe nuk ka 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 për të organizuar punën optimale me të dhënat në depozita të veçanta harduore.
Kodi mund të ekzekutohet dhe debugohet lokal, ashtu si në çdo proces zhvillimi. Testimi modular mbetet i njëjtë. Mundësia për të shpërndarë tërë infrastrukturën e aplikacionit duke përdorur një konfigurim të personalizuar të stekës lejon zhvilluesit të marrin shpejt një feedback të rëndësishëm, pa menduar për kostot e testimit ose ndikimin në mjediset e menaxhuara të shtrenjta.
Mjetet dhe metodat për ndërtimin e aplikacioneve pa server
Nuk ka një mënyrë specifike për të ndërtuar aplikacione pa server. As një grup shërbesh për këtë detyrë. Sot, AWS është lideri mes zgjidhjeve të fuqishme pa server, por gjithashtu kërkoni , dhe . Nëse po përdorni AWS, për një qasje ndaj ndërtimit të aplikacioneve, mund të rekomandohet (SAM), veçanërisht kur përdorni C#, pasi në Visual Studio ka mjete të shkëlqyera. SAM CLI mund të bëjë të njëjtat gjëra si Visual Studio, kështu që nuk do të humbni asgjë nëse kaloni në një IDE tjetër ose në një redaktues teksti. Sigurisht, SAM funksionon edhe me gjuhë të tjera.
Nëse shkruani në gjuhë të tjera, atëherë Serverless Framework është një mjet open source i shkëlqyer, që lejon të konfiguroni gjithçka përmes skedarëve shumë të fuqishëm të konfigurimit YAML. Gjithashtu, Serverless Framework mbështet shërbime të ndryshme në cloud, prandaj e rekomandojmë për ata që kërkojnë një zgjidhje shumë-cloud. Ai ka një komunitet të madh që ka krijuar shumë plugina për nevoja të ndryshme.
Për testimin lokal, mjetet open source si Docker-Lambda, Serverless Local, DynamoDB Local dhe LocalStack janë të përshtatshme. Teknologjitë pa server janë ende në një fazë të hershme zhvillimi, ashtu si mjetet për to, kështu që mund të kenë vështirësi gjatë konfigurimit për skenarë testimi të ndërlikuar. Megjithatë, është jashtëzakonisht e lirë të vendosni një mënyrë në ambient dhe ta testoni atje. Dhe nuk keni nevojë të bëni një kopje të saktë lokale të mjediseve të cloud.
Për të reduktuar përmasat e paketave të vendosura dhe për të përshpejtuar ngarkimin, përdorni AWS Lambda Layers.
Përdorni gjuhët e programimit të duhura për detyra specifike. Gjuha të ndryshme kanë avantazhe dhe disavantazhe të ndryshme. Ka shumë benchmarke, por JavaScript, Python dhe C# (.NET Core 2.1+) janë liderët në aspektin e performancës së AWS Lambda. Kohët e fundit, në AWS Lambda është shtuar Runtime API, i cili lejon të specifikoni gjuhën dhe ambientin e dëshiruar, prandaj eksperimentoni.
Mbanim përmasat e vogla të paketave për vendosje. Sa më të vogla të jenë ato, aq më shpejt ngarkohen. Shmangni përdorimin e bibliotekave të mëdha, veçanërisht nëse përdorni vetëm disa funksione prej tyre. Nëse po programoni në JavaScript, përdorni mjete ndërtimi si Webpack për të optimizuar ndërtimin dhe për të përfshirë vetëm atë që ju nevojitet vërtet. Në .NET Core 3.0 ka QuickJit dhe Tiered Compilation, të cilat përmirësojnë performancën dhe ndihmojnë ndjeshëm në nisjet e ftohta.
Varësia e funksioneve pa server nga ngjarjet në fillim mund të shqetësojë koordinimin e logjikës së biznesit. Për këtë arsye, radhët e mesazheve dhe automatizmat e përfundimeve mund të jenë jashtëzakonisht të dobishme. Funksionet Lambda janë në gjendje të thërrasin njëra-tjetrën, por bëni këtë vetëm nëse nuk prisni një përgjigje (“e qëllove dhe e harrove”) — nuk doni të merrni një faturë për pritjen e përfundimit të një funksioni tjetër. Radhët e mesazheve janë të dobishme për të ndarë pjesët e logjikës së biznesit, për të menaxhuar ngushticat e aplikacioneve dhe për të përpunuar transaksionet (me radhët FIFO). Funksionet AWS Lambda mund të lidhen me radhët SQS si radhë të “ngecur” mesazhesh, të cilat monitorojnë mesazhet e dështuar për analizë të mëvonshme. Funksionet AWS Step (automatizmat e përfundimeve) janë jashtëzakonisht të dobishme për të menaxhuar procese komplekse që kërkojnë krijimin e zinxhirëve funksionesh. Në vend që funksioni Lambda të thërrasë një funksion tjetër, funksionet Step mund të koordinojnë kalimet e gjendjeve, të kalojnë të dhëna midis funksioneve dhe të menaxhojnë gjendjen globale të funksioneve. Kjo lejon përcaktimin e kushteve të tentativave të përsëritura, ose çfarë duhet bërë në rastin e një gabimi të veçantë — në kushte të caktuara një mjet shumë të fuqishëm.
Përfundim
Në vitet e fundit, teknologjitë pa server po zhvillohen me një ritëm të paparë. Me këtë ndryshim paradigme lidhen disa keqkuptime. Falë abstrahimit të infrastrukturës dhe menaxhimit të shkallëzimit, zgjidhjet pa server ofrojnë përfitime të konsiderueshme: nga thjeshtësimi i zhvillimit dhe proceseve DevOps, në një ulje të madhe të shpenzimeve operative.
Dhe ndonëse qasja pa server ka të metat e saj, ekzistojnë metodologji të besueshme dhe modele dizajni, me të cilat mund të krijoni aplikacione pa server të qëndrueshme ose të integroheni elemente pa server në arkitekturat e ekzistuese.
Burimi: habr.com
