Pikat kryesore
- Prej disa vitesh, na është premtuar se kompjuteri pa server do të sjellë një epokë të re pa një OS të veçantë për ekzekutimin e aplikacioneve. Na u tha se kjo strukturë do të zgjidhte shumë probleme të shkallëzueshmërisë. Në fakt, gjithçka është ndryshe.
- Ndërsa shumë e shohin pa server si një ide të re, rrënjët e saj mund të gjurmohen në vitin 2006 me ardhjen e Zimki PaaS dhe Google App Engine, të cilat të dyja përdorin arkitekturë pa server.
- Ka katër arsye pse revolucioni pa server ka ngecur, duke filluar nga mbështetja e kufizuar e gjuhës së programimit deri te problemet e performancës.
- Llogaritja pa server nuk është edhe aq e padobishme. Aspak. Megjithatë, ato nuk duhet të konsiderohen si një zëvendësim i drejtpërdrejtë për serverët. Për disa aplikacione ato mund të jenë një mjet i dobishëm.
Serveri ka vdekur, rroftë serveri!
Kjo është thirrja e betejës së revolucionit pa server. Vetëm një vështrim i shpejtë në shtypin e industrisë gjatë viteve të fundit dhe është e lehtë të arrihet në përfundimin se modeli tradicional i serverit ka vdekur dhe se brenda pak vitesh ne të gjithë do të përdorim arkitekturat pa server.
Siç e di kushdo në industri, dhe siç theksuam edhe në artikullin tonë mbi , Kjo eshte e gabuar. Pavarësisht shumë artikujve për meritat , nuk u zhvillua kurrë. Në fakt, se ky revolucion mund të ketë arritur në një rrugë pa krye.
Disa nga premtimet e modeleve pa server sigurisht që janë realizuar, por jo të gjitha. Jo te gjithe.
Në këtë artikull dua të shikoj arsyet e kësaj gjendje. Pse mungesa e fleksibilitetit të modeleve pa server është ende një pengesë për miratimin e tyre më të gjerë, edhe pse ato mbeten të dobishme në rrethana specifike dhe të mirëpërcaktuara.
Çfarë premtuan njohësit e informatikës pa server
Përpara se të futemi në sfidat e informatikës pa server, le të shohim se çfarë duhej të ofronte. ishin të shumtë dhe - nganjëherë - shumë ambicioz.
Për ata që nuk janë të njohur me termin, këtu është një përkufizim i shpejtë. Llogaritja pa server përcakton një arkitekturë në të cilën aplikacionet (ose pjesë të aplikacioneve) ekzekutohen sipas kërkesës në mjediset e kohës së funksionimit që zakonisht priten nga distanca. Përveç kësaj, sistemet pa server mund të strehohen në shtëpi. Ndërtimi i sistemeve elastike pa server ka qenë një shqetësim i madh për administratorët e sistemit dhe kompanitë SaaS gjatë viteve të fundit, pasi (pretendohet) kjo arkitekturë ofron disa avantazhe kryesore mbi modelin "tradicional" klient-server:
- Modelet pa server nuk kërkojnë që përdoruesit të mirëmbajnë sistemet e tyre operative apo edhe të krijojnë aplikacione të pajtueshme me OS specifike. Në vend të kësaj, zhvilluesit krijojnë kodin e përbashkët, e ngarkojnë atë në një platformë pa server dhe e shikojnë atë të ekzekutohet.
- Burimet në kornizat pa server zakonisht faturohen në minutë (ose edhe në sekondë). Kjo do të thotë që klientët paguajnë vetëm për kohën kur ekzekutojnë kodin. Kjo krahasohet në mënyrë të favorshme me një VM tradicionale cloud, ku makina është në punë shumicën e kohës, por ju duhet të paguani për të.
- Problemi i shkallëzueshmërisë u zgjidh gjithashtu. Burimet në kornizat pa server caktohen në mënyrë dinamike në mënyrë që sistemi të mund të përballojë lehtësisht rritjet e papritura të kërkesës.
Me pak fjalë, modelet pa server ofrojnë zgjidhje fleksibël, me kosto të ulët dhe të shkallëzueshme. Është për t'u habitur që ne nuk e kemi menduar më herët këtë ide.
A është vërtet kjo një ide e re?
Në fakt, ideja nuk është e re. Koncepti i lejimit të përdoruesve të paguajnë vetëm për kohën kur kodi po funksionon në të vërtetë ka ekzistuar që kur u prezantua nga ai në 2006, dhe në të njëjtën kohë Google App Engine ofroi një zgjidhje shumë të ngjashme.
Në fakt, ai që ne tani e quajmë modeli "pa server" është më i vjetër se shumë teknologji që tani quhen "native në renë" që ofrojnë pothuajse të njëjtën gjë. Siç u përmend, modelet pa server janë në thelb vetëm një zgjatje e modelit të biznesit SaaS që ka qenë rreth e rrotull për dekada.
Vlen gjithashtu të pranohet se pa server nuk është një arkitekturë FaaS, megjithëse ekziston një lidhje midis të dyjave. FaaS është në thelb pjesa kompjuterike-centrike e një arkitekture pa server, por nuk përfaqëson të gjithë sistemin.
Pra, për çfarë bëhet fjalë për këtë bujë? Epo, ndërsa normat e depërtimit të internetit vazhdojnë të rriten në qiell në vendet në zhvillim, kërkesa për burime kompjuterike po rritet gjithashtu në të njëjtën kohë. Për shembull, shumë vende me sektorë të tregtisë elektronike në rritje të shpejtë thjesht nuk kanë infrastrukturën kompjuterike për aplikime në këto platforma. Këtu hyjnë platformat me pagesë pa server.
Probleme me modelet pa server
Kapja është se modelet pa server kanë... probleme. Mos më keqkuptoni: nuk po them se ato janë të këqija në vetvete ose nuk u japin vlerë të konsiderueshme disa kompanive në disa rrethana. Por pretendimi kryesor i "revolucionit" - që arkitektura pa server do të zëvendësojë shpejt arkitekturën tradicionale - nuk materializohet kurrë.
Kjo është arsyeja pse.
Mbështetje e kufizuar për gjuhët e programimit
Shumica e platformave pa server ju lejojnë të ekzekutoni vetëm aplikacione që janë të shkruara në gjuhë të caktuara. Kjo kufizon seriozisht fleksibilitetin dhe përshtatshmërinë e këtyre sistemeve.
Platformat pa server konsiderohen se mbështesin shumicën e gjuhëve kryesore. Funksionet AWS Lambda dhe Azure ofrojnë gjithashtu një mbështjellës për ekzekutimin e aplikacioneve dhe funksioneve në gjuhët e pambështetura, megjithëse kjo shpesh vjen me një kosto të performancës. Pra, për shumicën e organizatave ky kufizim zakonisht nuk është një punë e madhe. Por këtu është gjëja. Një nga përfitimet e modeleve pa server supozohet të jetë se programet pak të njohura, të përdorura rrallë mund të përdoren më lirë, sepse ju paguani vetëm për kohën që ato funksionojnë. Dhe programet pak të njohura, të përdorura rrallë, shpesh shkruhen në... gjuhë programimi pak të njohura, të përdorura rrallë.
Kjo minon një nga përfitimet kryesore të modelit pa server.
Lidhja e shitësit
Problemi i dytë me platformat pa server, ose të paktën mënyra se si ato zbatohen aktualisht, është se ato zakonisht nuk janë të ngjashme me njëra-tjetrën në nivel operacional. Nuk ka praktikisht asnjë standardizim për sa i përket funksioneve të shkrimit, vendosjes dhe menaxhimit. Kjo do të thotë që migrimi i veçorive nga një platformë në tjetrën kërkon shumë kohë.
Pjesa më e vështirë e kalimit në një model pa server nuk janë funksionet llogaritëse, të cilat zakonisht janë vetëm copa kodi, por mënyra se si aplikacionet komunikojnë me sistemet e lidhura si ruajtja e objekteve, menaxhimi i identitetit dhe radhët. Funksionet mund të zhvendosen, por pjesa tjetër e aplikacionit nuk mundet. Kjo është saktësisht e kundërta e platformave të lira dhe fleksibël që premtohen.
Disa argumentojnë se modelet pa server janë të reja dhe nuk ka pasur kohë për të standardizuar mënyrën se si funksionojnë. Por ato nuk janë aq të reja, siç theksova më lart, dhe shumë teknologji të tjera cloud, si kontejnerët, tashmë janë bërë shumë më të përdorshme falë zhvillimit dhe miratimit të gjerë të standardeve të mira.
prodhimtari
Performanca kompjuterike e platformave pa server është e vështirë të matet, pjesërisht sepse shitësit priren ta mbajnë informacionin privat. Shumica argumentojnë se funksionet në platformat e largëta, pa server funksionojnë po aq shpejt sa ato në serverët e brendshëm, me përjashtim të disa çështjeve të vonesës së pashmangshme.
Megjithatë, faktet individuale tregojnë të kundërtën. Veçoritë që nuk janë ekzekutuar më parë në një platformë të caktuar ose nuk janë ekzekutuar për ca kohë do të kërkojnë pak kohë për t'u inicializuar. Kjo ka të ngjarë për shkak të faktit se kodi i tyre është transferuar në një medium ruajtjeje më pak të aksesueshme, megjithëse - si me standardet - shumica e shitësve nuk do t'ju tregojnë për migrimin e të dhënave.
Sigurisht, ka disa mënyra rreth kësaj. Njëra është të optimizoni veçoritë për cilëndo gjuhë cloud në të cilën funksionon platforma juaj pa server, por kjo disi minon pretendimin se këto platforma janë "të shkathëta".
Një qasje tjetër është të sigurohet që programet kritike për produktivitetin të ekzekutohen rregullisht për t'i mbajtur ato të freskëta. Kjo qasje e dytë, natyrisht, është paksa në kundërshtim me pretendimin se platformat pa server janë më kosto-efektive sepse ju paguani vetëm për kohën kur programet tuaja po funksionojnë. Ofruesit e reve kompjuterike kanë prezantuar mënyra të reja për të reduktuar fillimet e ftohta, por shumë prej tyre kërkojnë "shkallë në një", gjë që minon vlerën origjinale të FaaS.
Problemi i fillimit të ftohtë mund të zgjidhet pjesërisht duke ekzekutuar sisteme pa server në shtëpi, por kjo vjen me kostot e veta dhe mbetet një opsion i veçantë për ekipet me burime të mira.
Nuk mund të ekzekutosh aplikacione të tëra
Së fundi, ndoshta arsyeja më e rëndësishme pse arkitekturat pa server nuk do të zëvendësojnë modelet tradicionale së shpejti: ato (zakonisht) nuk mund të ekzekutojnë aplikacione të tëra.
Më saktësisht, është jopraktike nga pikëpamja e kostos. Monoliti juaj i suksesshëm ndoshta nuk duhet të shndërrohet në një grup prej katër duzina funksionesh të lidhura nga tetë porta, dyzet radhë dhe një duzinë shembujsh të bazës së të dhënave. Për këtë arsye, pa server është më i përshtatshëm për zhvillime të reja. Pothuajse asnjë aplikacion (arkitekturë) ekzistues nuk mund të migrohet. Mund të migroni, por duhet të filloni nga e para.
Kjo do të thotë që në shumicën dërrmuese të rasteve, platformat pa server përdoren si një plotësues i serverëve të fundit për të kryer detyra intensive llogaritëse. Kjo i bën ata shumë të ndryshëm nga dy format e tjera të teknologjive cloud - kontejnerët dhe makinat virtuale - të cilat ofrojnë një mënyrë holistike për të kryer llogaritjen në distancë. Kjo ilustron një nga sfidat e kalimit nga mikroshërbimet në pa server.
Sigurisht, ky nuk është gjithmonë një problem. Aftësia për të shfrytëzuar periodikisht burime masive kompjuterike pa pasur nevojë të blini harduerin tuaj mund të sjellë përfitime reale dhe të qëndrueshme për shumë organizata. Por kur disa aplikacione qëndrojnë në serverë të brendshëm dhe të tjerë në arkitekturë cloud pa server, menaxhimi merr një nivel të ri kompleksiteti.
Rroftë revolucioni?
Pavarësisht nga të gjitha këto ankesa, unë nuk jam kundër zgjidhjeve pa server në vetvete. Sinqerisht. Zhvilluesit thjesht duhet të kuptojnë – veçanërisht nëse po eksplorojnë pa server për herë të parë – se teknologjia nuk është një zëvendësim i drejtpërdrejtë për serverët. Në vend të kësaj, shikoni këshillat dhe burimet tona për dhe vendosni se si të aplikoni më mirë modelin.
Burimi: www.habr.com