Peamised punktid

• Juba paar aastat on meile lubatud, et serverita arvutamine (serverless) avab uue ajastu, kus rakendusi ei tohiks käitada konkreetse operatsioonisüsteemi abil. Meile on öeldud, et see struktuur lahendab palju skaleeritavuse probleeme. Tegelikult on kõik teisiti.
• Kuigi paljud peavad serverita tehnoloogiat uueks ideeks, ulatuvad selle juured tagasi 2006. aastasse, mil ilmusid Zimki PaaS ja Google App Engine — mõlemal juhul kasutatakse serverita arhitektuuri.
• On neli põhjust, miks serverita revolutsioon on tänaseks ummikusse jooksnud: alates piiratud programmeerimiskeelte toetamisest kuni jõudlusprobleemideni.
• Serverita arvutamine ei ole sugugi kasutu. Ka kaugeltki mitte. Kuid neid ei tohiks pidada otseseks asenduseks serveritele. Teatud rakenduste jaoks võivad need olla mugav tööriist.

Server on surnud, longtemps server!

Nii kõlab serverita revolutsiooni toetajate lahinguhüüd. Piisab, kui kiiresti sirvida viimaste aastate tööstusuudiseid, et jõuda järeldusele, et traditsiooniline serverite mudel on surnud ja et paariaasta pärast kasutame kõik serverita arhitektuure.

Nagu on teada igale valdkonna inimesele ja nagu me ka oma artiklis märkisime serverita arvutamise seisundist, ei ole see nii. Vaatamata paljudele artiklitele serverita revolutsiooni voorustest , ei ole see kunagi tõeliselt käima läinud. Tegelikult, näitavad viimased uuringud , et see revolutsioon on ilmselt ummikusse jooksnud.Mõned serverita mudelite lubadustest on kindlasti täidetud, kuid mitte kõik. Kui kaugel ei ole kõik.

Selles artiklis tahan ma käsitleda sellise olukorra põhjuseid. Miks serverita mudelite paindlikkuse puudumine on endiselt takistuseks nende laiemale kasutusele, kuigi nad jäävad kasulikuks konkreetsetes, selgelt määratletud olukordades.

Mida lubasid serverita arvutamise toetajad

Enne kui liigume serverita arvutamise probleemide juurde, vaatame, mida nad pidid pakkuma.

Serverita revolutsiooni lubadused olid rohked ja — kohati — väga ambitsioonikad. olid ja — vahel — väga ambitsioonikad.

Neile, kes ei tunne mõistet, siin on lühike määratlus. Serverivabad arvutused määratlevad arhitektuuri, kus rakendused (või rakenduste osad) käivitatakse nõudmisel keskkondades, mis asuvad tavaliselt eemal. Lisaks saab serverivabu süsteeme majutada ka enda juures. Viimase paari aasta jooksul on usaldusväärsete serverivabade süsteemide loomine olnud süsteemiadministraatorite ja SaaS-ettevõtete peamine mure, kuna (väidetavalt) pakub see arhitektuur mitmeid olulisi eeliseid võrreldes "traditsioonilise" kliendi-serveri mudeliga:

1. Serverivabad mudelid ei nõua, et kasutajad hallaksid oma operatsioonisüsteeme või isegi loobuksid rakendustest, mis on ühilduvad teatud OS-idega. Selle asemel loovad arendajad üldise koodi, laadivad selle üles serverivabale platvormile ja jälgivad selle täitmist.
2. Serverivabades raamistikudes maksustatakse ressursse tavaliselt minutite (või isegi sekundite) kaupa. See tähendab, et kliendid maksavad ainult siis, kui nende kood tegelikult töötab. See on suur erinevus traditsioonilisest pilve VM-ist, kus masin seisab suure osa ajast tühjana, kuid selle eest tuleb ikkagi maksta.
3. Skaalautuvuse probleem on samuti lahendatud. Ressursse serverivabades raamistikudes määratakse dünaamiliselt, nii et süsteem suudab hõlpsasti toime tulla äkiliste nõudluse tõusudega.

Lühidalt öeldes pakuvad serverivabad mudelid paindlikke, odavaid ja skaleeritavaid lahendusi. Üllatav, et me ei tulnud selle ideeni varem.

