Wichtige punten
- Foar ferskate jierren is ús tasein dat serverless computing in nij tiidrek sil ynliede sûnder in spesifyk OS om applikaasjes út te fieren. Wy waarden ferteld dat dizze struktuer in protte skaalberensproblemen soe oplosse. Yn feite is alles oars.
- Wylst in protte serverless as in nij idee sjogge, kinne har woartels weromgean nei 2006 mei de komst fan Zimki PaaS en Google App Engine, dy't beide serverless arsjitektuer brûke.
- D'r binne fjouwer redenen wêrom't de serverleaze revolúsje stoppe is, fariearjend fan beheinde stipe foar programmeartaal oant prestaasjesproblemen.
- Serverless computing is net sa nutteloos. Heulendal net. Se moatte lykwols net wurde beskôge as in direkte ferfanging foar servers. Foar guon applikaasjes kinne se in handich ark wêze.
De tsjinner is dea, lang libje de tsjinner!
Dit is de striidkreet fan 'e serverless revolúsje. Gewoan in rappe blik op 'e yndustryparse yn' e ôfrûne jierren en it is maklik om te konkludearjen dat it tradisjonele servermodel dea is en dat wy binnen in pear jier allegear serverless-arsjitektuer sille brûke.
As elkenien yn 'e yndustry wit, en lykas wy ek oanjûn yn ús artikel oer , dit is ferkeard. Nettsjinsteande in protte artikels oer de fertsjinsten , it hat nea plakfûn. Yn feite, dat dizze revolúsje miskien in deade ein berikt hawwe.
Guon fan 'e belofte fan serverless modellen binne grif realisearre, mar net allegear. Net eltsenien.
Yn dit artikel wol ik sjen nei de redenen foar dizze betingst. Wêrom is it gebrek oan fleksibiliteit fan serverless modellen noch in barriêre foar har bredere oanname, ek al bliuwe se nuttich yn spesifike, goed definieare omstannichheden.
Wat de adepten fan serverless computing tasein
Foardat wy yngeane op 'e útdagings fan serverless computing, litte wy sjen nei wat it soe leverje. wiene tal fan en - bytiden - tige ambisjeus.
Foar dyjingen dy't net bekend binne mei de term, hjir is in rappe definysje. Serverless computing definiearret in arsjitektuer wêryn applikaasjes (of dielen fan applikaasjes) op oanfraach rinne yn runtime-omjouwings dy't typysk op ôfstân host wurde. Derneist kinne serverless systemen thús wurde hosted. It bouwen fan fearkrêftige serverless systemen hat de ôfrûne jierren in grutte soarch west foar systeembehearders en SaaS-bedriuwen, om't (it wurdt beweare) dizze arsjitektuer ferskate wichtige foardielen biedt boppe it "tradisjonele" client-server-model:
- Serverless modellen fereaskje brûkers net om har eigen bestjoeringssystemen te ûnderhâlden of sels applikaasjes te meitsjen dy't kompatibel binne mei spesifike OS's. Ynstee, ûntwikkelders meitsje dielde koade, upload it nei in serverless platfoarm, en sjoch it rinne.
- Boarnen yn serverleaze kaders wurde typysk per minuut (of sels de twadde) gefactureerd. Dit betsjut dat kliïnten allinich betelje foar de tiid dat se de koade eins útfiere. Dit fergeliket geunstich mei in tradisjonele wolk VM, wêr't de masine meastentiids idle is, mar jo moatte der foar betelje.
- It probleem fan skalberens waard ek oplost. Boarnen yn serverless kaders wurde dynamysk tawiisd sadat it systeem maklik kin omgean mei hommelse surges yn fraach.
Koartsein, serverless modellen leverje fleksibele, lege kosten, skalberbere oplossingen. It is ferrassend dat wy dit idee net earder betocht hawwe.
Is dit echt in nij idee?
Yn feite is it idee net nij. It konsept om brûkers te tastean om allinich te beteljen foar de tiid dat de koade eins rint, bestiet sûnt it waard yntrodusearre troch yn 2006, en om deselde tiid oanbean Google App Engine in hiel ferlykbere oplossing.
Yn feite is wat wy no it "serverless" model neame, âlder dan in protte technologyen dy't no "cloud native" wurde neamd dy't in protte itselde ding leverje. Lykas opmurken, binne serverleaze modellen yn wêzen gewoan in útwreiding fan it SaaS-bedriuwsmodel dat al tsientallen jierren bestiet.
It is ek de muoite wurdich te erkennen dat serverless gjin FaaS-arsjitektuer is, hoewol d'r in ferbining is tusken de twa. FaaS is yn wêzen it compute-sintraal diel fan in serverless arsjitektuer, mar it fertsjintwurdiget net it hiele systeem.
Dus wat is alle drokte oer? No, om't de penetraasjeraten fan ynternet trochgean te skyrocket yn ûntwikkelingslannen, nimt de fraach nei komputerboarnen ek tagelyk ta. Bygelyks, in protte lannen mei rap groeiende e-commerce sektoaren hawwe gewoan net de kompjûterynfrastruktuer foar applikaasjes op dizze platfoarms. Dit is wêr't betelle serverless platfoarms ynkomme.
Problemen mei Serverless modellen
It fangen is dat serverless modellen hawwe ... problemen. Begryp my net ferkeard: ik sis net dat se per se min binne of yn guon omstannichheden gjin wichtige wearde leverje oan guon bedriuwen. Mar de wichtichste eask fan 'e "revolúsje" - dat serverless arsjitektuer sil fluch ferfange tradisjonele arsjitektuer - nea materializes.
Dêrom.
Beheinde stipe foar programmeartalen
De measte serverleaze platfoarms kinne jo allinich applikaasjes útfiere dy't yn bepaalde talen skreaun binne. Dit beheint de fleksibiliteit en oanpassingsfermogen fan dizze systemen serieus.
Serverless platfoarms wurde beskôge te stypjen de measte grutte talen. AWS Lambda- en Azure-funksjes jouwe ek in wrapper foar it útfieren fan applikaasjes en funksjes yn net-stipe talen, hoewol dit faak komt mei in prestaasjekosten. Dat foar de measte organisaasjes is dizze beheining normaal net in grut probleem. Mar hjir is it ding. Ien fan 'e foardielen fan serverleaze modellen soe wêze dat lyts bekende, selden brûkte programma's goedkeaper kinne wurde brûkt, om't jo allinich betelje foar de tiid dy't se rinne. En min bekende, selden brûkte programma's wurde faak skreaun yn ... lyts bekende, selden brûkte programmeartalen.
Dit ûndermynt ien fan 'e wichtichste foardielen fan it serverless model.
Ferkeaper binding
It twadde probleem mei serverleaze platfoarms, of op syn minst de manier wêrop se op it stuit ymplementearre binne, is dat se meastentiids net op operative nivo mei elkoar lykje. Der is praktysk gjin standerdisearring wat skriuwfunksjes, ynset en behear oanbelanget. Dit betsjut dat it migrearjen fan funksjes fan it iene platfoarm nei it oare ekstreem tiidslinend is.
It dreechste diel fan it ferpleatsen nei in serverless model is net de komputerfunksjes, dy't normaal gewoan koadefragmenten binne, mar hoe't applikaasjes kommunisearje mei ferbûne systemen lykas objektopslach, identiteitsbehear en wachtrijen. Funksjes kinne wurde ferpleatst, mar de rest fan 'e applikaasje kin net. Dit is krekt it tsjinoerstelde fan 'e goedkeape en fleksibele platfoarms dy't wurde tasein.
Guon beweare dat serverless modellen nij binne en dat d'r gjin tiid west hat om te standardisearjen hoe't se wurkje. Mar se binne net sa nij, lykas ik hjirboppe opmurken, en in protte oare wolktechnologyen, lykas konteners, binne al folle mear brûkber wurden troch de ûntwikkeling en wiidferspraat oannimmen fan goede noarmen.
Produktiviteit
De komputerprestaasjes fan serverless platfoarms is lestich te mjitten, foar in part om't leveransiers de neiging hawwe om ynformaasje privee te hâlden. De measten beweare dat funksjes op ôfstân, serverleaze platfoarms krekt sa fluch rinne as dy op ynterne servers, mei útsûndering fan in pear ûnûntkombere latencyproblemen.
Lykwols, yndividuele feiten jouwe it tsjinoerstelde. Funksjes dy't net earder op in bepaald platfoarm hawwe rinne of in skoft net rinne, sille wat tiid nimme om te inisjalisearjen. Dit komt wierskynlik troch it feit dat har koade is porteare nei wat minder tagonklik opslachmedium, hoewol - lykas by benchmarks - de measte leveransiers jo net sille fertelle oer de gegevensmigraasje.
Fansels binne d'r ferskate manieren om dit hinne. Ien is om funksjes te optimalisearjen foar elke wolktaal wêrop jo serverless platfoarm draait, mar dit ûndermynt wat de bewearing dat dizze platfoarms "agile" binne.
In oare oanpak is om te soargjen dat produktiviteit-krityske programma's regelmjittich wurde útfierd om se fris te hâlden. Dizze twadde oanpak is fansels in bytsje tsjinspraak foar de bewearing dat serverless platfoarms kosten-effektiver binne, om't jo allinich betelje foar de tiid dat jo programma's rinne. Wolkproviders hawwe nije manieren yntrodusearre om kâlde starts te ferminderjen, mar in protte fan harren fereaskje "skaal nei ien", wat de oarspronklike wearde fan FaaS ûndermynt.
It probleem mei kâld start kin foar in part oplost wurde troch serverless systemen yn eigen hûs te rinnen, mar dit komt mei syn eigen kosten en bliuwt in niche-opsje foar teams mei goed boarnen.
Jo kinne gjin folsleine applikaasjes útfiere
Uteinlik, miskien de wichtichste reden wêrom't serverless arsjitektueren de tradisjonele modellen net gau sille ferfange: se kinne (meastal) gjin folsleine applikaasjes útfiere.
Mear krekter, it is ûnpraktysk út in kosten eachpunt. Jo suksesfolle monolith soe wierskynlik net moatte wurde feroare yn in set fan fjouwer tsientallen funksjes ferbûn troch acht poarten, fjirtich wachtrigen en in tsiental database-eksimplaren. Om dizze reden is serverless better geskikt foar nije ûntjouwings. Hast gjin besteande applikaasje (arsjitektuer) kin wurde migrearre. Jo kinne migrearje, mar jo moatte fanôf it begjin begjinne.
Dit betsjut dat yn 'e grutte mearderheid fan' e gefallen serverless platfoarms wurde brûkt as oanfolling op back-end servers om komputer-yntinsive taken út te fieren. Dit makket se heul oars fan 'e oare twa foarmen fan wolktechnologyen - konteners en firtuele masines - dy't in holistyske manier biede om komputer op ôfstân út te fieren. Dit yllustrearret ien fan 'e útdagings fan it ferpleatsen fan mikrotsjinsten nei serverless.
Fansels is dit net altyd in probleem. De mooglikheid om periodyk massive kompjûterboarnen te brûken sûnder jo eigen hardware te keapjen kin echte, bliuwende foardielen bringe foar in protte organisaasjes. Mar as guon applikaasjes wenje op ynterne servers en oaren op serverless wolk-arsjitektueren, nimt behear in nij nivo fan kompleksiteit oan.
Lang libje de revolúsje?
Nettsjinsteande al dizze klachten, ik bin net tsjin serverless oplossings per se. Earlik sein. Untwikkelders moatte gewoan begripe - foaral as se foar it earst serverless ferkenne - dat de technology gjin direkte ferfanging is foar servers. Besjoch ynstee ús tips en boarnen foar en beslute hoe't jo it model it bêste kinne tapasse.
Boarne: www.habr.com