Esencaj punktoj
- Jam de kelkaj jaroj oni promesis al ni, ke senservila komputado enkondukos novan epokon sen specifa OS por ruli aplikojn. Oni diris al ni, ke ĉi tiu strukturo solvus multajn skaleblajn problemojn. Fakte, ĉio estas malsama.
- Dum multaj rigardas senservila kiel novan ideon, ĝiaj radikoj povas esti spuritaj reen al 2006 kun la apero de Zimki PaaS kaj Google App Engine, kiuj ambaŭ uzas senservila arkitekturon.
- Estas kvar kialoj kial la senservila revolucio haltis, intervalante de limigita programlingvosubteno ĝis agado-problemoj.
- Senservila komputado ne estas tiom senutila. Tute ne. Tamen, ili ne devus esti konsiderataj kiel rekta anstataŭaĵo por serviloj. Por iuj aplikoj ili povas esti oportuna ilo.
La servilo mortis, vivu la servilo!
Jen la batalkrio de la senservila revolucio. Nur rapida rigardo al la industria gazetaro dum la lastaj jaroj kaj estas facile konkludi, ke la tradicia servila modelo estas mortinta kaj ke post kelkaj jaroj ni ĉiuj uzos senservilajn arkitekturojn.
Kiel ĉiuj en la industrio scias, kaj kiel ni ankaŭ atentigis en nia artikolo pri , ĉi tio estas malĝusta. Malgraŭ multaj artikoloj pri la meritoj , ĝi neniam okazis. Fakte, ke tiu ĉi revolucio eble atingis sakstraton.
Iuj el la promeso de senservilaj modeloj certe realiĝis, sed ne ĉiuj. Ne ĉiuj.
En ĉi tiu artikolo mi volas rigardi la kialojn de ĉi tiu kondiĉo. Kial la manko de fleksebleco de senservilaj modeloj ankoraŭ estas baro al ilia pli larĝa adopto, kvankam ili restas utilaj en specifaj, bone difinitaj cirkonstancoj.
Kion promesis la adeptoj de senservila komputado
Antaŭ ol ni eniros la defiojn de senservila komputado, ni rigardu, kion ĝi devis provizi. estis multaj kaj - foje - tre ambiciaj.
Por tiuj, kiuj ne konas la terminon, jen rapida difino. Senservila komputiko difinas arkitekturon en kiu aplikoj (aŭ partoj de aplikoj) funkcias laŭ postulo en rultempaj medioj kiuj estas tipe gastigitaj malproksime. Krome, senservilaj sistemoj povas esti gastigitaj hejme. Konstrui rezistemajn senservilajn sistemojn estis grava zorgo por sistemadministrantoj kaj SaaS-kompanioj dum la lastaj jaroj, ĉar (oni asertas) ĉi tiu arkitekturo ofertas plurajn ŝlosilajn avantaĝojn super la "tradicia" klient-servila modelo:
- Senservilaj modeloj ne postulas uzantojn konservi siajn proprajn operaciumojn aŭ eĉ krei aplikojn kongruajn kun specifaj OS-oj. Anstataŭe, programistoj kreas komunan kodon, alŝutas ĝin al senservila platformo kaj rigardas ĝin funkcii.
- Rimedoj en senservilaj kadroj estas kutime fakturitaj je la minuto (aŭ eĉ la dua). Ĉi tio signifas, ke klientoj pagas nur por la tempo, kiam ili efektive kuras la kodon. Ĉi tio komparas favore kun tradicia nuba VM, kie la maŝino estas neaktiva plejofte, sed vi devas pagi por ĝi.
- La problemo de skaleblo ankaŭ estis solvita. Rimedoj en senservilaj kadroj estas dinamike asignitaj tiel ke la sistemo povas facile elteni subitajn kreskojn de postulo.
Mallonge, senservilaj modeloj provizas flekseblajn, malmultekostajn, skaleblajn solvojn. Estas mirinde, ke ni ne pensis pri ĉi tiu ideo pli frue.
Ĉu ĉi tio vere estas nova ideo?
Fakte, la ideo ne estas nova. La koncepto permesi uzantojn pagi nur por la tempo, kiam la kodo efektive funkcias, ekzistas ekde kiam ĝi estis lanĉita de en 2006, kaj ĉirkaŭ la sama tempo Google App Engine ofertis tre similan solvon.
Fakte, tio, kion ni nun nomas la "senservila" modelo, estas pli malnova ol multaj teknologioj nun nomataj "nubaj denaskaj" kiuj provizas multe la samon. Kiel notite, senservilaj modeloj estas esence nur etendaĵo de la komerca modelo SaaS, kiu ekzistas dum jardekoj.
Ankaŭ indas rekoni, ke senservilo ne estas FaaS-arkitekturo, kvankam ekzistas ligo inter ambaŭ. FaaS estas esence la komput-centra parto de senservila arkitekturo, sed ĝi ne reprezentas la tutan sistemon.
Do pri kio temas la tuta tumulto? Nu, ĉar interretaj penetraj indicoj daŭre altiĝas en evolulandoj, ankaŭ la postulo pri komputikaj rimedoj samtempe pliiĝas. Ekzemple, multaj landoj kun rapide kreskantaj e-komercaj sektoroj simple ne havas la komputikan infrastrukturon por aplikoj sur ĉi tiuj platformoj. Ĉi tie envenas pagitaj senservilaj platformoj.
Problemoj kun Senservilaj Modeloj
La kapto estas, ke senservilaj modeloj havas... problemojn. Ne miskomprenu min: mi ne diras, ke ili estas malbonaj en si mem aŭ ne donas gravan valoron al iuj kompanioj en iuj cirkonstancoj. Sed la ĉefa aserto de la "revolucio" - ke senservila arkitekturo rapide anstataŭigos tradician arkitekturon - neniam realiĝas.
Tial.
Limigita subteno por programlingvoj
Plej multaj senservilaj platformoj nur permesas ruli aplikaĵojn skribitajn en certaj lingvoj. Ĉi tio grave limigas la flekseblecon kaj adapteblecon de ĉi tiuj sistemoj.
Senservilaj platformoj estas konsiderataj subtenaj plej gravaj lingvoj. AWS Lambda kaj Azure Functions ankaŭ disponigas envolvaĵon por ruli aplikojn kaj funkciojn en nesubtenataj lingvoj, kvankam tio ofte venas kun rendimentokosto. Do por plej multaj organizoj ĉi tiu limigo kutime ne estas grava afero. Sed jen la afero. Unu el la avantaĝoj de senservilaj modeloj supozeble estas, ke malmulte konataj, malofte uzataj programoj povas esti uzataj pli malmultekoste ĉar vi pagas nur por la tempo, kiam ili funkcias. Kaj malmulte konataj, malofte uzataj programoj estas ofte verkitaj en... malmulte konataj, malofte uzataj programlingvoj.
Ĉi tio subfosas unu el la ĉefaj avantaĝoj de la senservila modelo.
Vendisto ligado
La dua problemo kun senservilaj platformoj, aŭ almenaŭ la maniero kiel ili estas nuntempe efektivigitaj, estas ke ili kutime ne similas unu al la alia sur la funkcia nivelo. Preskaŭ ne ekzistas normigo pri skribaj funkcioj, disfaldiĝo kaj administrado. Ĉi tio signifas, ke migrado de funkcioj de unu platformo al alia estas ege tempopostula.
La plej malfacila parto de transloĝiĝo al senservila modelo ne estas la komputilaj funkcioj, kiuj kutime estas nur fragmentoj de kodo, sed kiel aplikaĵoj komunikas kun konektitaj sistemoj kiel objektostokado, identecadministrado kaj atendovicoj. Funkcioj povas esti movitaj, sed la resto de la aplikaĵo ne povas. Ĉi tio estas la ĝusta malo de la malmultekostaj kaj flekseblaj platformoj promesitaj.
Iuj argumentas, ke senservilaj modeloj estas novaj kaj ne estis tempo por normigi kiel ili funkcias. Sed ili ne estas tiom novaj, kiel mi rimarkis supre, kaj multaj aliaj nubaj teknologioj, kiel ujoj, jam fariĝis multe pli uzeblaj danke al la disvolviĝo kaj disvastigita adopto de bonaj normoj.
Produkteco
La komputika efikeco de senservilaj platformoj estas malfacile mezurebla, parte ĉar vendistoj emas konservi informojn privataj. Plej multaj argumentas, ke funkcioj sur foraj, senservilaj platformoj funkcias same rapide kiel tiuj sur internaj serviloj, escepte de kelkaj neeviteblaj latentecaj problemoj.
Tamen individuaj faktoj indikas la malon. Trajtoj, kiuj antaŭe ne funkciis sur aparta platformo aŭ ne funkciis dum iom da tempo, daŭros iom da tempo por pravalorigi. Ĉi tio verŝajne estas pro la fakto, ke ilia kodo estis portita al iu malpli alirebla stokadmedio, kvankam - kiel kun komparnormoj - la plej multaj vendistoj ne rakontos al vi pri la datummigrado.
Kompreneble, estas pluraj manieroj ĉirkaŭ ĉi tio. Unu estas optimumigi funkciojn por kia ajn nuba lingvo, sur kiu funkcias via senservila platformo, sed ĉi tio iom subfosas la aserton, ke ĉi tiuj platformoj estas "facilmovaj".
Alia aliro estas certigi ke produktivec-kritikaj programoj estas funkciantaj regule por konservi ilin freŝaj. Ĉi tiu dua aliro, kompreneble, estas iom kontraŭdira al la aserto, ke senservilaj platformoj estas pli kostefikaj ĉar vi pagas nur por la tempo, kiam viaj programoj funkcias. Nubaj provizantoj enkondukis novajn manierojn redukti malvarmajn startojn, sed multaj el ili postulas "skalon al unu", kio subfosas la originan valoron de FaaS.
La problemo de malvarma komenco povas esti parte solvita per funkciado de senservilaj sistemoj endome, sed ĉi tio venas kun siaj propraj kostoj kaj restas niĉa elekto por bone riĉaj teamoj.
Vi ne povas ruli tutajn aplikaĵojn
Fine, eble la plej grava kialo kial senservilaj arkitekturoj ne baldaŭ anstataŭigos tradiciajn modelojn: ili (kutime) ne povas ruli tutajn aplikaĵojn.
Pli precize, ĝi estas nepraktika el kosta vidpunkto. Via sukcesa monolito verŝajne ne devus esti igita aro de kvar dekduoj da funkcioj ligitaj per ok enirejoj, kvardek vicoj kaj dekduo da datumbazoj. Tial, senservilo pli taŭgas por novaj evoluoj. Preskaŭ neniu ekzistanta aplikaĵo (arkitekturo) povas esti migrita. Vi povas migri, sed vi devas komenci de nulo.
Ĉi tio signifas, ke en la vasta plimulto de kazoj, senservilaj platformoj estas uzataj kiel komplemento al malantaŭaj serviloj por plenumi komputigajn taskojn. Ĉi tio igas ilin tre malsamaj de la aliaj du formoj de nubaj teknologioj - ujoj kaj virtualaj maŝinoj - kiuj ofertas tutecan manieron fari malproksiman komputadon. Ĉi tio ilustras unu el la defioj transiri de mikroservoj al senservilo.
Kompreneble, ĉi tio ne ĉiam estas problemo. La kapablo periode utiligi amasajn komputilajn rimedojn sen devi aĉeti vian propran aparataron povas alporti realajn, daŭrajn avantaĝojn al multaj organizoj. Sed kiam iuj aplikaĵoj loĝas sur internaj serviloj kaj aliaj sur senservilaj nubaj arkitekturoj, administrado alprenas novan nivelon de komplekseco.
Vivu la revolucio?
Malgraŭ ĉiuj ĉi plendoj, mi ne estas kontraŭ senservilaj solvoj en si mem. Sincere. Programistoj nur bezonas kompreni—precipe se ili esploras senservila por la unua fojo—ke la teknologio ne estas rekta anstataŭaĵo por serviloj. Anstataŭe, rigardu niajn konsiletojn kaj rimedojn por kaj decidi kiel plej bone apliki la modelon.
fonto: www.habr.com