Megjithëse teknologjitë pa server kanë fituar me shpejtësi popullaritet vitet e fundit, ka ende shumë keqkuptime dhe frika që lidhen me to. Varësia nga shitësi, veglat e punës, menaxhimi i kostos, fillimi i ftohtë, monitorimi dhe cikli jetësor i zhvillimit janë të gjitha tema të nxehta kur bëhet fjalë për teknologjitë pa server. Në këtë artikull, ne do të shqyrtojmë disa nga temat e përmendura, si dhe do të ndajmë këshilla dhe lidhje me burime të dobishme informacioni për të ndihmuar fillestarët të krijojnë aplikacione të fuqishme, fleksibël dhe me kosto efektive pa server.
Keqkuptime rreth teknologjive pa server
Shumë njerëz mendojnë se përpunimi pa server dhe pa server (, FaaS) janë pothuajse e njëjta gjë. Kjo do të thotë se ndryshimi nuk është shumë i madh dhe ia vlen të prezantohet një risi. Megjithëse AWS Lambda ishte një nga yjet e lulëzimit pa server dhe një nga elementët më të njohur të arkitekturës pa server, megjithatë, kjo arkitekturë është shumë më tepër se FaaS.
Parimi bazë që qëndron pas teknologjive pa server është se nuk duhet të shqetësoheni për menaxhimin dhe shkallëzimin e infrastrukturës suaj, ju paguani vetëm për atë që përdorni. Shumë shërbime i përshtaten këtyre kritereve - AWS DynamoDB, S3, SNS ose SQS, Graphcool, Auth0, Now, Netlify, Firebase dhe shumë të tjerë. Në përgjithësi, pa server do të thotë të përdorni fuqinë e plotë të kompjuterit cloud pa pasur nevojë të menaxhoni infrastrukturën dhe ta optimizoni atë për shkallëzim. Kjo do të thotë gjithashtu se siguria në nivelin e infrastrukturës nuk është më shqetësimi juaj, gjë që është një përfitim i madh duke pasur parasysh vështirësinë dhe kompleksitetin e përmbushjes së standardeve të sigurisë. Së fundi, nuk keni pse të blini infrastrukturën që ju ofrohet.
Pa server mund të konsiderohet një "gjendje shpirtërore": një mentalitet i caktuar gjatë hartimit të zgjidhjeve. Shmangni qasjet që kërkojnë mirëmbajtje të çdo infrastrukture. Me një qasje pa server, ne shpenzojmë kohë duke zgjidhur detyra që ndikojnë drejtpërdrejt në projekt dhe sjellin përfitime për përdoruesit tanë: ne krijojmë logjikë të qëndrueshme biznesi, zhvillojmë ndërfaqe të përdoruesit dhe zhvillojmë API adaptive dhe të besueshme.
Për shembull, nëse është e mundur të shmangni menaxhimin dhe mirëmbajtjen e një platforme kërkimi teksti falas, atëherë kjo është ajo që ne do të bëjmë. Kjo qasje për ndërtimin e aplikacioneve mund të përshpejtojë shumë kohën për të dalë në treg, sepse nuk keni më nevojë të mendoni për menaxhimin e infrastrukturës komplekse. Eliminoni përgjegjësitë dhe kostot e menaxhimit të infrastrukturës dhe fokusohuni në ndërtimin e aplikacioneve dhe shërbimeve që u nevojiten klientëve tuaj. Patrick Debois e quajti këtë qasje , termi është adoptuar në komunitetin pa server. Funksionet duhet të mendohen si një lidhje me shërbimet si module të dislokueshme (në vend që të vendoset një bibliotekë e tërë ose një aplikacion ueb). Kjo siguron një shkallëzim të jashtëzakonshëm për menaxhimin e vendosjes dhe ndryshimeve në aplikacion. Nëse nuk mund të vendosni funksione në këtë mënyrë, atëherë mund të tregojë se funksionet kryejnë shumë detyra dhe duhet të rifaktorohen.
Disa janë të hutuar nga varësia nga shitësi kur zhvillojnë aplikacione cloud. E njëjta gjë është e vërtetë me teknologjitë pa server, dhe ky nuk është një ide e gabuar. Në përvojën tonë, ndërtimi i aplikacioneve pa server në AWS, i kombinuar me aftësinë e AWS Lambda për të bashkuar shërbime të tjera AWS së bashku, është pjesë e fuqisë së arkitekturave pa server. Ky është një shembull i mirë i sinergjisë, kur rezultati i kombinimit është më shumë se vetëm shuma e termave. Përpjekja për të shmangur varësinë nga shitësi mund të hasë edhe më shumë probleme. Kur punoni me kontejnerë, është më e lehtë të menaxhoni shtresën tuaj të abstraksionit midis ofruesve të cloud. Por kur bëhet fjalë për zgjidhjet pa server, përpjekja nuk do të shpërblehet, veçanërisht nëse kosto-efektiviteti merret parasysh që në fillim. Sigurohuni që të zbuloni se si shitësit ofrojnë shërbime. Disa shërbime të specializuara mbështeten në pikat e integrimit me shitësit e tjerë dhe mund të ofrojnë lidhje plug-and-play jashtë kutisë. Është më e lehtë të ofrosh një telefonatë Lambda nga një pikë fundore e API-së së portës, sesa të përcaktosh kërkesën në ndonjë kontejner ose shembull EC2. Graphcool siguron konfigurim të lehtë me Auth0, gjë që është më e lehtë sesa përdorimi i mjeteve të vërtetimit të palëve të treta.
Zgjedhja e shitësit të duhur për aplikacionin tuaj pa server është një vendim arkitektonik. Kur krijoni një aplikacion, nuk prisni që një ditë të ktheheni në menaxhimin e serverëve. Zgjedhja e një shitësi cloud nuk është ndryshe nga zgjedhja e përdorimit të kontejnerëve ose një bazë të dhënash, apo edhe një gjuhë programimi.
Merrni parasysh:
- Cilat shërbime ju nevojiten dhe pse.
- Çfarë shërbimesh ofrojnë ofruesit e reve kompjuterike dhe si mund t'i kombinoni ato me zgjidhjen tuaj të zgjedhur FaaS.
- Cilat gjuhë programimi mbështeten (me shtypje dinamike ose statike, të përpiluara ose të interpretuara, cilat janë standardet, cila është performanca në fillimin e ftohtë, cili është ekosistemi me burim të hapur, etj.).
- Cilat janë kërkesat tuaja të sigurisë (SLA, 2FA, OAuth, HTTPS, SSL, etj.).
- Si të menaxhoni ciklet tuaja CI/CD dhe të zhvillimit të softuerit.
- Cilat zgjidhje infrastrukturore si kod mund të përfitoni.
Nëse zgjeroni një aplikacion ekzistues dhe shtoni funksionalitete pa server, kjo mund të kufizojë disi aftësitë e disponueshme. Megjithatë, pothuajse të gjitha teknologjitë pa server ofrojnë një lloj API (nëpërmjet REST ose radhëve të mesazheve) që ju lejon të krijoni shtesa të pavarura nga bërthama e aplikacionit dhe me integrim të lehtë. Kërkoni shërbime me API të qarta, dokumentacion të mirë dhe një komunitet të fortë dhe nuk mund të gaboni. Lehtësia e integrimit shpesh mund të jetë një metrikë kryesore dhe ndoshta është një nga arsyet kryesore pse AWS ka qenë kaq i suksesshëm që kur Lambda u lëshua në 2015.
Kur pa server është i mirë
Teknologjitë pa server mund të aplikohen pothuajse kudo. Megjithatë, avantazhet e tyre nuk kufizohen vetëm në një mënyrë aplikimi. Barriera e hyrjes për kompjuterin cloud sot është kaq e ulët falë teknologjive pa server. Nëse zhvilluesit kanë një ide, por ata nuk dinë të menaxhojnë infrastrukturën cloud dhe të optimizojnë kostot, atëherë ata nuk kanë nevojë të kërkojnë një lloj inxhinieri për ta bërë atë. Nëse një startup dëshiron të ndërtojë një platformë, por ka frikë se kostot mund të dalin jashtë kontrollit, ata mund t'i drejtohen lehtësisht zgjidhjeve pa server.
Për shkak të kursimeve të kostos dhe lehtësisë së shkallëzimit, zgjidhjet pa server janë njëlloj të zbatueshme si për sistemet e brendshme ashtu edhe për ato të jashtme, deri në një aplikacion ueb me një audiencë shumë milionëshe. Llogaritë maten më tepër se në euro, por në cent. Marrja me qira e shembullit 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 kurrë ta fiket?!). Në krahasim, për të arritur këtë nivel shpenzimesh për të njëjtën periudhë kohore, do t'ju duhet të përdorni një Lambda 512 MB për 1 sekondë rreth 3 milionë herë. Dhe nëse nuk e përdorni këtë veçori, atëherë nuk paguani asgjë.
Për shkak se pa server është kryesisht i drejtuar nga ngjarjet, është mjaft e lehtë të shtosh një infrastrukturë pa server në sistemet e vjetra. Për shembull, duke përdorur AWS S3, Lambda dhe Kinesis, mund të krijoni një shërbim analitik për një sistem të vjetër të shitjes me pakicë që mund të marrë të dhëna përmes një API.
Shumica e platformave pa server mbështesin shumë gjuhë. Më shpesh është Python, JavaScript, C#, Java dhe Go. Zakonisht nuk ka kufizime në përdorimin e bibliotekave në të gjitha gjuhët, kështu që ju mund të përdorni bibliotekat tuaja të preferuara me burim të hapur. Megjithatë, këshillohet të mos abuzoni me varësitë në mënyrë që funksionet tuaja të funksionojnë në mënyrë optimale dhe të mos mohojnë përfitimet e shkallëzueshmërisë së madhe të aplikacioneve tuaja pa server. Sa më shumë pako që duhet të ngarkohen në enë, aq më shumë do të zgjasë fillimi i ftohtë.
Një fillim i ftohtë është kur së pari duhet të inicializoni kontejnerin, kohën e funksionimit dhe mbajtësin e gabimeve përpara se t'i përdorni. Për shkak të kësaj, vonesa në ekzekutimin e funksioneve mund të jetë deri në 3 sekonda, dhe kjo nuk është alternativa më e mirë për përdoruesit e paduruar. Megjithatë, fillimet e ftohta ndodhin në telefonatën e parë pas disa minutave të funksionit boshe. Pra, shumë e konsiderojnë këtë një bezdi të vogël që mund të zgjidhet duke e tingëlluar rregullisht funksionin për ta mbajtur atë në punë. Ose e injorojnë fare këtë aspekt.
Edhe pse AWS u lëshuaMegjithatë, bazat e të dhënave SQL nuk janë ideale për këtë aplikacion, pasi ato varen nga lidhjet për të kryer transaksione, të cilat mund të bëhen shpejt një pengesë me trafik të rënduar në AWS Lambda. Po, zhvilluesit po përmirësojnë vazhdimisht Aurora pa server dhe ju duhet të eksperimentoni me të, por sot zgjidhjet NoSQL si. Megjithatë, nuk ka dyshim se kjo situatë do të ndryshojë shumë shpejt.
Paketa e veglave imponon gjithashtu shumë kufizime, veçanërisht në fushën e testimit lokal. Megjithëse ka zgjidhje si Docker-Lambda, DynamoDB Local dhe LocalStack, ato kërkojnë punë të palodhur dhe një sasi të konsiderueshme konfigurimi. Megjithatë, të gjitha këto projekte janë zhvilluar në mënyrë aktive, kështu që është vetëm çështje kohe para se paketa e mjeteve të arrijë nivelin që na nevojitet.
Ndikimi i teknologjive pa server në ciklin e zhvillimit
Për shkak se infrastruktura juaj është vetëm një konfigurim, ju mund të përcaktoni dhe vendosni kodin duke përdorur skriptet, të tilla si skriptet e guaskës. Ose mund t'i drejtoheni zgjidhjeve të klasës së konfigurimit si kod si p.sh . Megjithëse ky shërbim nuk ofron konfigurim për të gjitha zonat, ai ju lejon të përcaktoni burime specifike për t'u përdorur si funksione Lambda. Kjo do të thotë, aty ku CloudFormation ju dështon, ju mund të shkruani burimin tuaj (funksioni Lambda) që do të mbyllë këtë boshllëk. Në këtë mënyrë mund të bëni gjithçka, madje edhe të konfiguroni varësitë jashtë mjedisit tuaj AWS.
Për shkak se gjithçka është thjesht konfigurim, ju mund të personalizoni skriptet tuaja të vendosjes për mjedise, rajone dhe përdorues të veçantë, veçanërisht nëse jeni duke përdorur zgjidhje infrastrukturore si kod si CloudFormation. Për shembull, mund të vendosni një kopje të infrastrukturës për secilën degë në depo, në mënyrë që t'i provoni ato plotësisht të izoluara gjatë zhvillimit. Kjo përshpejton në mënyrë drastike reagimet për zhvilluesit kur duan të kuptojnë nëse kodi i tyre funksionon siç duhet në një mjedis të drejtpërdrejtë. Menaxherët nuk kanë nevojë të shqetësohen për koston e vendosjes së mjediseve të shumta, pasi ata paguajnë vetëm për përdorimin aktual.
DevOps kanë më pak shqetësime pasi atyre u duhet vetëm të sigurohen që zhvilluesit të kenë konfigurimin e duhur. Nuk keni më nevojë të menaxhoni shembuj, balancues ose grupe sigurie. Prandaj, termi NoOps përdoret gjithnjë e më shumë, megjithëse është ende e rëndësishme të jesh në gjendje të konfigurosh infrastrukturën, veçanërisht kur bëhet fjalë për konfigurimin e IAM dhe optimizimin e burimeve cloud.
Ka mjete shumë të fuqishme monitorimi dhe vizualizimi si Epsagon, Thundra, Dashbird dhe IOPipe. Ato ju lejojnë të monitoroni gjendjen aktuale të aplikacioneve tuaja pa server, të siguroni regjistrime dhe gjurmime, të kapni metrikat e performancës dhe pengesat e arkitekturës, të kryeni analizën dhe parashikimin e kostos dhe më shumë. Ata jo vetëm që u japin inxhinierëve, zhvilluesve dhe arkitektëve të DevOps një pamje gjithëpërfshirëse të performancës së aplikacionit, por gjithashtu lejojnë menaxherët të monitorojnë situatën në kohë reale, me kostot e burimeve për sekondë dhe parashikimin e kostos. Është shumë më e vështirë ta organizosh këtë me një infrastrukturë të menaxhuar.
Dizajnimi i aplikacioneve pa server është shumë më i lehtë sepse nuk keni nevojë të vendosni serverë në internet, të menaxhoni makina virtuale ose kontejnerë, serverë patch, sisteme operative, porta interneti, etj. Duke hequr të gjitha këto përgjegjësi, një arkitekturë pa server mund të fokusohet në thelb - zgjidhja.nevojat e biznesit dhe të klientëve.
Ndërsa paketa e veglave mund të jetë më e mirë (bëhet më mirë çdo ditë), zhvilluesit mund të fokusohen në zbatimin e logjikës së biznesit dhe në shpërndarjen më të mirë të kompleksitetit të aplikacionit nëpër shërbime të ndryshme brenda arkitekturës. Menaxhimi i aplikacioneve pa server bazohet në ngjarje dhe abstragohet nga ofruesi i resë kompjuterike (p.sh. ngjarjet SQS, S3 ose transmetimet DynamoDB). Prandaj, zhvilluesit duhet vetëm të shkruajnë logjikën e biznesit për t'iu përgjigjur ngjarjeve të caktuara dhe nuk duhet të shqetësohen për mënyrën më të mirë për të zbatuar bazat e të dhënave dhe radhët e mesazheve, ose si të organizojnë punën optimale me të dhënat në depo të veçanta harduerike.
Kodi mund të ekzekutohet dhe korrigjohet në nivel lokal, si me çdo proces zhvillimi. Testimi i njësisë mbetet i njëjtë. Aftësia për të vendosur një infrastrukturë të tërë aplikacioni me një konfigurim të personalizuar të grumbullit i lejon zhvilluesit të marrin shpejt komente të rëndësishme pa menduar për koston e testimit ose ndikimin në mjediset e shtrenjta të menaxhuara.
Mjete dhe teknika për ndërtimin e aplikacioneve pa server
Nuk ka asnjë mënyrë specifike për të ndërtuar aplikacione pa server. Si dhe një grup shërbimesh për këtë detyrë. AWS është lider në mesin e zgjidhjeve të fuqishme pa server sot, por shikoni gjithashtu , и . Nëse jeni duke përdorur AWS, atëherë qasja e rekomanduar për mbledhjen e aplikacioneve është (SAM), veçanërisht kur përdorni C#, sepse Visual Studio ka mjete të shkëlqyera. SAM CLI mund të bëjë gjithçka që mund të bëjë Visual Studio, kështu që nuk do të humbisni asgjë nëse kaloni në një redaktues tjetër IDE ose teksti. Sigurisht, SAM funksionon edhe me gjuhë të tjera.
Nëse jeni duke shkruar në gjuhë të tjera, Korniza pa server është një mjet i shkëlqyer me burim të hapur që ju lejon të konfiguroni çdo gjë me skedarë shumë të fuqishëm të konfigurimit YAML. Korniza pa server gjithashtu mbështet shërbime të ndryshme cloud, kështu që ne ua rekomandojmë atë atyre që janë në kërkim të një zgjidhjeje me shumë re. Ka një komunitet të madh që ka krijuar një mori shtojcash për çdo nevojë.
Për testimin lokal, mjetet me burim të hapur Docker-Lambda, Local pa server, DynamoDB Local dhe LocalStack janë të përshtatshme. Teknologjitë pa server janë ende në fazat e hershme të zhvillimit, siç janë mjetet për to, kështu që kur vendosni për skenarë komplekse testimi, do t'ju duhet të punoni shumë. Megjithatë, vendosja e thjeshtë e pirgut në një mjedis dhe testimi atje është tepër i lirë. Dhe nuk keni nevojë të bëni një kopje të saktë lokale të mjediseve cloud.
Përdorni shtresat AWS Lambda për të zvogëluar madhësinë e paketave të vendosura dhe për të shpejtuar shkarkimet.
Përdorni gjuhët e duhura të programimit për detyra specifike. Gjuhë të ndryshme kanë avantazhet dhe disavantazhet e tyre. Ka shumë standarde, por JavaScript, Python dhe C# (.NET Core 2.1+) janë liderët për sa i përket performancës së AWS Lambda. AWS Lambda prezantoi kohët e fundit Runtime API, i cili ju lejon të specifikoni gjuhën dhe mjedisin e dëshiruar të kohës së ekzekutimit, kështu që eksperimentoni.
Mbani madhësitë e paketave të vogla për vendosje. 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 disa veçori prej tyre. Nëse jeni duke programuar në JavaScript, përdorni një mjet ndërtimi si Webpack për të optimizuar ndërtimin tuaj dhe përfshini vetëm atë që ju nevojitet vërtet. .NET Core 3.0 ka QuickJit dhe Përpilim me nivele që përmirëson performancën dhe ndihmon shumë në fillimet e ftohta.
Mbështetja e funksioneve pa server në ngjarje mund ta bëjë të vështirë koordinimin e logjikës së biznesit në fillim. Në këtë drejtim, radhët e mesazheve dhe makineritë e gjendjes mund të jenë tepër të dobishme. Funksionet Lambda mund të thërrasin njëri-tjetrin, por bëjeni këtë vetëm nëse nuk jeni duke pritur një përgjigje ("zjarr dhe harro") - nuk dëshironi të faturoheni për pritjen për të përfunduar një funksion tjetër. Radhët e mesazheve janë të dobishme për izolimin e pjesëve të logjikës së biznesit, menaxhimin e pengesave të aplikacioneve dhe përpunimin e transaksioneve (duke përdorur radhët FIFO). Funksionet AWS Lambda mund t'u caktohen radhëve SQS si radhë mesazhesh të bllokuara që mbajnë gjurmët e mesazheve të dështuara për analiza të mëvonshme. Funksionet AWS Step (makinat e gjendjes) janë shumë të dobishme për menaxhimin e proceseve komplekse që kërkojnë zinxhir funksionesh. Në vend që një funksion Lambda të thërrasë një funksion tjetër, funksionet Step mund të koordinojnë tranzicionet e gjendjes, të kalojnë të dhëna midis funksioneve dhe të menaxhojnë gjendjen globale të funksioneve. Kjo ju lejon të përcaktoni kushtet e riprovës, ose çfarë të bëni kur ndodh një gabim i veçantë - një mjet shumë i fuqishëm në kushte të caktuara.
Përfundim
Vitet e fundit, teknologjitë pa server janë zhvilluar me një ritëm të paparë. Ka disa keqkuptime që lidhen me këtë ndryshim paradigme. Duke abstraktuar infrastrukturën dhe menaxhimin e shkallëzimit, zgjidhjet pa server ofrojnë përfitime të rëndësishme, nga zhvillimi i thjeshtuar dhe proceset DevOps deri te reduktimet masive të kostove operacionale.
Ndërsa qasja pa server nuk është pa të meta, ka modele të fuqishme të projektimit që mund të përdoren për të ndërtuar aplikacione të fuqishme pa server ose për të integruar elementë pa server në arkitekturat ekzistuese.
Burimi: www.habr.com