Pse revolucioni pa server ka ngecur

Pikat kryesore

  • Ka disa vite që na premtuan se llogaritë pa server (serverless) do të hapin një epokë të re pa një OS të caktuar për ekzekutimin e aplikacioneve. Na u tha se një strukturë e tillë do të zgjidhte shumë nga problemet e shkallëzueshmërisë. Në të vërtetë, gjithçka është ndryshe.
  • Ndërsa shumë i shohin teknologjitë pa server si një ide të re, rrënjët e saj mund të ndjekin deri në vitin 2006, kur u shfaqën Zimki PaaS dhe Google App Engine — në të dyja rastet përdoret një arkitekturë pa server.
  • Ka katër arsye për të cilat revolucioni pa server është bllokuar: nga mbështetje e kufizuar për gjuhët e programimit deri te problemet me performancën.
  • Llogaritë pa server nuk janë aq të padobishme. Aspak. Megjithatë, nuk duhet t’i shohim si një zëvendësim të drejtpërdrejtë të serverëve. Për disa aplikacione, ato mund të jenë një mjet i dobishëm.

Serveri është i vdekur, të jetojë serveri!

Kështu tingëllon thirrja e adhuruesve të revolucionit pa server. Mjafton të shfletoni gazetat e industrisë të disa viteve të fundit dhe është e lehtë të arrish në përfundimin se modeli tradicional i serverëve është i vdekur dhe se pas disa vitesh të gjithë ne do të përdorim arkitektura pa server.

Siç dihet nga kushdo në industri, dhe siç e kemi theksuar gjithashtu në artikullin tonë mbi gjendjen e llogarive pa server, nuk është kështu. Pavarësisht nga numri i artikujve mbi meritat e revolucionit pa server, ai nuk ndodhi. Në të vërtetë, studimet e fundit tregojnë, se ky revolucion, ndoshta, ka bllokuar.

Disa nga premtimet për modelet pa server, padyshim, janë realizuar, por jo të gjitha. Shumë. Jo të gjitha.

Në këtë artikull, dëshiroj të shqyrtoj arsyet për këtë gjendje. Pse mungesa e fleksibilitetit të modeleve pa server vazhdon të jetë një pengesë për përhapjen e tyre më të gjerë, edhe pse ato mbeten të dobishme në rrethana shumë specifike.

Çfarë premtonin adhuruesit e llogarive pa server

Para se të kalojmë te problemet e llogarive pa server, le të shohim se çfarë duhej të ofronin. Premtimet e revolucionit pa server ishin të shumta dhe — ndonjëherë — shumë ambicioze.

Për ata që nuk janë të njohur me termin, ja një përkufizim i shkurtër. Llogaritë pa server definon një arkitekturë, në të cilën aplikacionet (ose pjesët e aplikacioneve) ekzekutohen sipas kërkesës në mjedise ekzekutimi, që zakonisht janë të hostuara në distancë. Për më tepër, sistemet pa server mund të hostohen edhe lokal. Gjatë disa viteve të fundit, krijimi i sistemeve të qëndrueshme pa server ka qenë prioriteti kryesor i administratorëve të sistemeve dhe kompanive SaaS, sepse (siç pretendohet) kjo arkitekturë ofron disa avantazhe kyçe në krahasim me modelin tradicional të klient-server:

  1. Modelet pa server nuk kërkojnë që përdoruesit të mbajnë sistemet e tyre operative ose madje të krijojnë aplikacione të pajtueshme me sisteme të caktuara operativesh. Në vend të kësaj, zhvilluesit krijojnë kod të përbashkët, e ngarkojnë atë në një platformë pa server dhe e monitorojnë ekzekutimin e tij.
  2. Burimet në kuadrot pa server zakonisht paguhen për minuta (ose madje sekonda). Kjo do të thotë se klientët paguajnë vetëm për kohën kur ata faktikisht ekzekutojnë kodin. Kjo është ndryshe shumë e favorshme nga VM tradicionale në cloud, ku makina është e papërdorur pjesën më të madhe të kohës, por ju duhet të paguani për të.
  3. Problemi i shkallëzimit gjithashtu është zgjidhur. Burimet në kuadrot pa server caktohen dinamikisht, kështu që sistemi përballon lehtësisht shpërthimet e papritura të kërkesës.

Në përmbledhje, modelet pa server ofrojnë zgjidhje fleksibile, të lira dhe të shkallëzuara. Është befasuese se si nuk e kemi menduar këtë ide më herët.

A është kjo vërtet një ide e re?

