Võtmepunktid
- Juba mitu aastat on meile lubatud, et serverita andmetöötlus (serverita) avab uue ajastu ilma konkreetse OS-ita rakenduste käitamiseks. Meile öeldi, et selline struktuur lahendaks palju mastaapsuse probleeme. Tegelikult on kõik erinev.
- Kuigi paljud peavad serverita tehnoloogiat uueks ideeks, võib selle juured ulatuda 2006. aastasse Zimki PaaS-i ja Google App Engine'iga, mis mõlemad kasutavad serverita arhitektuuri.
- Serverita revolutsiooni seiskumisel on neli põhjust, alates piiratud programmeerimiskeele toest kuni jõudlusprobleemideni.
- Serverita andmetöötlus pole sugugi nii kasutu. Kaugel sellest. Siiski ei tohiks neid pidada serverite otseseks asenduseks. Mõne rakenduse jaoks võivad need olla käepärased tööriistad.
Server on surnud, elagu server!
See on serverita revolutsiooni pooldajate lahinguhüüd. Kiirest pilgust tööstuse ajakirjandusele viimastel aastatel piisab, et järeldada, et traditsiooniline serverimudel on surnud ja mõne aasta pärast hakkame kõik kasutama serverita arhitektuure.
Nagu kõik selle valdkonna esindajad teavad ja nagu me ka oma artiklis märkisime , see on vale. Vaatamata paljudele sisulist artiklitele , seda ei toimunud kunagi. Tegelikult, et see revolutsioon võib olla jõudnud ummikusse.
Mõned lubadused serverita mudelite kohta on kindlasti täitunud, kuid mitte kõik. Mitte igaüks.
Selles artiklis tahan kaaluda selle tingimuse põhjuseid. Miks on serverita mudelite paindlikkuse puudumine endiselt takistuseks nende laiemale kasutuselevõtule, kuigi need on endiselt kasulikud konkreetsetes, täpselt määratletud olukordades.
Mida serverita andmetöötluse asjatundjad lubasid
Enne serverita andmetöötluse probleemide juurde asumist vaatame, mida nad pidid pakkuma. neid oli palju ja kohati väga ambitsioonikad.
Neile, kes seda terminit ei tunne, on siin lühike määratlus. Serverita andmetöötlus määratleb arhitektuuri, milles rakendused (või rakenduste osad) töötavad nõudmisel käituskeskkondades, mida tavaliselt hostitakse eemalt. Lisaks saab majutada serverita süsteeme. Tugevate serverita süsteemide loomine on viimastel aastatel olnud süsteemiadministraatorite ja SaaS-i ettevõtete jaoks suur murekoht, kuna (väidetavalt) pakub see arhitektuur mitmeid olulisi eeliseid võrreldes "traditsioonilise" kliendi/serveri mudeliga:
- Serverita mudelid ei nõua kasutajatelt oma operatsioonisüsteemide haldamist ega isegi konkreetsete operatsioonisüsteemidega ühilduvate rakenduste loomist. Selle asemel loovad arendajad jagatud koodi, laadivad selle üles serverita platvormile ja jälgivad selle töötamist.
- Serverita raamistike ressursside eest arveldatakse tavaliselt minutite (või isegi sekundite) alusel. See tähendab, et kliendid maksavad ainult koodi tegeliku täitmise aja eest. See on soodne võrreldes traditsioonilise pilv-VM-iga, kus masin on suurema osa ajast jõude, kuid selle eest tuleb maksta.
- Samuti sai lahendatud skaleeritavuse probleem. Serverita raamistike ressursid määratakse dünaamiliselt, et süsteem saaks hõlpsasti hakkama ootamatute nõudluse hüpetega.
Lühidalt öeldes pakuvad serverita mudelid paindlikke, odavaid ja skaleeritavaid lahendusi. Olen üllatunud, et me sellele ideele varem ei mõelnud.
Kas see on tõesti uus idee?
Tegelikult pole idee uus. Mõiste, mis võimaldab kasutajatel maksta ainult koodi tegeliku käitamise aja eest, on kehtinud alates selle kasutuselevõtust aastal 2006 ja umbes samal ajal tuli Google App Engine välja väga sarnase lahendusega.
Tegelikult on see, mida me praegu nimetame "serverita" mudeliks, vanem kui paljud tehnoloogiad, mida praegu nimetatakse "pilvepõhiseks", mis pakuvad peaaegu sama. Nagu märgitud, on serverita mudelid sisuliselt vaid aastakümneid eksisteerinud SaaS-i ärimudeli laiendus.
Samuti tasub tunnistada, et serverita mudel ei ole FaaS-i arhitektuur, kuigi nende kahe vahel on seos. FaaS on sisuliselt serverita arhitektuuri arvutuskeskne osa, kuid see ei esinda kogu süsteemi.
Milleks siis kogu see hüpe? Noh, kuna Interneti leviku määr arengumaades kasvab pidevalt, kasvab ka nõudlus arvutiressursside järele. Näiteks paljudel kiiresti kasvavate e-kaubanduse sektoritega riikides puudub nendel platvormidel rakenduste jaoks lihtsalt arvutitaristu. Siin tulevad sisse tasulised serverita platvormid.
Probleemid serverita mudelitega
Konks on selles, et serverita mudelitel on… probleeme. Ärge saage minust valesti aru: ma ei väida, et need on iseenesest halvad või ei paku mõnele ettevõttele teatud tingimustes olulist väärtust. Kuid "revolutsiooni" põhiväide – et serverita arhitektuur asendab kiiresti traditsioonilise – ei saa kunagi teoks.
Sellepärast.
Piiratud tugi programmeerimiskeeltele
Enamik serverita platvorme lubab töötada ainult teatud keeltes kirjutatud rakendustel. See piirab tõsiselt nende süsteemide paindlikkust ja kohanemisvõimet.
Arvatakse, et serverita platvormid toetavad enamikku peamisi keeli. AWS Lambda ja Azure Functions pakuvad ka ümbrist rakenduste ja funktsioonide käitamiseks toetamata keeltes, kuigi see on sageli jõudluskuluga. Nii et enamiku organisatsioonide jaoks pole see piirang tavaliselt suur asi. Aga siin on asi. Serverita mudelite üks eeliseid peaks olema see, et ebaselgeid, harva kasutatavaid programme saab kasutada odavamalt, kuna maksate ainult nende tööaja eest. Ja ebaselged, harva kasutatavad programmid on sageli kirjutatud... ebaselgetes, harva kasutatavates programmeerimiskeeltes.
See kahjustab serverita mudeli üht peamist eelist.
Müüjaga sidumine
Teine serverita platvormide probleem või vähemalt nende praegune rakendamine on see, et need ei näe tavaliselt töötasandil sarnased. Kirjutamisfunktsioonide, juurutamise ja haldamise osas standardiseerimine praktiliselt puudub. See tähendab, et funktsioonide migreerimine ühelt platvormilt teisele on äärmiselt aeganõudev.
Serverita mudelile üleminekul pole kõige raskem osa mitte arvutusfunktsioonid, mis on tavaliselt vaid koodijupid, vaid see, kuidas rakendused suhtlevad ühendatud süsteemidega, nagu objektide salvestamine, identiteedihaldus ja järjekorrad. Funktsioone saab liigutada, kuid ülejäänud rakendust mitte. See on täpselt vastupidine lubatud odavatele ja paindlikele platvormidele.
Mõned väidavad, et serverita mudelid on uued ja nende toimimise standardimiseks pole olnud aega. Kuid need pole nii uued, nagu ma eespool märkisin, ja paljud teised pilvetehnoloogiad, näiteks konteinerid, on heade standardite väljatöötamise ja laialdase kasutuselevõtu tõttu juba palju mugavamaks muutunud.
Производительность
Serverita platvormide arvutusjõudlust on raske mõõta, osaliselt seetõttu, et müüjad hoiavad teavet salajas. Enamik väidavad, et serverita serverite kaugplatvormide funktsioonid töötavad sama kiiresti kui sisemistes serverites, välja arvatud mõned vältimatud latentsusprobleemid.
Mõned tõendid viitavad aga vastupidisele. Funktsioonide initsialiseerimine, mis pole varem teatud platvormil töötanud või pole mõnda aega töötanud, võtab aega. Tõenäoliselt on see tingitud sellest, et nende kood on teisaldatud mõnele vähem kergesti kättesaadavale andmekandjale, kuigi – nagu ka võrdlusaluste puhul – enamik tarnijaid ei räägi teile andmete teisaldamisest.
Loomulikult on sellest mööda saamiseks mitu võimalust. Üks on funktsioonide optimeerimine mis tahes pilvekeele jaoks, millel teie serverita platvorm töötab, kuid see õõnestab mõnevõrra väidet, et need platvormid on "agiilsed".
Teine lähenemisviis on tagada, et jõudluskriitilised programmid töötaksid regulaarselt, et need oleksid värsked. See teine lähenemisviis on muidugi veidi vastuolus väitega, et serverita platvormid on kuluefektiivsemad, kuna maksate ainult programmide töötamise aja eest. Pilvepakkujad on kasutusele võtnud uusi viise külmkäivituste vähendamiseks, kuid paljud neist nõuavad "skaala ühele" (skaala ühele), mis õõnestab FaaS-i algset väärtust.
Külmkäivituse probleemi saab osaliselt lahendada serverita süsteemide majas käitamisega, kuid see tuleb omal kulul ja jääb nišivalikuks hästi varustatud meeskondade jaoks.
Te ei saa käitada terveid rakendusi
Lõpuks võib-olla kõige olulisem põhjus, miks serverita arhitektuurid ei asenda niipea traditsioonilisi mudeleid, on see, et need (üldiselt) ei saa käivitada terveid rakendusi.
Täpsemalt on see kulude seisukohalt ebapraktiline. Tõenäoliselt ei tohiks teie edukat monoliiti muuta neljast tosinast funktsioonist koosnevaks komplektiks, mis on omavahel seotud kaheksa lüüsi, neljakümne järjekorra ja tosina andmebaasi eksemplariga. Sel põhjusel sobib serverita uute arenduste jaoks paremini. Praktiliselt ühtegi olemasolevat rakendust (arhitektuuri) ei saa teisaldada. Võite migreerida, kuid peate alustama nullist.
See tähendab, et enamikul juhtudel kasutatakse serverita platvorme taustaserverite täiendusena arvutusmahukate ülesannete täitmiseks. See erineb suuresti kahest teisest pilvandmetöötluse vormist, konteineritest ja virtuaalmasinatest, mis pakuvad terviklikku viisi kaugandmetöötluse teostamiseks. See illustreerib üht väljakutset mikroteenustelt serverita süsteemidele üleminekul.
Muidugi pole see alati probleem. Võimalus perioodiliselt kasutada tohutuid arvutusressursse ilma oma riistvara ostmata võib tuua paljudele organisatsioonidele tõelist ja püsivat kasu. Kuid kui mõned rakendused asuvad siseserverites ja teised serverita pilvarhitektuurides, läheb haldus uuele keerukuse tasemele.
Elagu revolutsioon?
Kõigist nendest kaebustest hoolimata ei ole ma serverita lahenduste vastu iseenesest. Ausalt öeldes. Lihtsalt arendajad peavad mõistma – eriti kui nad esimest korda uurivad serverita mudeleid –, et see tehnoloogia ei asenda servereid otseselt. Selle asemel vaadake meie nõuandeid ja ressursse ja otsustage, kuidas seda mudelit kõige paremini rakendada.
Allikas: www.habr.com