Peamised punktid
- Juba mitu aastat on meile lubatud, et serverivabad arvutused (serverless) avavad uue ajastu, kus rakendusi ei käivitata konkreetse opsüsteemi abil. Meile on öeldud, et see struktuur lahendab palju skalatsiooni probleeme. Tõelisus on aga hoopis teistsugune.
- Kuigi paljud peavad serverivaba tehnoloogiat uueks ideeks, ulatuvad selle juured tagasi 2006. aastasse, mil ilmusid Zimki PaaS ja Google App Engine — mõlemad kasutavad serverivaba arhitektuuri.
- On neli põhjust, miks serverivaba revolutsioon on lahtiselt kokku jooksnud: alates piiratud programmeerimiskeelte toetamisest kuni jõudlusprobleemideni.
- Serverivabad arvutused ei ole sugugi kasutu. Kaugel sellest. Siiski ei tohiks neid pidada otseseks asenduseks serveritele. Mõne rakenduse jaoks võivad need olla mugav tööriist.
Server on surnud, elagu server!
Nii kõlab serverivaba revolutsiooni toetajate lahingukutsung. Piisab, kui kiiresti üle vaadata viimaste aastate tööstusuudised, ja on lihtne järeldada, et traditsiooniline serverimudel on surnud ning et mõne aasta jooksul kasutame kõik serverivabu arhitektuure.
Igaühele valdkonnas on teada, ja nagu me ka oma artiklis on märkinud , ei ole see tõsi. Vaatamata paljudele artiklitele serverivaba revolutsiooni eeliste kohta , näitavad viimased uuringud Mõned lubadused serverivabade mudelite jaoks on kindlasti teoks saanud, kuid mitte kõik. Kaugel sellest.
Selles artiklis tahan arutada selle olukorra põhjuseid. Miks serverivabade mudelite paindlikkuse puudumine on endiselt takistuseks nende laiemale kasutusele, kuigi need jäävad kasulikeks konkreetsetes, selgelt määratletud oludes.
Mida lubasid serverivaba arvutuse toetajad
Mida lubasid serverita arvutuste toetajad
Enne kui räägime serverivabade arvutuste probleemidest, vaatame, mida need peaksid pakkuma. on olnud mitmeid ja mõnikord väga ambitsioonikaid lubadusi.
Kellelegi, kes ei ole mõistega tuttav, on siin lühike määratlus. Serverivabad arvutused määratlevad arhitektuuri, kus rakendused (või rakenduste osad) käivad nõudmisel keskkondades, mis tavaliselt asuvad kaugel. Lisaks on serverivabad süsteemid võimalik ka kohapeal hostida. Viimastel aastatel on vastupidavate serverivabade süsteemide loomine olnud peamine mure süsteemiadministraatoritele ja SaaS-ettevõtetele, kuna väidetavalt pakub see arhitektuur mitmeid peamisi eeliseid võrreldes traditsioonilise kliendi-serveri mudeliga:
- Serverivabad mudelid ei nõua, et kasutajad toetaksid oma operatsioonisüsteeme või isegi looksid rakendusi, mis oleksid ühilduvad teatavate OS-idega. Selle asemel loovad arendajad ühise koodi, laadivad selle serverivabasse platvormi ja jälgivad selle käivitamist.
- Serverless raamistikes ressursid arveldatakse tavaliselt minutite (või isegi sekundite) kaupa. See tähendab, et kliendid maksavad ainult selle aja eest, mil nad tõepoolest töötavad koodi. See erineb oluliselt traditsioonilisest pilve VM-ist, kus masin enamikul ajast seisab, kuid selle eest tuleb ikkagi maksta.
- Ka skaleerimisprobleem on lahendatud. Serverless raamistikes määratakse ressursid dünaamiliselt, mistõttu süsteem suudab hõlpsasti hakkama saada äkiliste nõudluse tõusudega.
Lühidalt öeldes pakuvad serverless mudelid paindlikke, odavaid ja skaleeritavaid lahendusi. Üllatav, et me ei mõelnud sellele ideele varem.
Kas see on tõeliselt uus idee?
Tegelikult ei ole see idee uus. Kontseptsioon, mis võimaldab kasutajatel maksta ainult selle aja eest, mil kood tegelikult töötab, on eksisteerinud alates selle sissetoomisest aastal 2006 ning umbes samal ajal pakkus Google App Engine väga sarnast lahendust.
Tegelikult on see, mida me nüüd nimetameme 'serverituks' mudeliks, vanem kui paljud tehnoloogiad, mida praegu nimetatakse 'natiivseteks pilvedeks', ja mis pakuvad peaaegu sama. Nagu juba mainitud, on serverivabad mudelid põhimõtteliselt lihtsalt SaaS äri mudeli jätk, mis on olemas juba mitu aastakümmet.
Samuti tasub tunnustada, et serverivaba mudel ei ole FaaS arhitektuur, kuigi nende vahel on seos. FaaS on põhimõtteliselt serverivaba arhitektuuri arvutuspõhine osa, kuid see ei esinda kogu süsteemi tervikuna.
Nii et mis on kõik need kõrvalhääled? Kuna interneti leviku kiirus arenevates riikides jätkab kiiret kasvu, suureneb samal ajal nõudlus arvutusressursside järele. Näiteks paljudes riikides, kus kiiresti kasvavad e-kaubanduse sektorid, ei ole lihtsalt rakendustele vajalikku arvutusinfrastruktuuri. Siin tulevad mängu tasulised serverivabad platvormid.
Serverivabade mudelite probleemid
Probleem on selles, et serverita mudelidel on… probleeme. Ärge saage valesti aru: ma ei ütle, et need on iseenesest halvad või et nad ei paku mõnele ettevõttele teatud oludes olulist väärtust. Kuid peamine väide "revolutsioonist" — et serverita arhitektuur asendab kiiresti traditsioonilise — ei saa kunagi teoks.
Seetõttu.
Piiratud programmeerimiskeelte tugi
Enamik serverita platvorme võimaldab käivitada ainult neid rakendusi, mis on kirjutatud teatud keeltes. See piirab nende süsteemide paindlikkust ja kohandatavust tõsiselt.
Arvatakse, et serveriteta platvormid toetavad enamikku peamisi programmeerimiskeeli. AWS Lambda ja Azure Functions pakuvad ka keskkonda rakenduste ja funktsioonide käivitamiseks, mis ei ole toetatud keeltel, kuigi see toob sageli kaasa jõudluskulud. Nii et enamikule organisatsioonidele ei ole see piirang tavaliselt kuigi oluline. Aga siin on probleem. Eeldatakse, et serveriteta mudelite üks eelis on see, et vähe tuntud, harva kasutatavad programmid võivad olla odavamad, kuna maksate ainult nende töötamise aja eest. Ja vähe tuntud, harva kasutatavad programmid on sageli kirjutatud... vähe tuntud, harva kasutatavatele programmeerimiskeeltele.
See õõnestab ühte serveriteta mudeli peamist eelist.
Tarnija sidumine
Teine probleem, mis on seotud serverivabade platvormidega või vähemalt sellega, kuidas neid praegu rakendatakse, on see, et need ei sarnane tavaliselt üksteisele operatsioonitasandil. Funktsioonide kirjutamise, kasutuselevõtu ja haldamise osas on praktiliselt puuduvad standardid. See tähendab, et funktsioonide migreerimine ühelt platvormilt teisele on äärmiselt ajamahukas.
Serverivabale mudelile ülemineku kõige keerulisem osa ei ole arvutusfunktsioonid, mis on tavaliselt lihtsalt koodijupid, vaid see, kuidas rakendused on seotud ühendatud süsteemidega, nagu objektide salvestamine, identiteedi haldamine 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 on hiljuti tekkinud ja nende töö standardimiseks ei ole aega olnud. Kuid need ei ole nii uued, nagu ma juba mainisin, ja paljud teised pilvetehnoloogiad, nagu konteinerid, on juba muutunud palju mugavamaks tänu headele standarditele, mille väljatöötamine ja laialdane kasutuselevõtt on toimunud.
Tootlikkus
Serverless platvormide arvutusvõimsust on raske mõõta, osaliselt seetõttu, et tarnijad püüavad teavet saladuses hoida. Enamik väidab, et funktsioonid kaugtöödeldud serverless platvormidel töötavad sama kiiresti nagu kohalikud serverid, välja arvatud mõned vältimatud viivituse probleemid.
Kuid eraldi faktid viitavad vastupidisele. Funktsioonid, mida ei ole varem teatud platvormil käitatud või mis on teatud aja jooksul olnud seisakas, vajavad algatamiseks aega. See on tõenäoliselt seotud sellega, et nende kood on kantud vähem ligipääsetavasse andmekandja, kuigi - nagu ka benchmarkide puhul - ei ütle enamik tarnijaid teile andmete üleviimisest.
Muidugi on mitmeid viise, kuidas sellest mööda minna. Üks neist on funktsioonide optimeerimine kõigile pilve keelte jaoks, millel teie serverless platvorm töötab, kuid see veidi kompromiteerib väidet, et need platvormid on 'paindlikud'.
Teine lähenemine seisneb kriitilistest jõudlusega programmide regulaarse käivitamise tagamises, et need püsiksid "värsked". See teine lähenemine on muidugi natuke vastuolus väitega, et serverivaba platvorm on odavam, kuna maksate ainult oma programmide tööaja eest. Pilveteenuse pakkujad on välja töötanud uusi meetodeid külmkäivituste vähendamiseks, kuid paljud neist nõuavad "ühe suurendamist" (scale to one), mis õõnestab FaaS-i algset väärtust.
Külmkäivituse probleem on osaliselt lahendatav serverivabade süsteemide ise käivitamisega, kuid see toob kaasa oma kulud ja jääb ressursside poolest hea varustatuse saanud meeskondade nišitooteks.
Te ei saa käivitada tervet rakendust
Lõpuks, võib-olla kõige olulisem põhjus, miks serverivabad arhitektuurid ei asenda traditsioonilisi mudeleid varsti: neid ei saa (tavaliselt) kasutada tervete rakenduste käitamiseks.
Täpsemalt öeldes ei ole see kulude poolest mõistlik. Teie edukas monoliit ei pruugi väärt olla muundada neljakümne funktsiooni kogumisse, millel on kaheksa väravat, nelikümmend järjekorda ja tosin andmebaasi instantsi. Sel põhjusel sobib serverless paremini uute arenduste jaoks. Praktiliselt ei saa ühtegi olemasolevat rakendust (arhitektuuri) migreerida. Te saate migreerida, kuid peate alustama nullist.
See tähendab, et enamikul juhtudel kasutatakse serverless platvorme täienduseks sisemistele serveritele, et teostada arvutusülesandeid, mis nõuavad suuri jõudlusi. See eristab neid oluliselt kahest muust pilvetehnoloogia vormist — konteineritest ja virtuaalmasinatest, mis pakuvad terviklikku lähenemist kaugtehingute teostamiseks. See illustreerib ühte raskust mikroteenustelt serverless süsteemidele üleminekul.
Muidugi ei ole see alati probleem. Võime aeg-ajalt kasutada suuri arvutusressursse ilma oma riistvara ostmata võib olla paljude organisatsioonide jaoks tõeline ja pikaajaline kasu. Kuid kui mõned rakendused on sise serverites ja teised serverivabades pilvaarhitektuurides, siis tõuseb haldamine uuele keerukuse tasemele.
Elagu revolutsioon?
Malest lähtuvalt ei ole ma serverivabade lahenduste vastu. Ausalt. Arendajad peavad lihtsalt mõistma — eriti kui nad uurivad serverivabasid mudeleid esmakordselt — et see tehnoloogia ei asenda otseselt servereid. Selle asemel tutvuge meie näpunäidete ja ressurssidega ja otsustage, kuidas seda mudelit kõige paremini rakendada.
Allikas: habr.com