Me të vërtetë, ideja nuk është e re. Koncepti që lejon përdoruesit të paguajnë vetëm për kohën kur kodi ekzekutohet me të vërtetë, ekziston qëkur është prezantuar në kuadër të Zimki PaaS në vitin 2006 dhe rreth të njëjtës kohë Google App Engine ofroi një zgjidhje shumë të ngjashme.

Me të vërtetë, ajo që tani e quajmë modelin "pa server" është më e vjetër se shumë teknologji që sot quhen "natyra cloud", dhe që ofrojnë pothuajse të njëjtën gjë. Siç u përmend, modelet pa server në thelb janë vetëm një vazhdim i modelit të biznesit SaaS, i cili ekziston prej disa dekadash.

Është gjithashtu e rëndësishme të pranohet se modeli pa server nuk është arkitekturë FaaS, ndonëse ka një lidhje midis tyre. FaaS është, në thelb, një pjesë e orientuar ndaj llogaritjeve e arkitekturës pa server, por nuk përfaqëson të gjithë sistemin në tërësi.

Pra, përse gjithë kjo zhurmë? Po, pasi shpejtësia e depërtimit të internetit në vendet në zhvillim vazhdon të rritet me shpejtësi, po rritet njëkohësisht edhe kërkesa për burime llogaritëse. Për shembull, në shumë vende me sektorë të shpejtë të tregtisë elektronike, thjesht nuk ka një infrastrukturë llogaritëse për aplikacionet në këto platforma. Këtu hyjnë platformat pa server me pagesë.

Problemet e modeleve pa server

Sfidë është se modelet pa server kanë... probleme. Mos më kuptoni gabim: nuk po them që ato janë të këqija vetvetiu apo që nuk ofrojnë vlerë të konsiderueshme për disa kompani në disa rrethana. Por deklarata kryesore e "revolucionit" - që arkitektura pa server do të zëvendësojë shpejt tradicionale - nuk do të realizohet ndonjëherë.

Këtu është arsyeja.

Ndarje e kufizuar e gjuhëve programimi

Shumica e platformave pa server lejojnë ekzekutimin e aplikacioneve vetëm të shkruara në gjuhë të caktuara. Kjo kufizon ndjeshëm fleksibilitetin dhe adaptueshmërinë e këtyre sistemeve.

Kuptohet se platformat pa server mbështesin shumicën e gjuhëve kryesore. AWS Lambda dhe Azure Functions gjithashtu ofrojnë një mbështetje për ekzekutimin e aplikacioneve dhe funksioneve në gjuhë të papërshtatshme, megjithëse kjo shpesh lidhet me kosto në performancë. Prandaj, për shumicën e organizatave, zakonisht ky kufizim nuk ka shumë rëndësi. Por këtu është çështja. Supozohet se një nga përfitimet e modeleve pa server është se programet e panjohura, të përdorura rrallë mund të ekzekutohen më lirë, pasi paguani vetëm për kohën e tyre të ekzekutimit. Dhe programet e panjohura, të përdorura rrallë shpesh shkruhen në... gjuhë programimi të panjohura, të përdorura rrallë.

Kjo minon një nga përfitimet kryesore të modelit pa server.

Pavarësia nga shitësit

Problemi i dytë me platformat pa serverë ose, të paktën, si ato po zbatohen aktualisht, është se ato zakonisht nuk i ngjajnë njëra-tjetrës në nivel operacional. Praktikisht nuk ka standardizim në mënyrën e shkruarjes së funksioneve, deploy-imit dhe menaxhimit. Kjo do të thotë se migrimi i funksioneve nga një platformë në një tjetër merr jashtëzakonisht shumë kohë.

Pjesa më e vështirë e kalimit në modelin pa server është se nuk janë funksionet llogaritëse, të cilat zakonisht përbëjnë thjesht fragmente kodi, por mënyra si aplikacionet lidhen me sistemet e lidhura, si ruajtja e objekteve, menaxhimi i identitetit dhe radhët. Funksionet mund të transferohen, por pjesa tjetër e aplikacionit jo. Kjo është krejtësisht e kundërta me platformat e përshkruara si të lira dhe fleksibël.

Disa pretendojnë se modelet pa server janë shfaqur kohët e fundit dhe nuk ka pasur kohë për t'i standardizuar ato. Por ato nuk janë aq të reja, siç e kam përmendur më lart, dhe shumë teknologji të tjera në cloud, si kontejnerët, janë bërë tashmë shumë më të thjeshta për shkak të zhvillimit dhe shpërndarjes së standardeve të mira.

Performanca

