Af hverju netþjónalausa byltingin er í dauðafæri

Lykil atriði

  • Í nokkur ár hefur okkur verið lofað að netþjónalaus tölvumál (miðlaralaus) muni opna nýtt tímabil án sérstaks stýrikerfis til að keyra forrit. Okkur var sagt að slík uppbygging myndi leysa mörg vandamál með sveigjanleika. Í raun er allt öðruvísi.
  • Þó að margir líti á netþjónalausa tækni sem nýja hugmynd, má rekja rætur hennar aftur til ársins 2006 með Zimki PaaS og Google App Engine, sem bæði nota netþjónalausan arkitektúr.
  • Það eru fjórar ástæður fyrir því að netþjónalausa byltingin hefur stöðvast, allt frá takmörkuðum stuðningi við forritunarmál til frammistöðuvandamála.
  • Miðlaralaus tölva er ekki svo gagnslaus. Langt frá því. Hins vegar ætti ekki að líta á þá sem beinan stað í stað netþjóna. Fyrir sum forrit geta þau verið handhægt tæki.

Serverinn er dauður, lengi lifi serverinn!

Þetta er baráttuóp fylgismanna netþjónalausu byltingarinnar. Fljótlegt yfirlit yfir iðnaðarpressuna undanfarin ár er nóg til að álykta að hefðbundna netþjónalíkanið sé dautt og að eftir nokkur ár munum við öll nota netþjónalausan arkitektúr.

Eins og allir í greininni vita, og eins og við bentum líka á í grein okkar um ástand miðlaralausrar tölvunar, þetta er rangt. Þrátt fyrir margar efnisgreinar netþjónalaus bylting, það átti sér aldrei stað. Reyndar, nýlegar rannsóknir sýnaað þessi bylting gæti verið komin í öngstræti.

Sum loforð um netþjónalausar gerðir hafa vissulega ræst, en ekki öll. Ekki allir.

Í þessari grein vil ég íhuga ástæður þessa ástands. Hvers vegna skortur á sveigjanleika netþjónalausra gerða er enn hindrun fyrir víðtækari upptöku þeirra, þó að þau séu áfram gagnleg við sérstakar, vel skilgreindar aðstæður.

Því sem unnendur netþjónalausrar tölvunar lofuðu

Áður en haldið er áfram að vandamálum við netþjónalausa tölvuvinnslu skulum við sjá hvað þeir þurftu að veita. Loforð um netþjónalausa byltingu voru fjölmargir og - stundum - mjög metnaðarfullir.

Fyrir þá sem ekki þekkja hugtakið er hér stutt skilgreining. Serverless computing skilgreinir arkitektúr þar sem forrit (eða hlutar af forritum) keyra á eftirspurn í keyrsluumhverfi sem venjulega er fjarhýst. Að auki er hægt að hýsa netþjónalaus kerfi. Að byggja upp öflug netþjónalaus kerfi hefur verið mikið áhyggjuefni kerfisstjóra og SaaS-fyrirtækja á undanförnum árum, þar sem (það er fullyrt) að þessi arkitektúr býður upp á nokkra lykilkosti fram yfir „hefðbundna“ biðlara/miðlara líkanið:

  1. Miðlaralausar gerðir krefjast ekki þess að notendur viðhaldi eigin stýrikerfum eða jafnvel smíða forrit sem eru samhæf við ákveðin stýrikerfi. Þess í stað búa verktaki til sameiginlegan kóða, hlaða honum upp á netþjónslausan vettvang og horfa á hann keyra.
  2. Tilföng í netþjónalausum ramma eru venjulega gjaldfærð á mínútu (eða jafnvel sekúndum). Þetta þýðir að viðskiptavinir greiða aðeins fyrir þann tíma sem þeir framkvæma kóðann í raun. Þetta er í góðu samanburði við hefðbundna ský VM, þar sem vélin er aðgerðalaus að mestu leyti, en þú þarft að borga fyrir það.
  3. Vandamálið um sveigjanleika var einnig leyst. Tilföngum í netþjónalausum ramma er úthlutað á virkan hátt þannig að kerfið geti auðveldlega tekist á við skyndilega aukningu í eftirspurn.

Í stuttu máli, miðlaralausar gerðir bjóða upp á sveigjanlegar, ódýrar, skalanlegar lausnir. Ég er hissa á að við höfum ekki hugsað um þessa hugmynd fyrr.

