Pagrindiniai klausimai
- Jau keletą metų mums žadama, kad kompiuterija be serverio (be serverio) atvers naują erą be konkrečios OS programoms paleisti. Mums buvo pasakyta, kad tokia struktūra išspręstų daug mastelio problemų. Tiesą sakant, viskas yra kitaip.
- Nors daugelis mano, kad technologija be serverio yra nauja idėja, jos šaknis galima atsekti 2006 m. su Zimki PaaS ir Google App Engine, kurie abu naudoja be serverio architektūrą.
- Yra keturios priežastys, kodėl revoliucija be serverių sustojo: nuo riboto programavimo kalbos palaikymo iki našumo problemų.
- Kompiuterija be serverio nėra tokia nenaudinga. Toli nuo to. Tačiau jie neturėtų būti vertinami kaip tiesioginis serverių pakaitalas. Kai kurioms programoms jie gali būti patogus įrankis.
Serveris miręs, tegyvuoja serveris!
Tai yra revoliucijos be serverių šalininkų kovos šauksmas. Greito žvilgsnio į pramonės spaudą per pastaruosius kelerius metus pakanka padaryti išvadą, kad tradicinis serverio modelis yra miręs ir kad po kelerių metų mes visi naudosime architektūrą be serverių.
Kaip žino visi pramonės atstovai ir kaip mes taip pat nurodėme savo straipsnyje apie , Tai yra blogai. Nepaisant daugybės straipsnių apie nuopelnus , tai niekada neįvyko. Faktiškai, kad ši revoliucija galėjo patekti į aklavietę.
Kai kurie pažadai dėl modelių be serverių tikrai išsipildė, bet ne visi. Ne visi.
Šiame straipsnyje noriu apsvarstyti šios būklės priežastis. Kodėl be serverių modelių lankstumo trūkumas vis dar trukdo juos plačiau pritaikyti, nors jie išlieka naudingi konkrečiomis, tiksliai apibrėžtomis aplinkybėmis.
Ką žadėjo kompiuterių be serverių adeptai
Prieš pereidami prie kompiuterių be serverių problemų, pažiūrėkime, ką jie turėjo pateikti. buvo daug ir kartais labai ambicingų.
Tiems, kurie nėra susipažinę su terminu, pateikiame trumpą apibrėžimą. Skaičiavimas be serverio apibrėžia architektūrą, kurioje programos (arba programų dalys) veikia pagal poreikį vykdymo aplinkose, kurios paprastai yra priglobtos nuotoliniu būdu. Be to, gali būti talpinamos sistemos be serverių. Per pastaruosius kelerius metus sistemų administratoriams ir SaaS kompanijoms rūpėjo kurti patikimas be serverių sistemas, nes (teigiama) ši architektūra turi keletą pagrindinių pranašumų, palyginti su „tradiciniu“ kliento/serverio modeliu:
- Modeliuose be serverių nereikia, kad naudotojai prižiūrėtų savo operacines sistemas ar net kurtų su konkrečiomis operacinėmis sistemomis suderinamų programų. Vietoj to, kūrėjai sukuria bendrinamą kodą, įkelia jį į platformą be serverio ir stebi, kaip jis veikia.
- Ištekliai be serverių sistemose paprastai apmokestinami minutėmis (ar net sekundėmis). Tai reiškia, kad klientai moka tik už laiką, kurį iš tikrųjų vykdo kodą. Tai yra palankiai palyginama su tradicine debesies VM, kur mašina didžiąją laiko dalį neveikia, bet už tai reikia mokėti.
- Taip pat buvo išspręsta mastelio problema. Ištekliai be serverių sistemose priskiriami dinamiškai, kad sistema galėtų lengvai susidoroti su staigiais paklausos šuoliais.
Trumpai tariant, modeliai be serverių suteikia lanksčius, nebrangius, keičiamo dydžio sprendimus. Nustebau, kad anksčiau nepagalvojome apie šią idėją.
Ar tai tikrai nauja idėja?
Tiesą sakant, idėja nėra nauja. Sąvoka, leidžianti vartotojams mokėti tik už kodo faktinio veikimo laiką, egzistuoja nuo tada, kai jis buvo pristatytas pagal 2006 m. ir maždaug tuo pačiu metu „Google App Engine“ sugalvojo labai panašų sprendimą.
Tiesą sakant, tai, ką dabar vadiname „be serverio“ modeliu, yra senesnis nei daugelis technologijų, dabar vadinamų „natyvinėmis debesimis“, kurios užtikrina beveik tą patį. Kaip minėta, modeliai be serverių iš esmės yra tik dešimtmečius gyvuojančio SaaS verslo modelio išplėtimas.
Taip pat verta pripažinti, kad be serverio modelis nėra FaaS architektūra, nors tarp jų yra ryšys. FaaS iš esmės yra į skaičiavimus orientuota architektūros be serverio dalis, tačiau ji neatspindi visos sistemos.
Tai kam tas ažiotažas? Besivystančiose šalyse sparčiai didėjant interneto skverbties greičiui, didėja ir kompiuterinių išteklių paklausa. Pavyzdžiui, daugelis šalių, kuriose sparčiai auga elektroninės prekybos sektoriai, tiesiog neturi kompiuterinės infrastruktūros, skirtos šių platformų programoms. Čia atsiranda mokamos be serverio platformos.
Problemos su modeliais be serverių
Bėda ta, kad modeliai be serverių turi... problemų. Nesupraskite manęs neteisingai: nesakau, kad jie patys savaime yra blogi arba tam tikromis aplinkybėmis kai kurioms įmonėms nesuteikia didelės vertės. Tačiau pagrindinis „revoliucijos“ teiginys – kad architektūra be serverių greitai pakeis tradicinę – niekada neišsipildo.
Štai kodėl.
Ribotas programavimo kalbų palaikymas
Dauguma be serverių naudojamų platformų leidžia paleisti tik tam tikromis kalbomis parašytas programas. Tai labai apriboja šių sistemų lankstumą ir pritaikomumą.
Manoma, kad platformos be serverių palaiko daugumą pagrindinių kalbų. „AWS Lambda“ ir „Azure Functions“ taip pat suteikia paketą, skirtą programoms ir funkcijoms vykdyti nepalaikomomis kalbomis, nors tai dažnai kainuoja našumui. Taigi daugumai organizacijų šis apribojimas paprastai nėra didelis dalykas. Bet štai kas. Vienas iš be serverių modelių pranašumų yra tas, kad neaiškios, retai naudojamos programos gali būti naudojamos pigiau, nes mokama tik už jų veikimo laiką. O neaiškios, retai naudojamos programos dažnai rašomos... neaiškiomis, retai naudojamomis programavimo kalbomis.
Tai kenkia vienam iš pagrindinių modelio be serverio pranašumų.
Susiejimas su pardavėju
Antra problema, susijusi su platformomis be serverių arba bent jau šiuo metu jų įdiegimo būdu, yra ta, kad jos paprastai nėra panašios veikimo lygmeniu. Rašymo funkcijų, diegimo ir valdymo standartizavimo praktiškai nėra. Tai reiškia, kad funkcijų perkėlimas iš vienos platformos į kitą užima itin daug laiko.
Sunkiausia dalis pereinant prie modelio be serverio yra ne skaičiavimo funkcijos, kurios dažniausiai yra tik kodo fragmentai, bet tai, kaip programos bendrauja su prijungtomis sistemomis, tokiomis kaip objektų saugykla, tapatybės valdymas ir eilės. Funkcijas galima perkelti, bet likusios programos dalies – ne. Tai visiškai priešinga žadėtoms pigioms ir lanksčioms platformoms.
Kai kurie teigia, kad modeliai be serverių yra nauji ir nebuvo laiko standartizuoti jų veikimo. Tačiau jie nėra tokie nauji, kaip minėjau aukščiau, ir daugelis kitų debesų technologijų, tokių kaip konteineriai, jau tapo daug patogesnės dėl gerų standartų kūrimo ir plačiai pritaikymo.
Našumas
Be serverių platformų skaičiavimo našumą sunku išmatuoti, iš dalies todėl, kad pardavėjai linkę laikyti informaciją paslaptyje. Dauguma teigia, kad nuotolinių, be serverių platformų funkcijos veikia taip pat greitai, kaip ir vidiniuose serveriuose, išskyrus keletą neišvengiamų delsos problemų.
Tačiau kai kurie įrodymai rodo priešingai. Funkcijos, kurios anksčiau neveikė konkrečioje platformoje arba neveikė kurį laiką, užtrunka šiek tiek laiko. Tikriausiai taip yra dėl to, kad jų kodas buvo perkeltas į kokią nors mažiau prieinamą laikmeną, nors, kaip ir etalonų atveju, dauguma pardavėjų jums nepasakys apie duomenų perkėlimą.
Žinoma, yra keletas būdų, kaip tai apeiti. Vienas iš jų yra optimizuoti funkcijas bet kokiai debesų kalbai, kurioje veikia jūsų platforma be serverio, tačiau tai šiek tiek paneigia teiginį, kad šios platformos yra „judrios“.
Kitas būdas – užtikrinti, kad našumui svarbios programos būtų vykdomos reguliariai, kad jos būtų „šviežios“. Šis antrasis metodas, žinoma, šiek tiek prieštarauja teiginiui, kad platformos be serverių yra ekonomiškesnės, nes mokate tik už programų veikimo laiką. Debesų paslaugų teikėjai pristatė naujus būdus, kaip sumažinti šaltojo užvedimo dažnį, tačiau daugeliui jų reikalingas „mastas iki vieno“ (mastas iki vieno), o tai kenkia pradinei FaaS vertei.
Šaltojo užvedimo problemą iš dalies galima išspręsti naudojant vidines sistemas be serverių, tačiau tai kainuoja savo lėšomis ir išlieka nišiniu gerai išteklius turinčių komandų pasirinkimu.
Negalite paleisti visų programų
Galiausiai, bene svarbiausia priežastis, kodėl architektūros be serverių artimiausiu metu nepakeis tradicinių modelių, yra ta, kad jie (paprastai) negali paleisti visų programų.
Tiksliau, tai nepraktiška sąnaudų požiūriu. Jūsų sėkmingas monolitas tikriausiai neturėtų būti paverstas keturių dešimčių funkcijų rinkiniu, susietu aštuoniais šliuzais, keturiasdešimt eilių ir keliolika duomenų bazės egzempliorių. Dėl šios priežasties be serverio geriau tinka naujiems pokyčiams. Praktiškai jokios esamos programos (architektūros) negalima perkelti. Galite migruoti, bet turite pradėti nuo nulio.
Tai reiškia, kad daugeliu atvejų platformos be serverių naudojamos kaip galinių serverių papildymas, norint atlikti daug skaičiavimo reikalaujančias užduotis. Tai labai skiriasi nuo kitų dviejų debesų kompiuterijos formų, konteinerių ir virtualių mašinų, kurios siūlo holistinį nuotolinio skaičiavimo būdą. Tai iliustruoja vieną iš iššūkių, susijusių su perėjimu nuo mikropaslaugų prie sistemų be serverių.
Žinoma, tai ne visada yra problema. Galimybė periodiškai naudoti didžiulius skaičiavimo išteklius neperkant savo aparatinės įrangos gali atnešti realios ir ilgalaikės naudos daugeliui organizacijų. Tačiau jei kai kurios programos yra vidiniuose serveriuose, o kitos – debesų architektūrose be serverių, tada valdymas pereina į naują sudėtingumo lygį.
Tegyvuoja revoliucija?
Nepaisant visų šių skundų, aš neprieštarauju sprendimams be serverių per se. Sąžiningai. Tiesiog kūrėjai turi suprasti – ypač jei jie pirmą kartą tyrinėja modelius be serverių – kad ši technologija nėra tiesioginis serverių pakaitalas. Vietoj to peržiūrėkite mūsų patarimus ir išteklius ir nuspręsti, kaip geriausiai pritaikyti šį modelį.
Šaltinis: www.habr.com