Azken urteotan zerbitzaririk gabeko teknologiek ospea azkar irabazi duten arren, oraindik ere asko dira haiekin lotutako uste okerrak eta beldurrak. Saltzaileen menpekotasuna, tresneria, kostuen kudeaketa, hotz abiaraztea, jarraipena eta garapenaren bizi-zikloa dira zerbitzaririk gabeko teknologiei dagokienez. Artikulu honetan, aipatutako gaietako batzuk aztertuko ditugu, baita informazio iturri lagungarrietarako aholkuak eta estekak partekatuko ditugu, hasiberriei zerbitzaririk gabeko aplikazio indartsuak, malguak eta errentagarriak sortzen laguntzeko.
Zerbitzaririk gabeko teknologiei buruzko uste okerrak
Jende askok uste du zerbitzaririk eta zerbitzaririk gabeko prozesatzea (, FaaS) ia gauza bera dira. Horrek esan nahi du aldea ez dela handiegia eta merezi duela berritasun bat sartzea. AWS Lambda zerbitzaririk gabeko garaiko izarretako bat eta zerbitzaririk gabeko arkitekturaren elementu ezagunenetako bat izan bazen ere, arkitektura hau FaaS baino askoz gehiago da.
Zerbitzaririk gabeko teknologien atzean dagoen oinarrizko printzipioa da ez duzula zure azpiegitura kudeatu eta eskalatzeaz kezkatu behar, erabiltzen duzunagatik bakarrik ordaintzen duzula. Zerbitzu askok irizpide hauek betetzen dituzte: AWS DynamoDB, S3, SNS edo SQS, Graphcool, Auth0, Now, Netlify, Firebase eta beste asko. Oro har, zerbitzaririk gabekoak esan nahi du hodeiko informatikaren ahalmen osoa erabiltzea azpiegitura kudeatu eta eskalatzeko optimizatu beharrik gabe. Horrek esan nahi du, gainera, azpiegitura mailan segurtasuna jada ez dela zure kezka, eta hori onura handia da segurtasun estandarrak betetzeko zailtasuna eta konplexutasuna kontuan hartuta. Azkenik, ez duzu zuk emandako azpiegitura erosi beharrik.
Zerbitzaririk gabeko βgogo egoeraβtzat har daiteke: irtenbideak diseinatzerakoan mentalitate jakin bat. Saihestu edozein azpiegitura mantentzea eskatzen duten hurbilketak. Zerbitzaririk gabeko ikuspegiarekin, denbora ematen dugu proiektuari zuzenean eragiten dioten eta gure erabiltzaileei onurak ekartzen dizkieten zereginak konpontzen: negozio-logika iraunkorra sortzen dugu, erabiltzaile-interfazeak garatzen ditugu eta API moldagarriak eta fidagarriak garatzen ditugu.
Adibidez, testu libreko bilaketa-plataforma bat kudeatzea eta mantentzea saihestea posible bada, horixe egingo dugu. Aplikazioak eraikitzeko ikuspegi honek merkaturatzeko denbora asko bizkortu dezake, jada ez duzulako azpiegitura konplexuak kudeatzeaz pentsatu behar. Ezabatu azpiegituren kudeaketaren ardurak eta kostuak eta zentratu zure bezeroek behar dituzten aplikazioak eta zerbitzuak eraikitzera. Patrick Debois-ek planteamendu horri deitu zion , terminoa zerbitzaririk gabeko komunitatean hartzen da. Funtzioak zerbitzuetarako esteka gisa pentsatu behar dira modulu inplementagarri gisa (liburutegi osoa edo web aplikazioa zabaldu beharrean). Honek inplementazioa eta aplikazioaren aldaketak kudeatzeko sekulako granulartasuna eskaintzen du. Funtzioak horrela zabaldu ezin badituzu, baliteke funtzioek zeregin gehiegi egiten dituztela eta birfactorizatu behar direla.
Batzuk nahastu egiten dira saltzailearekiko menpekotasunagatik hodeiko aplikazioak garatzerakoan. Zerbitzaririk gabeko teknologiekin ere gauza bera gertatzen da, eta hori ez da uste oker bat. Gure esperientziaren arabera, AWS-en zerbitzaririk gabeko aplikazioak eraikitzea, AWS Lambdak beste AWS zerbitzu batzuk elkarrekin biltzeko duen gaitasunarekin konbinatuta, zerbitzaririk gabeko arkitekturaren indarraren parte da. Hau sinergiaren adibide ona da, konbinazioaren emaitza terminoen batura baino gehiago denean. Saltzaileen menpekotasuna saihesten saiatzeak arazo gehiago sor ditzake. Edukiontziekin lan egiten duzunean, errazagoa da zure abstrakzio-geruza kudeatzea hodeiko hornitzaileen artean. Baina zerbitzaririk gabeko irtenbideei dagokienez, ahaleginak ez du etekinik emango, batez ere kostu-eraginkortasuna hasieratik kontuan hartzen bada. Ziurtatu saltzaileek zerbitzuak nola eskaintzen dituzten jakitea. Zerbitzu espezializatu batzuk beste saltzaile batzuekin integratzeko puntuetan oinarritzen dira eta litekeena da plug-and-play konexioa eskaintzea. Errazagoa da atebideko API amaierako puntu batetik Lambda dei bat ematea, eskaera edukiontzi edo EC2 instantzia batera proxy egitea baino. Graphcool-ek Auth0-rekin konfigurazio erraza eskaintzen du, hirugarrenen autentifikazio-tresnak erabiltzea baino errazagoa dena.
Zerbitzaririk gabeko aplikaziorako hornitzaile egokia aukeratzea erabaki arkitektonikoa da. Aplikazio bat sortzen duzunean, ez duzu espero egunen batean zerbitzariak kudeatzen itzultzea. Hodeiko saltzaile bat aukeratzea ez da edukiontziak edo datu-base bat edo programazio-lengoaia bat erabiltzea aukeratzea baino.
Kontuan izan:
- Zer zerbitzu behar dituzu eta zergatik.
- Zer zerbitzu eskaintzen dituzten hodeiko hornitzaileek eta nola konbina ditzakezu aukeratutako FaaS soluzioarekin.
- Zein programazio-lengoaia onartzen diren (idazketa dinamiko edo estatikoarekin, konpilatu edo interpretatuarekin, zeintzuk diren erreferentziak, zein den abiarazte hotzean errendimendua, zer den kode irekiko ekosistema, etab.).
- Zeintzuk dira zure segurtasun-baldintzak (SLA, 2FA, OAuth, HTTPS, SSL, etab.).
- Nola kudeatu zure CI/CD eta softwarearen garapen-zikloak.
- Zein azpiegitura-kode gisa aprobetxatu ditzakezun irtenbideak.
Lehendik dagoen aplikazio bat hedatzen baduzu eta zerbitzaririk gabeko funtzionaltasuna gehitzen baduzu, horrek erabilgarri dauden gaitasunak zertxobait muga ditzake. Hala ere, zerbitzaririk gabeko teknologia ia guztiek API motaren bat eskaintzen dute (REST edo mezu-ilaren bidez), aplikazioaren nukleotik independente eta integrazio errazarekin luzapenak sortzeko aukera ematen duena. Bilatu API argiak, dokumentazio ona eta komunitate sendoa dituzten zerbitzuak, eta ezin duzu gaizki egin. Integratzeko erraztasuna sarritan funtsezko metrika izan daiteke, eta ziurrenik AWS 2015ean Lambda kaleratu zenetik arrakasta handia izan duen arrazoi nagusietako bat da.
Zerbitzaririk Gabeko Ona denean
Zerbitzaririk gabeko teknologiak ia nonahi aplika daitezke. Hala ere, haien abantailak ez dira aplikazio modu bakarrera mugatzen. Gaur egun hodeiko informatikan sartzeko oztopoa oso baxua da zerbitzaririk gabeko teknologiei esker. Garatzaileek ideia bat badute, baina ez dakite hodeiko azpiegiturak kudeatu eta kostuak optimizatzen, orduan ez dute ingeniari motaren bat bilatu behar hori egiteko. Startup batek plataforma bat eraiki nahi badu baina kostuak kontroletik kanpo geratu daitezkeen beldur bada, zerbitzaririk gabeko irtenbideetara erraz jo dezake.
Kostuen aurreztea eta eskalatzeko erraztasuna dela eta, zerbitzaririk gabeko soluzioak berdin aplikatzen dira barneko zein kanpoko sistemetarako, milioi askotako audientzia duen web aplikazio batera arte. Kontuak eurotan baino neurtzen dira, baina zentimotan. Hilabetez AWS EC2 (t1.micro) instantziarik errazena alokatzea 15 β¬ kostatuko da, nahiz eta horrekin ezer egin (nori ez zaio inoiz ahaztu itzaltzea?!). Alderatuz, denbora-tarte berean gastu-maila horretara iristeko, 512 MB-ko Lambda bat segundo batean exekutatu beharko zenuke 1 milioi aldiz inguru. Eta funtzio hau erabiltzen ez baduzu, ez duzu ezer ordainduko.
Zerbitzaririk gabekoa batez ere gertaeren araberakoa denez, nahiko erraza da sistema zaharretan zerbitzaririk gabeko azpiegitura bat gehitzea. Adibidez, AWS S3, Lambda eta Kinesis erabiliz, API baten bidez datuak jaso ditzakeen txikizkako sistema zahar baten analitika zerbitzu bat sor dezakezu.
Zerbitzaririk gabeko plataforma gehienek hainbat hizkuntza onartzen dituzte. Gehienetan Python, JavaScript, C#, Java eta Go dira. Normalean ez dago hizkuntza guztietan liburutegiak erabiltzeko murrizketarik, beraz, zure kode irekiko liburutegi gogokoenak erabil ditzakezu. Dena den, komeni da menpekotasunak ez abusatzea, zure funtzioak ondo funtziona ditzan eta zerbitzaririk gabeko aplikazioen eskalagarritasun handiaren onurak ezeztatzeko. Zenbat eta pakete gehiago edukiontzian kargatu, orduan eta luzeagoa izango da hotz abiarazteak.
Hasiera hotza da edukiontzia, exekuzio-denbora eta errore-kudeatzailea hasieratu behar dituzunean erabili aurretik. Hori dela eta, funtzioen exekuzioaren atzerapena 3 segundora artekoa izan daiteke, eta hau ez da pazientziarik gabeko erabiltzaileentzat aukerarik onena. Hala ere, abiarazte hotzak lehen deian gertatzen dira funtzionamendu inaktiboa minutu batzuk igaro ondoren. Askok gogaikarri txiki bat dela uste dute, funtzioari aldian-aldian ping eginez funtzionamendua inaktibo mantentzeko. Edo alderdi hori guztiz baztertzen dute.
AWS kaleratu arrenHala ere, SQL datu-baseak ez dira aproposak aplikazio honetarako, transakzioak egiteko konexioen araberakoak baitira, eta hori azkar bihur daiteke AWS Lambda-n trafiko handiarekin. Bai, garatzaileak etengabe hobetzen ari dira Serverless Aurora, eta horrekin esperimentatu beharko zenuke, baina gaur egun NoSQL irtenbideak bezalako. Hala ere, ez dago zalantzarik egoera hau oso laster aldatuko dela.
Tresnak ere murrizketa asko ezartzen ditu, batez ere tokiko proben arloan. Docker-Lambda, DynamoDB Local eta LocalStack bezalako irtenbideak badaude ere, lan gogorra eta konfigurazio kopuru handia behar dute. Hala ere, proiektu hauek guztiak aktiboki garatzen dira, beraz, denbora kontua da tresna-kutxa behar dugun mailara iristea.
Zerbitzaririk gabeko teknologien eragina garapen-zikloan
Zure azpiegitura konfigurazio bat besterik ez denez, kodea definitu eta inplementa dezakezu scriptak erabiliz, hala nola shell scriptak. Edo konfigurazio-kode gisa klaseko soluzioetara jo dezakezu . Zerbitzu honek eremu guztietarako konfigurazioa eskaintzen ez badu ere, Lambda funtzio gisa erabiltzeko baliabide zehatzak definitzeko aukera ematen du. Hau da, CloudFormation-ek huts egiten dizun tokian, hutsune hori itxiko duen zure baliabide propioa (Lambda funtzioa) idatz dezakezu. Horrela edozer egin dezakezu, baita zure AWS ingurunetik kanpoko mendekotasunak konfiguratu ere.
Guztia konfigurazioa besterik ez denez, ingurune, eskualde eta erabiltzaile zehatzetarako inplementazio-scriptak pertsonaliza ditzakezu, batez ere, CloudFormation bezalako azpiegitura gisa kode-soluzioak erabiltzen ari bazara. Adibidez, adar bakoitzeko azpiegituraren kopia bat zabal dezakezu biltegian, garapenean zehar guztiz isolatuta probatu ahal izateko. Horrek izugarri bizkortzen du garatzaileentzako iritzia beren kodea zuzeneko ingurune batean behar bezala funtzionatzen duen ala ez ulertu nahi dutenean. Kudeatzaileek ez dute kezkatu behar ingurune anitz zabaltzearen kostuaz, benetako erabileragatik soilik ordaintzen baitute.
DevOps-ek kezka gutxiago ditu, garatzaileek konfigurazio zuzena dutela ziurtatu behar baitute. Jada ez dituzu instantziak, orekatzaileak edo segurtasun taldeak kudeatu behar. Hori dela eta, gero eta gehiago erabiltzen da NoOps terminoa, nahiz eta oraindik garrantzitsua den azpiegitura konfiguratu ahal izatea, batez ere IAM konfigurazioari eta hodeiko baliabideen optimizazioari dagokionez.
Epsagon, Thundra, Dashbird eta IOPipe bezalako monitorizazio eta bistaratzeko tresna oso indartsuak daude. Zerbitzaririk gabeko aplikazioen uneko egoera kontrolatzeko aukera ematen dizute, erregistroa eta trazadura eskaintzeko, errendimendu-neurriak eta arkitektura-botoiak harrapatzeko, kostuen azterketa eta aurreikuspenak egiteko eta abar. DevOps ingeniariei, garatzaileei eta arkitektoei aplikazioen errendimenduaren ikuspegi osoa emateaz gain, kudeatzaileek egoera denbora errealean kontrolatzeko aukera ematen diete, segundoko baliabideen kostuekin eta kostuen aurreikuspenarekin. Askoz zailagoa da hori kudeatutako azpiegitura batekin antolatzea.
Zerbitzaririk gabeko aplikazioak diseinatzea askoz errazagoa da, ez duzulako web zerbitzariak zabaldu beharrik, makina edo edukiontzi birtualak kudeatu beharrik, adabaki zerbitzariak, sistema eragileak, Interneteko pasabideak, etab. Erantzukizun horiek guztiak kenduz, zerbitzaririk gabeko arkitekturak muinean zentratu daiteke. irtenbidea.enpresen eta bezeroen beharrak.
Tresna-kit hobea izan daitekeen arren (egunero hobetzen da), garatzaileek negozio-logika inplementatzen eta aplikazioaren konplexutasuna hobekien banatzen dute arkitekturako zerbitzu desberdinetan. Zerbitzaririk gabeko aplikazioen kudeaketa hodeiko hornitzaileak gertaeren arabera eta abstrakzioa egiten du (adibidez, SQS, S3 gertaerak edo DynamoDB korronteak). Hori dela eta, garatzaileek negozio-logika idatzi behar dute gertaera jakin batzuei erantzuteko, eta ez dute kezkatu behar datu-baseak eta mezu-ilarak nola inplementatu hobekien edo hardware-biltegiratze zehatzetan datuekin lan optimoa nola antolatu.
Kodea lokalean exekutatu eta arazketa daiteke, edozein garapen prozesutan bezala. Unitate-probak berdin jarraitzen du. Pila pertsonalizatuaren konfigurazio batekin aplikazio-azpiegitura osoa zabaltzeko gaitasunari esker, garatzaileek iritzi garrantzitsuak azkar jaso ditzakete proben kostuetan edo kudeatutako ingurune garestietan duen eraginaz pentsatu gabe.
Zerbitzaririk gabeko aplikazioak eraikitzeko tresnak eta teknikak
Ez dago zerbitzaririk gabeko aplikazioak eraikitzeko modu zehatzik. Baita zeregin horretarako zerbitzu multzo bat ere. AWS zerbitzaririk gabeko irtenbide indartsuen artean liderra da gaur egun, baina begiratu ere bai , ΠΈ . AWS erabiltzen ari bazara, aplikazioak biltzeko gomendatutako hurbilketa hau da (SAM), batez ere C# erabiltzean, Visual Studio-k tresna bikainak dituelako. SAM CLI-k Visual Studio-k egin dezakeen guztia egin dezake, beraz, ez duzu ezer galduko beste IDE edo testu editore batera aldatzen bazara. Jakina, SAM-ek beste hizkuntza batzuekin ere lan egiten du.
Beste hizkuntza batzuetan idazten ari bazara, Serverless Framework kode irekiko tresna bikaina da, YAML konfigurazio-fitxategi oso indartsuekin edozer konfiguratzeko aukera ematen duena. Serverless Framework-ek hodeiko hainbat zerbitzu ere onartzen ditu, beraz, hodei anitzeko irtenbide bat bilatzen ari direnei gomendatzen diegu. Komunitate handi bat du, edozein beharretarako plugin mordoa sortu duena.
Tokiko probak egiteko, Docker-Lambda, Serverless Local, DynamoDB Local eta LocalStack kode irekiko tresnak egokiak dira. Zerbitzaririk gabeko teknologiak garapenaren hasierako fasean daude oraindik, haien tresnak bezalaxe, beraz, proba-egoera konplexuetarako konfiguratzean, gogor lan egin beharko duzu. Hala ere, pila ingurune batean zabaltzea eta bertan probatzea oso merkea da. Eta ez duzu hodeiko inguruneen tokiko kopia zehatza egin beharrik.
Erabili AWS Lambda Layers inplementatutako paketeen tamaina murrizteko eta deskargak bizkortzeko.
Erabili programazio-lengoaia egokiak zeregin zehatzetarako. Hizkuntza ezberdinek bere abantailak eta desabantailak dituzte. Erreferentzia asko daude, baina JavaScript, Python eta C# (.NET Core 2.1+) liderrak dira AWS Lambda errendimenduari dagokionez. AWS Lambda-k duela gutxi aurkeztu du Runtime APIa, zeinak nahi duzun exekuzio-denborako hizkuntza eta ingurunea zehazteko aukera ematen dizu, beraz, esperimentatu.
Mantendu paketeen tamaina txikiak zabaltzeko. Zenbat eta txikiagoak izan, orduan eta azkarrago kargatzen dira. Saihestu liburutegi handiak erabiltzea, batez ere haietako funtzio pare bat erabiltzen badituzu. JavaScript-en programatzen ari bazara, erabili Webpack bezalako eraikuntza-tresna bat zure eraikuntza optimizatzeko eta benetan behar duzuna bakarrik sartzeko. .NET Core 3.0-k QuickJit eta Tired Compilation ditu eta horrek errendimendua hobetzen du eta asko laguntzen du hotz abiarazteetan.
Zerbitzaririk gabeko funtzioek gertaerengan konfiantza izateak negozio-logika koordinatzea zaila egin dezake hasieran. Zentzu honetan, mezu-ilarak eta egoera-makinak izugarri erabilgarriak izan daitezke. Lambda funtzioek elkarri dei diezaiokete, baina egin erantzunik espero ez baduzu ("su eta ahaztu") - ez duzu fakturatu nahi beste funtzio bat amaitu arte itxaroteagatik. Mezu-ilarak baliagarriak dira negozio-logikaren zatiak isolatzeko, aplikazioen botila-lepoak kudeatzeko eta transakzioak prozesatzeko (FIFO ilarak erabiliz). AWS Lambda-ren funtzioak SQS ilaretara eslei daitezke itsatsita dauden mezuen ilara gisa, huts egindako mezuen jarraipena gero aztertzeko. AWS Step Functions (egoera-makinak) oso erabilgarriak dira funtzioak kateatzea eskatzen duten prozesu konplexuak kudeatzeko. Lambda funtzio batek beste funtzio bat deitu beharrean, Step funtzioek egoera-trantsizioak koordinatu ditzakete, funtzioen arteko datuak pasa ditzakete eta funtzioen egoera globala kudeatu. Horri esker, berriro saiakera-baldintzak defini ditzakezu, edo errore jakin bat gertatzen denean zer egin - oso tresna indartsua baldintza jakin batzuetan.
Ondorioa
Azken urteotan, zerbitzaririk gabeko teknologiak aurrekaririk gabeko erritmoan garatzen ari dira. Paradigma aldaketa honekin lotutako zenbait uste oker daude. Azpiegiturak abstraituz eta kudeaketa eskalatuz, zerbitzaririk gabeko soluzioek onura handiak eskaintzen dituzte, garapen sinplifikatu eta DevOps prozesuetatik hasi eta kostu operatiboen murrizketa masiboetaraino.
Zerbitzaririk gabeko ikuspegia eragozpenik gabe badago ere, diseinu eredu sendoak daude, zerbitzaririk gabeko aplikazio sendoak eraikitzeko edo lehendik dauden arkitekturetan zerbitzaririk gabeko elementuak integratzeko erabil daitezkeenak.
Iturria: www.habr.com