Er þetta virkilega ný hugmynd?

Reyndar er hugmyndin ekki ný. Hugmyndin um að leyfa notendum að borga aðeins fyrir þann tíma sem kóðinn keyrir í raun hefur verið til síðan hann var kynntur undir Zimki PaaS árið 2006 og um svipað leyti kom Google App Engine með mjög svipaða lausn.

Reyndar er það sem við köllum „miðlaralausa“ líkanið núna eldra en mörg tækni sem nú er kölluð „skýjamætt“ sem veitir nánast það sama. Eins og fram hefur komið eru netþjónalaus líkön í rauninni bara framlenging á SaaS viðskiptamódelinum sem hefur verið til í áratugi.

Það er líka þess virði að viðurkenna að netþjónalausa líkanið er ekki FaaS arkitektúr, þó að það sé tenging þar á milli. FaaS er í rauninni tölvumiðaður hluti netþjónslauss arkitektúrs, en það táknar ekki allt kerfið.

Svo hvers vegna allt þetta hype? Jæja, þar sem hlutfall internets í þróunarlöndunum heldur áfram að aukast, eykst eftirspurnin eftir tölvuauðlindum. Til dæmis hafa mörg lönd með ört vaxandi rafræn viðskipti einfaldlega ekki tölvuinnviði fyrir forrit á þessum kerfum. Þetta er þar sem greiddir netþjónarlausir pallar koma inn.

Vandamál með netþjónalausum gerðum

Gallinn er sá að netþjónalausar gerðir eiga í... vandamálum. Ekki misskilja mig: Ég er ekki að segja að þau séu slæm í sjálfu sér eða veiti sumum fyrirtækjum ekki veruleg verðmæti í sumum kringumstæðum. En aðalkrafan „byltingarinnar“ - að netþjónalausi arkitektúrinn komi fljótt í stað hinn hefðbundna - gengur aldrei upp.

Þess vegna.

Takmarkaður stuðningur við forritunarmál

Flestir netþjónalausir pallar leyfa aðeins að keyra forrit sem eru skrifuð á ákveðnum tungumálum. Þetta takmarkar mjög sveigjanleika og aðlögunarhæfni þessara kerfa.

Miðlaralausir pallar eru taldir styðja flest helstu tungumál. AWS Lambda og Azure Functions bjóða einnig upp á umbúðir til að keyra forrit og aðgerðir á óstuddum tungumálum, þó að þetta kosti oft frammistöðukostnað. Þannig að fyrir flestar stofnanir er þessi takmörkun venjulega ekki mikil. En hér er málið. Einn af kostunum við netþjónalausar gerðir á að vera sá að óljós, sjaldan notuð forrit er hægt að nota ódýrari vegna þess að þú borgar aðeins fyrir þann tíma sem þau keyra. Og óljós, sjaldan notuð forrit eru oft skrifuð á... óskýr, sjaldan notuð forritunarmál.

Þetta grefur undan einum af helstu kostum netþjónalausa líkansins.

Bindur við söluaðila

Annað vandamálið við netþjónalausa vettvang, eða að minnsta kosti hvernig þeir eru útfærðir eins og er, er að þeir líta venjulega ekki eins út á rekstrarstigi. Það er nánast engin stöðlun hvað varðar ritunaraðgerðir, uppsetningu og stjórnun. Þetta þýðir að það er mjög tímafrekt að flytja eiginleika frá einum vettvang til annars.

Erfiðast við að fara yfir í netþjónslaust líkan eru ekki reiknieiginleikarnir, sem eru venjulega bara bútar af kóða, heldur hvernig forrit eiga í samskiptum við tengd kerfi eins og hlutgeymslu, auðkennisstjórnun og biðraðir. Hægt er að færa aðgerðir, en restin af forritinu ekki. Þetta er nákvæmlega andstæðan við fyrirheitna ódýra og sveigjanlega pallana.

Sumir halda því fram að netþjónalausar gerðir séu nýjar og það hafi ekki gefist tími til að staðla hvernig þær virka. En þær eru ekki svo nýjar, eins og ég tók fram hér að ofan, og mörg önnur skýjatækni eins og gámar er þegar orðin miklu þægilegri vegna þróunar og víðtækrar upptöku góðra staðla.