Kas see on tõeliselt uus idee?

Tegelikkuses ei ole idee uus. Kontseptsioon, mis võimaldab kasutajatel maksta ainult siis, kui kood tegelikult käivitatakse, on eksisteerinud alates selle sisseviimisest Zimki PaaS aastal 2006 ning umbes samal ajal pakkus Google App Engine väga sarnast lahendust.

Tegelikkuses on see, mida me nüüd nimetame "serverivabaks" mudeliks, vanem kui paljud tehnoloogiad, mida nüüd nimetatakse "põhise pilveks", ja mis pakuvad peaaegu sama. Nagu juba mainitud, on serverivabad mudelid põhimõtteliselt lihtsalt SaaS äri mudeli jätk, mis on olemas olnud juba mitu aastakümmet.

Samuti tuleb tunnistada, et serverita mudel ei ole FaaS arhitektuur, kuigi nende vahel on seos. FaaS on põhimõtteliselt arvutusi suunav osa serverita arhitektuurist, kuid see ei hõlma kogu süsteemi.

Milleks kogu see lärmakus? Noh, kuna interneti levik arenguriikides jätkab kiiret kasvu, kasvab samal ajal nõudlus arvutusressursside järele. Näiteks paljudes riikides, kus kiiresti arenevad e-kaubanduse sektorid, puudub lihtsalt arvutinfrastruktuur nende platvormide rakenduste jaoks. Siin tulevadki mängu tasulised serverita platvormid.

Serverita mudelite probleemid

Probleem on selles, et serverita mudelitel on... probleemid. Ärge saage valesti aru: ma ei ütle, et need on iseenesest halvad või ei too teatud ettevõttele teatud olukordades märkimisväärset väärtust. Kuid peamine väide "revolutsioonist" - et serverita arhitektuur asendab kiiresti traditsioonilise - ei saa kunagi teoks.

Siin on põhjus.

Piiratud programmeerimiskeelte tugi

Enamik serverita platvorme võimaldab käivitada ainult neid rakendusi, mis on kirjutatud teatud keeles. See piirab tõsiselt nende süsteemide paindlikkust ja kohanemisvõimet.

Arvatakse, et serverita platvormid toetavad enamikku peamistest keeltest. AWS Lambda ja Azure Functions pakuvad samuti kihti rakenduste ja funktsioonide käitamiseks toe puudumisega keeltele, kuigi see on sageli seotud jõudluse kuludega. Nii et enamikule organisatsioonidest ei ole see piirang üldiselt suur probleem. Aga siin on asi. Eeldatakse, et üks serverita mudelite eeliseid on see, et vähe tuntud, harva kasutatavaid programme saab odavalt kasutada, kuna maksate ainult nende käitusaja eest. Ja vähe tuntud, harva kasutatavad programmid on sageli kirjutatud... vähe tuntud, harva kasutatavates programmeerimiskeeltes.

See õõnestab üht serverita mudeli põhipunkte.

Tarnija sidusus

Teise probleemi puhul serverivabade platvormidega või vähemalt nende rakendamisel tänapäeval on see, et need ei sarnane üksteisele operatsioonitasandil. Funktsioonide, juurutamise ja haldamise osas puudub peaaegu igasugune standardiseerimine. See tähendab, et funktsioonide migreerimine ühelt platvormilt teisele võtab äärmiselt kaua aega.

Kõige raskem osa serverivabale mudelile ülemisest ei ole arvutusfunktsioonid, mis tavaliselt on lihtsalt koodifragmendid, vaid see, kuidas rakendused on seotud seotud süsteemidega, nagu objektide salvestamine, identiteedihaldus ja järjekorrad. Funktsioone saab liigutada, kuid rakenduse ülejäänud osa mitte. See on täielik vastand lubatud odavatele ja paindlikele platvormidele.

Mõned väidavad, et serverivabad mudelid ilmusid hiljuti ning ei olnud aega nende toimimise standardimiseks. Kuid nagu ma eespool mainisin, ei ole nad nii uued ja paljud teised pilvetehnoloogiad, näiteks konteinerid, on juba palju mugavamaks muutunud tänu headele standardite väljatöötamisele ja laialdasele kasutusele.

