Kvankam senservilaj teknologioj rapide akiris popularecon en la lastaj jaroj, ankoraŭ ekzistas multaj miskompreniĝoj kaj zorgoj asociitaj kun ili. Vendistodependeco, ilaro, kostadministrado, malvarma ekfunkciigo, monitorado kaj evolua vivociklo estas ĉiuj varme diskutitaj temoj kiam temas pri senservilaj teknologioj. En ĉi tiu artikolo, ni esploros kelkajn el la menciitaj temoj, kaj ankaŭ dividos konsiletojn kaj ligilojn al helpemaj rimedoj por helpi komencantojn konstrui potencajn, flekseblajn kaj kostefikajn senservilajn aplikaĵojn.
Miskompreniĝoj pri senservilaj teknologioj
Multaj homoj kredas, ke senservila kaj senservila datumtraktado (, FaaS) estas preskaŭ la sama afero. Ĉi tio signifas, ke la diferenco ne estas tro granda kaj valoras enkonduki novan produkton. Kvankam AWS Lambda estis unu el la steloj de la pliiĝo de senservila teknologio kaj unu el la plej popularaj elementoj de senservila arkitekturo, estas pli al ĉi tiu arkitekturo ol FaaS.
La kerna principo de senservilo estas, ke vi ne devas zorgi pri administrado aŭ skalado de via infrastrukturo; vi nur pagas por tio, kion vi uzas. Multaj servoj taŭgas ĉi tiujn kriteriojn - AWS DynamoDB, S3, SNS aŭ SQS, Graphcool, Auth0, Now, Netlify, Firebase kaj multaj aliaj. Ĝenerale, senservilo signifas uzi ĉiujn kapablojn de nuba komputado sen la bezono administri kaj optimumigi la infrastrukturon por grimpi. Ĝi ankaŭ signifas, ke sekureco ĉe la infrastruktura nivelo ne plu estas via problemo, kio estas grandega profito pro la malfacileco kaj komplekseco plenumi sekurecajn normojn. Fine, vi ne devas aĉeti la infrastrukturon provizitan al vi.
Senservilo povas esti konsiderata "animstato": certa pensmaniero dum desegnado de solvoj. Evitu alirojn, kiuj postulas prizorgadon de ajna infrastrukturo. Kun senservila aliro, ni pasigas tempon solvante problemojn, kiuj rekte influas la projekton kaj alportas valoron al niaj uzantoj: kreante fortikan komercan logikon, disvolvante uzantinterfacojn kaj disvolvante respondemajn kaj fidindajn API-ojn.
Ekzemple, se eblas eviti administri kaj konservi senpagan tekstan serĉplatformon, tiam tion ni faros. Ĉi tiu aliro al konstruado de aplikoj povas draste akceli la tempon por merkati ĉar vi ne plu devas pensi pri administrado de kompleksa infrastrukturo. Liberigu vin de la respondecoj kaj kostoj de infrastruktura administrado kaj koncentriĝu pri konstruado de la aplikoj kaj servoj kiujn viaj klientoj bezonas. Patrick Debois nomis ĉi tiun aliron , ĉi tiu termino estas akceptita en la senservila komunumo. Funkcioj devus esti konsiderataj kiel la gluo kiu kunligas servojn kiel deplojeblajn modulojn (prefere ol deploji tutan bibliotekon aŭ TTT-aplikaĵon). Ĉi tio disponigas nekredeblan granularecon por administri deplojojn kaj ŝanĝojn al la aplikaĵo. Se vi ne povas deploji funkciojn tiamaniere, ĝi povas indiki ke la funkcioj faras tro multajn aferojn kaj devas esti refactorigitaj.
Kelkaj homoj estas konfuzitaj de vendistodependeco dum disvolvado de nubaj aplikaĵoj. La sama estas vera kun senservilaj teknologioj, kaj ĉi tio verŝajne ne estos la rezulto de miskompreniĝo. Laŭ nia sperto, konstrui senservilajn aplikojn sur AWS, kune kun la kapablo de AWS Lambda kunigi aliajn AWS-servojn, estas parto de tio, kio faras senservilajn arkitekturojn tiel bonegaj. Ĉi tio estas bona ekzemplo de sinergio, kiam la rezulto de kombinaĵo estas pli granda ol nur la sumo de ĝiaj partoj. Provi eviti vendistan enŝlosadon povas konduki al eĉ pli da problemoj. Kiam vi laboras kun ujoj, estas pli facile administri vian propran abstraktan tavolon inter nubaj provizantoj. Sed se temas pri senservilaj solvoj, la peno ne pagos, precipe se vi konsideras kostefikecon de la komenco. Nepre eksciu kiel vendistoj provizas servojn. Iuj specialigitaj servoj dependas de integriĝaj punktoj kun aliaj vendistoj kaj povas disponigi plug-and-play konekteblecon el la skatolo. Estas pli facile provizi Lambda-vokon de enireja API-finpunkto ol prokurigi la peton al iu ujo aŭ EC2-instanco. Graphcool ebligas facilan agordon uzante Auth0, kio estas pli facila ol uzado de triaj aŭtentigaj iloj.
Elekti la ĝustan vendiston por via senservila aplikaĵo estas arkitektura-nivela decido. Kiam vi kreas aplikaĵon, vi ne atendas iam reveni al administrado de serviloj. Elekti nuban vendiston ne diferencas ol elekti uzi ujojn aŭ datumbazon, aŭ eĉ programlingvon.
Konsideru:
- Kiajn servojn vi bezonas kaj kial.
- Kiajn servojn provizas nubaj provizantoj kaj kiel vi povas kombini ilin uzante vian elektitan FaaS-solvon.
- Kiaj programlingvoj estas subtenataj (dinamike aŭ statike tajpitaj, kompilitaj aŭ interpretitaj, kiaj estas la komparnormoj, kio estas la agado de malvarma starto, kio estas la malfermfonta ekosistemo, ktp.).
- Kio estas viaj sekurecaj postuloj (SLA, 2FA, OAuth, HTTPS, SSL, ktp.).
- Kiel administri viajn CI/KD kaj programajn evoluciklojn.
- Kiujn infrastruktur-kiel-kodajn solvojn vi povas utiligi?
Se vi pligrandigas ekzistantan aplikaĵon kaj aldonas senservilajn funkciojn iom post iom, ĉi tio povas iom limigi la disponeblajn kapablojn. Tamen, preskaŭ ĉiuj senservilaj teknologioj disponigas iun specon de API (per REST aŭ mesaĝvicado) kiu ebligas al vi krei etendaĵojn sendependajn de la aplikaĵkerno kaj kun facila integriĝo. Serĉu servojn kun klaraj APIoj, bona dokumentaro kaj forta komunumo, kaj vi ne povas erari. Facileco de integriĝo ofte povas esti ŝlosila metriko, kaj estas verŝajne unu el la ĉefaj kialoj, kial AWS sukcesis de kiam Lambda aperis en 2015.
Kiam senservilo utilas?
Senservilaj teknologioj povas esti uzataj preskaŭ ie ajn. Tamen, iliaj avantaĝoj ne estas limigitaj al nur la metodoj de apliko. La baro al eniro por nuba komputado estas tiom malalta hodiaŭ ĝuste pro senservilaj teknologioj. Se programistoj havas ideon, sed ili ne scias kiel administri nuban infrastrukturon kaj optimumigi kostojn, tiam ili ne bezonas serĉi iun inĝenieron por fari ĝin. Se noventrepreno volas konstrui platformon sed zorgas pri tio, ke kostoj eble malaperiĝos, ili povas facile turni sin al senservilaj solvoj.
Danke al kostŝparo kaj facileco de skalo, senservilaj solvoj estas egale aplikeblaj al kaj internaj kaj eksteraj sistemoj, ĝuste ĝis retejo-apliko kun multmilion-dolara publiko. Kontoj estas mezuritaj en cendoj prefere ol eŭroj. Luado de la plej simpla AWS EC2-instanco (t1.micro) por monato kostos €15, eĉ se vi faras nenion per ĝi (kiu iam forgesis malŝalti ĝin?!). Kompare, por atingi ĉi tiun nivelon de elspezo dum la sama tempodaŭro, vi bezonus ruli 512 MB Lambda dum 1 sekundo proksimume 3 milionojn da fojoj. Kaj se vi ne uzas ĉi tiun funkcion, vi pagas nenion.
Ĉar senservila estas ĉefe okazigita, estas sufiĉe facile aldoni senservila infrastrukturo al heredaj sistemoj. Ekzemple, uzante AWS S3, Lambda kaj Kinesis, vi povas krei analizan servon por hereda podetala sistemo, kiu povas ricevi datumojn per API.
Plej multaj senservilaj platformoj subtenas plurajn lingvojn. Plej ofte ĉi tiuj estas Python, JavaScript, C#, Java kaj Go. Kutime, ĉiuj lingvoj ne havas limigojn pri la uzo de bibliotekoj, do vi povas uzi viajn plej ŝatatajn malfermfontajn bibliotekojn. Tamen, estas konsilinde ne tro uzi dependecojn, por ke viaj funkcioj plenumu optimume kaj ne nuligu la avantaĝojn de la grandega skaleblo de viaj senservilaj aplikaĵoj. Ju pli da pakaĵoj devas esti ŝarĝitaj en la ujon, des pli longe daŭros la malvarma ekfunkciigo.
Malvarma komenco estas kiam vi unue bezonas pravalorigi la ujon, rultempon kaj erartraktilon antaŭ ol uzi ilin. Pro tio, la malfruo en plenumado de funkcioj povas esti ĝis 3 sekundoj, kaj ĉi tio ne estas la plej bona elekto por senpaciencaj uzantoj. Tamen, malvarmaj ekfunkcioj okazas ĉe la unua voko post kelkaj minutoj da neaktiva funkcio. Do multaj konsideras ĉi tion negrava ĝeno, kiun oni povas solvi per regule pingado de la funkcio por teni ĝin senmova. Aŭ ili tute ignoras ĉi tiun aspekton.
Kvankam AWS liberigitaTamen, SQL-datumbazoj ne estas idealaj por ĉi tiu tipo de uzo ĉar ili dependas de konektoj por fari transakciojn, kiuj povas rapide fariĝi botelo kiam estas multe da trafiko sur AWS Lambda. Jes, programistoj konstante plibonigas Serverless Aurora, kaj vi devus eksperimenti kun ĝi, sed hodiaŭ NoSQL-solvoj kiel. Tamen, ne estas dubo, ke ĉi tiu situacio ŝanĝiĝos tre baldaŭ.
La ilaro ankaŭ trudas multajn limojn, precipe en la areo de loka testado. Kvankam ekzistas solvoj kiel Docker-Lambda, DynamoDB Local kaj LocalStack, ili postulas zorgan laboron kaj gravan kvanton da agordo. Tamen ĉiuj ĉi tiuj projektoj aktive disvolviĝas, do estas nur demando de tempo antaŭ ol la iloj atingas la nivelon, kiun ni bezonas.
La efiko de senservilaj teknologioj sur la evoluciklo
Ĉar via infrastrukturo estas simple agorda, vi povas difini kaj disfaldi kodon uzante skriptojn, kiel ŝelajn skriptojn. Aŭ vi povas recurri al agordaj kiel-kodaj klassolvoj kiel . Kvankam ĉi tiu servo ne provizas agordon por ĉiuj areoj, ĝi permesas vin difini specifajn rimedojn por uzi kiel Lambda funkcioj. Tio estas, kie CloudFormation malsukcesas vin, vi povas skribi vian propran rimedon (Lambda funkcio), kiu fermos ĉi tiun breĉon. Tiel vi povas fari ion ajn, eĉ agordi dependecojn ekster via AWS-medio.
Ĉar ĉio estas nur agordo, vi povas parametrigi viajn deplojajn skriptojn por specifaj medioj, regionoj kaj uzantoj, precipe se vi uzas infrastrukturajn kiel-kodajn solvojn kiel CloudFormation. Ekzemple, vi povas disfaldi kopion de la infrastrukturo por ĉiu branĉo en la deponejo, por ke vi povu testi ilin tute izole dum disvolviĝo. Ĉi tio radikale plirapidigas la tempon, kiam programistoj ricevas reagojn kiam ili volas kompreni ĉu ilia kodo funkcias adekvate en viva medio. Administrantoj ne devas zorgi pri la kosto de deplojado de multoblaj medioj ĉar ili nur pagas por reala uzo.
DevOps havas malpli zorgi pri tio, ĉar ili nur bezonas certigi, ke programistoj havas la ĝustan agordon. Ne plu administri okazojn, ekvilibrilojn aŭ sekurecajn grupojn. Tial, la termino NoOps estas ĉiam pli uzata, kvankam ankoraŭ gravas povi agordi la infrastrukturon, precipe kiam temas pri IAM-agordo kaj optimumigo de nubaj rimedoj.
Estas tre potencaj monitoraj kaj videblecaj iloj kiel Epsagon, Thundra, Dashbird kaj IOPipe. Ili permesas vin kontroli la nunan staton de senservilaj aplikoj, provizi protokolojn kaj spurojn, kapti rendimento-metrikojn kaj arkitekturajn proplempunktojn, plenumi kostan analizon kaj prognozon, kaj multe pli. Ne nur ili donas al DevOps-inĝenierojn, programistojn kaj arkitektojn ampleksan vidon pri aplikaĵo-rendimento, sed ili ankaŭ ebligas al administrantoj akiri videblecon en realtempan, dua-post-sekundan elspezadon de rimedoj kaj kostoprognozon. Estas multe pli malfacile organizi ĉi tion kun administrita infrastrukturo.
Projekti senservilajn aplikaĵojn estas multe pli facila ĉar vi ne devas disfaldi retservilojn, administri virtualajn maŝinojn aŭ ujojn, flikservilojn, operaciumojn, interretajn enirejojn ktp. Abstrakti ĉiujn ĉi tiujn respondecojn permesas al senservila arkitekturo koncentriĝi pri tio, kio plej gravas: la solvo. komercaj kaj klientaj bezonoj.
Dum la ilaro povus esti pli bona (ĝi pliboniĝas ĉiutage), programistoj povas koncentriĝi pri efektivigado de komerca logiko kaj kiel plej bone distribui la kompleksecon de la aplikaĵo tra malsamaj servoj ene de la arkitekturo. Senservila aplika administrado estas okazaĵbazita kaj abstraktita de la nuba provizanto (ekzemple, SQS, S3-okazaĵoj aŭ DynamoDB-riveretoj). Tial, programistoj nur bezonas skribi komercan logikon por reagi al certaj eventoj, kaj ne devas zorgi pri kiel plej bone efektivigi datumbazojn kaj mesaĝajn atendovicojn, aŭ kiel optimume labori kun datumoj en specifaj aparataj stokaĵoj.
Kodo povas esti ekzekutita kaj sencimigita loke, kiel kun ajna evoluprocezo. Unutestado restas la sama. La kapablo deploji tutan aplikan infrastrukturon uzante kutiman stakan agordon permesas al programistoj rapide ricevi gravajn sugestojn sen zorgi pri la kosto de testado aŭ la efiko al multekostaj administritaj medioj.
Iloj kaj teknikoj por konstruado de senservilaj aplikoj
Ne ekzistas specifa maniero konstrui senservilajn aplikaĵojn. Same kiel aro da servoj por ĉi tiu tasko. La gvidanto inter potencaj senservilaj solvoj hodiaŭ estas AWS, sed atentu , и . Se vi uzas AWS, tiam ni povas rekomendi kiel aliron por kolekti aplikojn (SAM), precipe kiam vi uzas C#, ĉar Visual Studio havas bonegajn ilojn. La SAM CLI povas fari ĉion, kion Visual Studio povas fari, do vi nenion perdos se vi ŝanĝas al malsama IDE aŭ tekstredaktilo. Kompreneble, SAM funkcias ankaŭ kun aliaj lingvoj.
Se vi skribas en aliaj lingvoj, la Senservila Kadro estas bonega malfermfonta ilo, kiu ebligas al vi agordi ion ajn uzante tre potencajn YAML-agordajn dosierojn. Senservila Kadro ankaŭ subtenas diversajn nubajn servojn, do ni rekomendas ĝin al tiuj, kiuj serĉas plurnuban solvon. Ĝi havas grandegan komunumon, kiu kreis amason da kromaĵojn por ajna bezono.
Por loka testado, malfermfontaj iloj Docker-Lambda, Serverless Local, DynamoDB Local kaj LocalStack taŭgas. Senservilaj teknologioj estas ankoraŭ en frua etapo de evoluo, same kiel la iloj por ili, do vi devos multe labori kiam vi starigas kompleksajn testajn scenarojn. Tamen, simple deploji la stakon en la medio kaj testi ĝin tie montriĝas nekredeble malmultekosta. Kaj vi ne bezonas fari precizan lokan kopion de viaj nubaj medioj.
Uzu AWS Lambda Layers por redukti deplojitajn pakaĵojn kaj akceli ŝarĝtempojn.
Uzu la ĝustajn programlingvojn por specifaj taskoj. Malsamaj lingvoj havas siajn proprajn avantaĝojn kaj malavantaĝojn. Estas multaj komparnormoj, sed JavaScript, Python kaj C# (.NET Core 2.1+) estas la gvidantoj laŭ AWS Lambda agado. AWS Lambda lastatempe enkondukis Runtime API, kiu permesas vin specifi vian deziratan lingvon kaj rultempan medion, do eksperimentu.
Tenu malgrandajn grandecojn de disfaldaj pakaĵoj. Ju pli malgrandaj ili estas, des pli rapide ili ŝarĝas. Evitu uzi grandajn bibliotekojn, precipe se vi uzas kelkajn funkciojn el ili. Se vi programas en JavaScript, uzu konstruajn ilojn kiel Webpack por optimumigi vian konstruon kaj nur inkluzivi tion, kion vi vere bezonas. .NET Core 3.0 inkluzivas QuickJit kaj Tired Compilation, kiuj plibonigas rendimenton kaj multe helpas kun malvarmaj ekfunkciigo.
La dependeco de senservilaj funkcioj de eventoj povas malfaciligi kunordigi komercan logikon komence. Mesaĝvostoj kaj ŝtataj maŝinoj povas esti nekredeble utilaj ĉi-rilate. Lambda funkcioj povas voki unu la alian, sed nur faru tion se vi ne atendas respondon ("fajru kaj forgesu") - vi ne volas esti fakturita pro atendo de alia funkcio finiĝos. Mesaĝaj atendovicoj estas utilaj por izoli pecojn de komerca logiko, administri aplikajn proplempunktojn kaj prilabori transakciojn (uzante FIFO-vicojn). AWS Lambda-funkcioj povas esti asignitaj al SQS-vostoj kiel blokitaj mesaĝvostoj, kiuj spuras malsukcesajn mesaĝojn por posta analizo. AWS Step Functions (ŝtataj maŝinoj) estas tre utilaj por administri kompleksajn procezojn, kiuj postulas ĉenadon de funkcioj. Anstataŭ ke Lambda funkcio vokas alian funkcion, Step-funkcioj povas kunordigi ŝtattransirojn, transdoni datumojn inter funkcioj kaj administri la tutmondan staton de funkcioj. Ĉi tio permesas vin difini reprovi kondiĉojn, aŭ kion fari kiam specifa eraro okazas - tre potenca ilo sub certaj kondiĉoj.
konkludo
En la lastaj jaroj, senservilaj teknologioj disvolviĝis kun senprecedenca rapideco. Estas certaj miskompreniĝoj asociitaj kun ĉi tiu paradigmoŝanĝo. Abstraktante infrastrukturon kaj administrante skaleblon, senservilaj solvoj ofertas signifajn avantaĝojn, de simpligita evoluo kaj DevOps-procezoj ĝis grandaj reduktoj en operaciaj kostoj.
Kvankam la senservila aliro ne estas sen siaj malavantaĝoj, ekzistas fidindaj dezajnaj ŝablonoj, kiuj povas esti uzataj por krei fortikan senservilajn aplikojn aŭ integri senservilajn elementojn en ekzistantajn arkitekturojn.
fonto: www.habr.com