Përformanca llogaritëse e platformat pa server është e vështirë për t'u matet, pjesërisht sepse furnizuesit përpiqen të mbajnë informacionin sekret. Shumica e tyre pretendojnë se funksionet në platformat pa server punojnë po aq shpejt sa ato në serverat lokalë, përveç disa problemeve të pashmangshme me vonesat.

Megjithatë, disa fakte tregojnë të kundërtën. Funksionet që nuk kanë funksionuar më parë në një platformë të caktuar ose nuk kanë funksionuar për një kohë të caktuar, kërkojnë njëfarë kohe për t'u inicializuar. Kjo ndoshta ka të bëjë me faktin që kodi i tyre është transferuar në ndonjë medium të dhënash më pak të aksesueshëm, megjithatë, siç ndodh zakonisht me benchmark-et, shumica e furnizuesve nuk do t'ju thonë për transferimin e të dhënave.

Sigurisht, ka disa mënyra për ta anashkaluar këtë. Njëra prej tyre është optimizimi i funksioneve për çdo gjuhë cloud, në të cilën funksionon platforma juaj pa server, por kjo e minon pak pretendimin se këto platforma janë 'fleksibile.'

Një qasje tjetër është që të sigurohet ekzekutimi i rregullt i programeve kritikë për performancën, në mënyrë që ata të mbeten "të freskët". Kjo qasje e dytë, natyrisht, paksa bie në kundërshtim me deklaratën se platformat pa server janë më ekonomike, sepse paguani vetëm për kohën e ekzekutimit të programeve tuaja. Ofruesit e облаков kanë implementuar mënyra të reja për të reduktuar fillimet e ftohta, por shumë prej tyre kërkojnë "shkallëzimin në një" (scale to one), që dëmton vlerën fillestare të FaaS.

Problemi i "fillimit të ftohtë" mund të zgjidhet pjesërisht duke nisur sistemet pa server me burime të veta, por kjo vjen me kosto të veta dhe mbetet një opsion niçë për ekipet që kanë burime të mira.

Nuk mund të nisni aplikacione të plota

Në fund, ndoshta arsyeja më e rëndësishme pse arkitekturat pa server nuk do të zëvendësojnë modelet tradicionale në afat të shkurtër: ato (zakonisht) nuk i lejojnë ekzekutimin e aplikacioneve të plota.

Më saktësisht, kjo nuk është e përshtatshme nga pikëpamja kostos. Monoliti juaj i suksesshëm nuk vlen të shndërrohet në një grup prej katër dhjetë funksionesh të lidhura me tetë porta, katërzero radhë dhe një duzinë kopjesh të DB-së. Për këtë arsye, pa server është më e përshtatshme për zhvillime të reja. Praktikisht asnjë aplikacion ekzistues (arkitekturë) nuk mund të migrohet. Mund të emigroni, por do të duhet të filloni nga e para.

Kjo do të thotë se në shumicën dërrmuese të rasteve, platformat pa server përdoren si një shtesë për serverët e brendshëm për të kryer detyra që kërkojnë llogaritje të mëdha. Kjo ndan shumë në mënyrë të thellë nga dy format e tjera të teknologjisë së облаков, kontejnerëve dhe makinave virtuale, të cilat ofrojnë një mënyrë të plotë për të kryer llogaritje të largëta. Kjo ilustron një nga vështirësitë e kalimit nga mikroshërbimet në sistemet pa server.

Sigurisht, kjo nuk është gjithmonë një problem. Mundësia për të përdorur herë pas here burime të mëdha kompjuterike, pa blerë harduerin tuaj, mund të sjellë përfitime të vërteta dhe afatgjata për shumë organizata. Por nëse disa aplikacione janë në serverat e brendshëm dhe të tjerat në arkitektura të cloud pa server, menaxhimi përshkon një nivel të ri kompleksiteti.

Jetë revolucionare?

Pavarësisht nga këto ankesa, unë nuk kam ndonjë problem me zgjidhjet pa server. Fjalë për fjalë. Thjesht zhvilluesit duhet të kuptojnë - veçanërisht nëse ata janë duke eksploruar modelet pa server për herë të parë - se kjo teknologji nuk është një zëvendësim i drejtpërdrejtë për serverët. Në vend të kësaj, hidhni një vështrim në këshillat dhe burimet tona për krijimin e aplikacioneve pa server dhe vendosni se si ta aplikoni më së miri këtë model.

Burimi: habr.com

Blini hosting të besueshëm për faqe interneti me mbrojtje nga DDoS, serverë VPS VDS 🔥 Blini hosting të besueshëm për faqe interneti me mbrojtje nga DDoS, serverë VPS VDS | ProHoster