Tõhusus

Serverivabade platvormide arvutusvõimsust on keeruline mõõta, osaliselt seetõttu, et müüjad püüavad teavet saladuses hoida. Enamik väidab, et funktsioonid kaugemal asuvatel serverivabadel platvormidel töötavad sama kiiresti kui kohalikes serverites, välja arvatud mõned vältimatud latentsusprobleemid.

Kuid eraldi faktid viitavad vastupidisele. Funktsioonid, mida varem ei käivitatud teatud platvormil või mis ei olnud mõnda aega käivitunud, vajavad initsialiseerimiseks teatud aega. Tõenäoliselt on see tingitud sellest, et nende kood viidi vähem kergesti ligipääsetavasse andmekandjasse, kuigi – nagu ka tulemustes – enamik müüjaid ei ütle sulle andmete üleviimisest.

Loomulikult on mitmeid võimalusi selle üle saamiseks. Üks neist seisneb funktsioonide optimeerimises igasuguste pilvekeelete jaoks, milles teie serverivaba platvorm töötab, kuid see kahtleb veidi väites, et need platvormid on "paindlikud".

Teine lähenemine on regulaarselt täita jõudlust nõudvaid programme, et need püsiksid „värsked“. See teine lähenemine on muidugi veidi vastuolus väitega, et serverivabad platvormid on kulutõhusamad, kuna maksate ainult oma programmide tööaja eest. Pilveteenusepakkujad on kehtestanud uusi meetodeid külmade käivituste vähendamiseks, kuid paljud neist nõuavad „üheks skaleerimist“ (scale to one), mis seab kahtluse alla FaaS-i algse väärtuse.

Küsimust „külma käivitust“ saab osaliselt lahendada, käivitades serverivabad süsteemid iseseisvalt, kuid see toob kaasa omad kulud ja jääb nišivalikuks hästi varustatud ressurssidega meeskondadele.

Te ei saa käivitada terveid rakendusi

Lõpuks, võib-olla kõige olulisem põhjus, miks serverivabad arhitektuurid ei asenda traditsioonilisi mudeleid lähiajal: neid (tavaliselt) ei saa kasutada tervete rakenduste käitamiseks.

Täpsemalt, see ei ole kulude osas mõttekas. Teie edukat monoliiti ei tasu ilmselt muuta neljakümne funktsiooni komplektiks, mis on seotud kaheksa värava, neljakümne järjekorra ja tosin DB eksemplariga. Selle tõttu on serverivabad lahendused paremad uute arenduste jaoks. Praktiliselt mitte ühtegi olemasolevat rakendust (arhitektuuri) ei saa migreerida. Võite migreerida, kuid peate alustama nullist.

See tähendab, et enamikul juhtudel kasutatakse serverivabu platvorme sisemiste serverite täiendamiseks suurte arvutuslike ülesannete täitmiseks. See eristab neid tugevalt kahest teisest pilvetehnoloogia vormist - konteineritest ja virtuaalmasinatest, mis pakuvad terviklikku lähenemist kaugarvutuste teostamisele. See illustreerib mõningaid raskusi mikroteenustelt serverivabade süsteemide üleminekul.

Muidugi ei tähenda see alati probleemi. Võimalus perioodiliselt kasutada tohutuid arvutusressursse ilma oma riistvara ostmata võib tuua reaalse ja pikaajalise kasu paljudele organisatsioonidele. Kuid kui mõned rakendused on sise-serverites ja teised serverita pilvearhitektuurides, siis muutub haldamine uueks keerukuse tasemeks.

Elagu revolutsioon?

Hoolimata kõigist neist kaebustest ei ole ma serverita lahenduste vastu. Ausalt öeldes. Lihtsalt arendajad peavad mõistma – eriti kui nad uurivad serverita mudeleid esmakordselt – et see tehnoloogia ei asenda servereid otse. Selle asemel tutvuge meie nõuannete ja ressurssidega serverita rakenduste loomine ja otsustage, kuidas seda mudelit parimal viisil kasutada.

Allikas: habr.com