Belangrike punte
- Vir 'n paar jaar is ons nou belowe dat bedienerlose rekenaars 'n nuwe era sal inlui sonder 'n spesifieke bedryfstelsel om toepassings te laat loop. Ons is meegedeel dat hierdie struktuur baie skaalbaarheidsprobleme sou oplos. Trouens, alles is anders.
- Terwyl baie bedienerloos as 'n nuwe idee beskou, kan die wortels daarvan teruggevoer word na 2006 met die koms van Zimki PaaS en Google App Engine, wat albei bedienerlose argitektuur gebruik.
- Daar is vier redes waarom die bedienerlose revolusie tot stilstand gekom het, wat wissel van beperkte programmeertaalondersteuning tot prestasiekwessies.
- Bedienerlose rekenaars is nie so nutteloos nie. Glad nie. Dit moet egter nie as 'n direkte plaasvervanger vir bedieners beskou word nie. Vir sommige toepassings kan hulle 'n handige hulpmiddel wees.
Die bediener is dood, lank lewe die bediener!
Dit is die strydkreet van die bedienerlose revolusie. Net 'n vinnige blik op die bedryfspers oor die afgelope paar jaar en dit is maklik om tot die gevolgtrekking te kom dat die tradisionele bedienermodel dood is en dat ons binne 'n paar jaar almal bedienerlose argitekture sal gebruik.
Soos enigiemand in die bedryf weet, en soos ons ook uitgewys het in ons artikel oor , Dis verkeerd. Ten spyte van baie artikels oor die meriete , dit het nooit plaasgevind nie. In werklikheid, dat hierdie rewolusie dalk 'n doodloopstraat bereik het.
Sommige van die beloftes van bedienerlose modelle is beslis verwesenlik, maar nie almal nie. Nie almal nie.
In hierdie artikel wil ek kyk na die redes vir hierdie toestand. Waarom die gebrek aan buigsaamheid van bedienerlose modelle steeds 'n hindernis is vir die wyer aanvaarding daarvan, al bly dit nuttig in spesifieke, goed gedefinieerde omstandighede.
Wat die kundiges van bedienerlose rekenaars belowe het
Voordat ons by die uitdagings van bedienerlose rekenaars ingaan, kom ons kyk na wat dit veronderstel was om te voorsien. was talle en - by tye - baie ambisieus.
Vir diegene wat nie vertroud is met die term nie, hier is 'n vinnige definisie. Bedienerlose rekenaars definieer 'n argitektuur waarin toepassings (of dele van toepassings) op aanvraag loop in looptydomgewings wat tipies op afstand gehuisves word. Boonop kan bedienerlose stelsels tuis gehuisves word. Die bou van veerkragtige bedienerlose stelsels was 'n groot bekommernis vir stelseladministrateurs en SaaS-maatskappye oor die afgelope paar jaar, aangesien (daar word beweer) hierdie argitektuur verskeie sleutelvoordele bied bo die "tradisionele" kliënt-bedienermodel:
- Bedienerlose modelle vereis nie van gebruikers om hul eie bedryfstelsels in stand te hou of selfs toepassings te skep wat versoenbaar is met spesifieke bedryfstelsels nie. In plaas daarvan skep ontwikkelaars gedeelde kode, laai dit op na 'n bedienerlose platform en kyk hoe dit loop.
- Hulpbronne in bedienerlose raamwerke word tipies per minuut (of selfs die sekonde) gefaktureer. Dit beteken dat kliënte slegs betaal vir die tyd wat hulle werklik die kode gebruik. Dit vergelyk gunstig met 'n tradisionele wolk-VM, waar die masjien die meeste van die tyd ledig is, maar jy moet daarvoor betaal.
- Die skaalbaarheidsprobleem is ook opgelos. Hulpbronne in bedienerlose raamwerke word dinamies toegewys sodat die stelsel maklik die skielike toename in aanvraag kan hanteer.
Kortom, bedienerlose modelle bied buigsame, laekoste, skaalbare oplossings. Dit is verbasend dat ons nie vroeër aan hierdie idee gedink het nie.
Is dit regtig 'n nuwe idee?
Trouens, die idee is nie nuut nie. Die konsep om gebruikers toe te laat om slegs te betaal vir die tyd wat die kode werklik loop, bestaan sedert dit ingestel is deur in 2006, en ongeveer dieselfde tyd het Google App Engine 'n baie soortgelyke oplossing aangebied.
Trouens, wat ons nou die "bedienerlose" model noem, is ouer as baie tegnologieë wat nou "wolk-inheems" genoem word, wat baie dieselfde ding bied. Soos opgemerk, is bedienerlose modelle in wese net 'n uitbreiding van die SaaS-sakemodel wat al dekades bestaan.
Dit is ook die moeite werd om te erken dat bedienerloos nie 'n FaaS-argitektuur is nie, hoewel daar 'n verband tussen die twee is. FaaS is in wese die rekenaarsentriese deel van 'n bedienerlose argitektuur, maar dit verteenwoordig nie die hele stelsel nie.
So waaroor gaan al die bohaai? Wel, aangesien internetpenetrasiekoerse steeds die hoogte inskiet in ontwikkelende lande, neem die vraag na rekenaarhulpbronne ook terselfdertyd toe. Byvoorbeeld, baie lande met vinnig groeiende e-handelsektore het eenvoudig nie die rekenaarinfrastruktuur vir toepassings op hierdie platforms nie. Dit is waar betaalde bedienerlose platforms inkom.
Probleme met bedienerlose modelle
Die vangplek is dat bedienerlose modelle ... probleme het. Moet my nie verkeerd verstaan nie: ek sê nie dat hulle per se sleg is of in sommige omstandighede nie noemenswaardige waarde aan sommige maatskappye verskaf nie. Maar die hoofaanspraak van die "revolusie" - dat bedienerlose argitektuur vinnig tradisionele argitektuur sal vervang - realiseer nooit nie.
Dis hoekom.
Beperkte ondersteuning vir programmeertale
Die meeste bedienerlose platforms laat jou net toe om toepassings te laat loop wat in sekere tale geskryf is. Dit beperk die buigsaamheid en aanpasbaarheid van hierdie stelsels ernstig.
Bedienerlose platforms word beskou as om die meeste groot tale te ondersteun. AWS Lambda- en Azure-funksies bied ook 'n omhulsel vir die uitvoer van toepassings en funksies in nie-ondersteunde tale, hoewel dit dikwels met 'n werkverrigtingskoste gepaard gaan. So vir die meeste organisasies is hierdie beperking gewoonlik nie 'n groot probleem nie. Maar hier is die ding. Een van die voordele van bedienerlose modelle is veronderstel om te wees dat min bekende, selde gebruikte programme goedkoper gebruik kan word omdat jy net betaal vir die tyd wat hulle loop. En min bekende, selde gebruikte programme word dikwels geskryf in ... min bekende, selde gebruikte programmeertale.
Dit ondermyn een van die belangrikste voordele van die bedienerlose model.
Verkoper bindend
Die tweede probleem met bedienerlose platforms, of ten minste die manier waarop hulle tans geïmplementeer word, is dat hulle gewoonlik nie op bedryfsvlak aan mekaar ooreenstem nie. Daar is feitlik geen standaardisering in terme van skryffunksies, ontplooiing en bestuur nie. Dit beteken dat die migreer van kenmerke van een platform na 'n ander uiters tydrowend is.
Die moeilikste deel van die oorskakeling na 'n bedienerlose model is nie die rekenaarfunksies nie, wat gewoonlik net stukkies kode is, maar hoe toepassings met gekoppelde stelsels kommunikeer soos objekberging, identiteitsbestuur en toue. Funksies kan geskuif word, maar die res van die toepassing kan nie. Dit is presies die teenoorgestelde van die goedkoop en buigsame platforms wat belowe word.
Sommige argumenteer dat bedienerlose modelle nuut is en dat daar nie tyd was om te standaardiseer hoe hulle werk nie. Maar hulle is nie so nuut nie, soos ek hierbo opgemerk het, en baie ander wolktegnologieë, soos houers, het reeds baie meer bruikbaar geword danksy die ontwikkeling en wydverspreide aanvaarding van goeie standaarde.
produktiwiteit
Die rekenaarprestasie van bedienerlose platforms is moeilik om te meet, deels omdat verskaffers geneig is om inligting privaat te hou. Die meeste argumenteer dat funksies op afgeleë, bedienerlose platforms net so vinnig werk as dié op interne bedieners, met die uitsondering van 'n paar onvermydelike vertragingskwessies.
Individuele feite dui egter op die teendeel. Eienskappe wat nie voorheen op 'n spesifieke platform geloop het nie of vir 'n geruime tyd nie geloop het nie, sal 'n rukkie neem om te inisialiseer. Dit is waarskynlik te wyte aan die feit dat hul kode na 'n minder toeganklike bergingsmedium oorgedra is, hoewel - soos met maatstawwe - die meeste verskaffers jou nie van die data-migrasie sal vertel nie.
Natuurlik is daar verskeie maniere om dit te doen. Een daarvan is om kenmerke te optimaliseer vir watter wolktaal jou bedienerlose platform ook al gebruik, maar dit ondermyn ietwat die bewering dat hierdie platforms "rats" is.
Nog 'n benadering is om te verseker dat produktiwiteitskritiese programme gereeld uitgevoer word om dit vars te hou. Hierdie tweede benadering is natuurlik 'n bietjie teenstrydig met die bewering dat bedienerlose platforms meer koste-effektief is omdat jy net betaal vir die tyd wat jou programme loop. Wolkverskaffers het nuwe maniere bekendgestel om koue begin te verminder, maar baie van hulle vereis "skaal tot een", wat die oorspronklike waarde van FaaS ondermyn.
Die koue begin-probleem kan gedeeltelik opgelos word deur bedienerlose stelsels in die huis te laat loop, maar dit kom met sy eie koste en bly 'n nis-opsie vir spanne met goeie hulpbronne.
Jy kan nie hele toepassings laat loop nie
Ten slotte, miskien die belangrikste rede waarom bedienerlose argitekture nie binnekort tradisionele modelle sal vervang nie: hulle kan (gewoonlik) nie hele toepassings laat loop nie.
Meer presies, dit is onprakties uit 'n koste-oogpunt. Jou suksesvolle monoliet moet waarskynlik nie verander word in 'n stel van vier dosyn funksies wat deur agt poorte, veertig toue en 'n dosyn databasisgevalle verbind word nie. Om hierdie rede is bedienerloos beter geskik vir nuwe ontwikkelings. Byna geen bestaande toepassing (argitektuur) kan gemigreer word nie. Jy kan migreer, maar jy moet van voor af begin.
Dit beteken dat in die oorgrote meerderheid van gevalle, bedienerlose platforms gebruik word as 'n aanvulling tot back-end bedieners om rekenaar-intensiewe take uit te voer. Dit maak hulle baie anders as die ander twee vorme van wolktegnologieë—houers en virtuele masjiene—wat ’n holistiese manier bied om afstandrekenaars uit te voer. Dit illustreer een van die uitdagings om van mikrodienste na bedienerloos te beweeg.
Dit is natuurlik nie altyd 'n probleem nie. Die vermoë om periodiek massiewe rekenaarhulpbronne te benut sonder om jou eie hardeware aan te skaf, kan werklike, blywende voordele vir baie organisasies inhou. Maar wanneer sommige toepassings op interne bedieners en ander op bedienerlose wolkargitekture woon, neem bestuur 'n nuwe vlak van kompleksiteit aan.
Lank lewe die rewolusie?
Ten spyte van al hierdie klagtes, is ek nie teen bedienerlose oplossings per se nie. Eerlik. Ontwikkelaars moet net verstaan - veral as hulle vir die eerste keer bedienerloos verken - dat die tegnologie nie 'n direkte vervanging vir bedieners is nie. Kyk eerder na ons wenke en hulpbronne vir en besluit hoe om die model die beste toe te pas.
Bron: will.com