Framleiðni

Erfitt er að mæla tölvuafköst netþjónalausra kerfa, meðal annars vegna þess að söluaðilar hafa tilhneigingu til að halda upplýsingum leyndum. Flestir halda því fram að eiginleikar á fjarlægum, netþjónalausum kerfum gangi alveg jafn hratt og þeir gera á innri netþjónum, fyrir utan nokkur óumflýjanleg leynd vandamál.

Hins vegar benda sumar vísbendingar til annars. Aðgerðir sem hafa ekki áður keyrt á tilteknum vettvangi, eða hafa ekki keyrt í nokkurn tíma, tekur nokkurn tíma að frumstilla. Þetta er líklega vegna þess að kóði þeirra hefur verið fluttur á einhvern óaðgengilegan geymslumiðil, þó - eins og með viðmið - flestir söluaðilar muni ekki segja þér um flutning á gögnum.

Auðvitað eru nokkrar leiðir til að komast í kringum þetta. Eitt er að fínstilla eiginleika fyrir hvaða skýjamál sem netþjónalausi vettvangurinn þinn keyrir á, en það grefur nokkuð undan fullyrðingunni um að þessir pallar séu „liprir“.

Önnur aðferð er að tryggja að árangursmikil forrit keyri reglulega til að halda þeim „ferskum“. Þessi önnur nálgun er auðvitað svolítið á móti þeirri fullyrðingu að netþjónalausir pallar séu hagkvæmari vegna þess að þú borgar aðeins fyrir þann tíma sem forritin þín keyra. Skýjaveitur hafa kynnt nýjar leiðir til að draga úr kaldræsingum, en margar þeirra krefjast „skala í einn“ (skala í einn), sem grefur undan upprunalegu gildi FaaS.

Hægt er að bregðast við kaldræsingarvandamálinu að hluta til með því að keyra netþjónalaus kerfi innanhúss, en þetta kemur á sinn kostnað og er enn sessvalkostur fyrir vel útbúið teymi.

Þú getur ekki keyrt heil forrit

Að lokum, kannski mikilvægasta ástæðan fyrir því að netþjónalaus arkitektúr kemur ekki í stað hefðbundinna módela í bráð er sú að þeir geta (almennt) ekki keyrt heil forrit.

Nánar tiltekið er það óframkvæmanlegt frá kostnaðarsjónarmiði. Sennilega ætti ekki að breyta farsælli einstæðunni þinni í sett af fjórum tugum aðgerða sem eru bundnar saman af átta gáttum, fjörutíu biðröðum og tugi gagnagrunnstilvika. Af þessum sökum hentar netþjónalaust betur fyrir nýja þróun. Nánast ekkert núverandi forrit (arkitektúr) er hægt að flytja. Þú getur flutt, en þú verður að byrja frá grunni.

Þetta þýðir að í langflestum tilfellum eru netþjónarlausir pallar notaðir sem viðbót við bakendaþjóna til að framkvæma tölvufrek verkefni. Þetta er mjög frábrugðið hinum tveimur tegundum tölvuskýja, gáma og sýndarvéla, sem bjóða upp á heildræna leið til að framkvæma fjartölvu. Þetta sýnir eina af áskorunum við að flytja úr örþjónustu yfir í netþjónalaus kerfi.

Auðvitað er þetta ekki alltaf vandamál. Hæfni til að nota mikið tölvuauðlindir reglulega án þess að kaupa eigin vélbúnað getur fært mörgum stofnunum raunverulegan og varanlegan ávinning. En ef sum forrit eru á innri netþjónum og önnur eru á netþjónalausum skýjaarkitektúr, þá fer stjórnun inn á nýtt flókið stig.

Lengi lifi byltingin?

Þrátt fyrir allar þessar kvartanir er ég ekki á móti netþjónalausum lausnum í sjálfu sér. Heiðarlega. Það er bara það að verktaki þurfa að skilja - sérstaklega ef þeir eru að skoða netþjónalaus módel í fyrsta skipti - að þessi tækni kemur ekki beint í staðinn fyrir netþjóna. Skoðaðu í staðinn ábendingar okkar og úrræði um byggja upp netþjónalaus forrit og ákveða hvernig best sé að nota þetta líkan.

Heimild: www.habr.com

Bæta við athugasemd