Kompjuterizimi pa server është "një kategori shërbimesh cloud ku klienti mund të përdorë lloje të ndryshme të aftësive cloud pa pasur nevojë që klienti të sigurojë, vendosë dhe menaxhojë burime harduerike ose softuerike, përveç ofrimit të kodit të aplikacionit të klientit ose ofrimit të të dhënave të klientit. Kompjuterizimi pa server përfaqëson një formë të informatikës së virtualizuar", sipas ISO/IEC 22123-2. Kompjuterizimi pa server është një ekosistem i gjerë që përfshin ofruesin e cloud-it, funksionin si shërbim (FaaS), shërbimet e menaxhuara, mjetet, kornizat, inxhinierët, palët e interesuara dhe elementë të tjerë të ndërlidhur.
Përmbledhje
"Pa server" është një emërtim i gabuar në kuptimin që serverët përdoren ende nga ofruesit e shërbimeve cloud për të ekzekutuar kodin për zhvilluesit. Përkufizimi i informatikës pa server ka evoluar me kalimin e kohës, duke çuar në interpretime të ndryshme. Sipas Ben Kehoe, "pa server" përfaqëson një spektër dhe jo një përkufizim të ngurtë. Theksi duhet të zhvendoset nga përkufizimet e rrepta dhe teknologjitë specifike në miratimin e një mendësie pa server, duke u përqendruar në shfrytëzimin e zgjidhjeve pa server për të adresuar sfidat e biznesit.
Kompjuterizimi pa server nuk e eliminon kompleksitetin, por e zhvendos pjesën më të madhe të tij nga ekipi i operacioneve te ekipi i zhvillimit. Megjithatë, ky ndryshim nuk është absolut, pasi ekipet e operacioneve vazhdojnë të menaxhojnë aspekte të tilla si menaxhimi i identitetit dhe aksesit (IAM), rrjetëzimi, politikat e sigurisë dhe optimizimi i kostos. Përveç kësaj, ndërsa ndarja e aplikacioneve në komponentë më të imët mund të rrisë kompleksitetin e menaxhimit, marrëdhënia midis granularitetit dhe vështirësisë së menaxhimit nuk është rreptësisht lineare. Shpesh ekziston një nivel optimal i modularizimit ku përfitimet tejkalojnë kostot e shtuara të menaxhimit.
Sipas Yan Cui, teknikat pa server duhet të përdoren vetëm kur ato ndihmojnë në ofrimin e vlerës për klientin më shpejt. Dhe gjatë përdorimit, organizatat duhet të ndërmarrin hapa të vegjël dhe të ulin rrezikun gjatë rrugës.
Sfidat
Aplikacionet pa server janë të prirura ndaj gabimeve të informatikës së shpërndarë. Përveç kësaj, ato janë të prirura ndaj gabimeve të mëposhtme:
- Versionimi është i thjeshtë
- Transaksionet kompensuese funksionojnë gjithmonë
- Vëzhgueshmëria është opsionale
Monitorimi dhe debugging-u
Monitorimi dhe debugging-u i aplikacioneve pa server mund të paraqesë sfida unike për shkak të natyrës së tyre të shpërndarë, të drejtuar nga ngjarjet dhe mjediseve pronësore. Mjetet tradicionale mund të dështojnë, duke e bërë të vështirë gjurmimin e rrjedhave të ekzekutimit nëpër shërbime. Megjithatë, zgjidhjet moderne, të tilla si mjetet e gjurmimit të shpërndarë (p.sh., AWS X-Ray, Datadog), regjistrimi i centralizuar dhe platformat e vëzhgimit pa lidhje me cloud-in, po i zbusin këto sfida. Teknologjitë në zhvillim si OpenTelemetry, zbulimi i anomalive të mundësuara nga inteligjenca artificiale dhe kornizat specifike pa server po e përmirësojnë më tej dukshmërinë dhe analizën e shkaqeve rrënjësore. Ndërsa sfidat vazhdojnë, përparimet në mjetet e monitorimit dhe debugging-ut po i adresojnë vazhdimisht këto kufizime.
Siguria
Sipas OWASP, aplikacionet pa server janë të ndjeshme ndaj variacioneve të sulmeve tradicionale, kodit të pasigurt dhe disa sulmeve specifike për server (si mohimi i portofolit). Pra, rreziqet kanë ndryshuar dhe parandalimi i sulmeve kërkon një ndryshim në mentalitet.
Bllokimi i shitësit
Kompjuterizimi pa server ofrohet si një shërbim i palës së tretë. Aplikacionet dhe softuerët që funksionojnë në mjedisin pa server janë të kyçur si parazgjedhje në një shitës specifik të cloud-it. Ky problem përkeqësohet në informatikën pa server, pasi me nivelin e rritur të abstraksionit, shitësit publikë lejojnë vetëm klientët të ngarkojnë kod në një platformë FaaS pa autoritetin për të konfiguruar mjediset themelore. Më e rëndësishmja, kur merret në konsideratë një rrjedhë pune më komplekse që përfshin backend-as-a-service (BaaS), një ofertë BaaS zakonisht mund të aktivizojë vetëm në mënyrë native një ofertë FaaS nga i njëjti ofrues. Kjo e bën praktikisht të pamundur migrimin e ngarkesës së punës në informatikën pa server. Prandaj, marrja në konsideratë e mënyrës së projektimit dhe vendosjes së rrjedhave të punës pa server nga një perspektivë shumë-cloud mund ta zbusë këtë.
Informatikë me performancë të lartë
Kompjuterizimi pa server mund të mos jetë ideal për ngarkesa të caktuara pune të informatikës me performancë të lartë (HPC) për shkak të kufizimeve të burimeve që shpesh imponohen nga ofruesit e cloud-it, duke përfshirë kufizimet maksimale të memories, CPU-së dhe kohës së ekzekutimit. Për ngarkesat e punës që kërkojnë përdorim të qëndrueshëm ose të parashikueshëm të burimeve, serverët e furnizuar me shumicë ndonjëherë mund të jenë më efektivë nga ana e kostos sesa modeli "pagesë për përdorim" tipik i platformave pa server. Megjithatë, informatika pa server është gjithnjë e më e aftë të mbështesë ngarkesa specifike pune HPC, veçanërisht ato që janë shumë të paralelizueshme dhe të drejtuara nga ngjarjet, duke shfrytëzuar shkallëzueshmërinë dhe elasticitetin e saj. Përshtatshmëria e informatikës pa server për HPC vazhdon të evoluojë me përparimet në teknologjitë e cloud-it.
Anti-modelet
Anti-model i kokërrzave të rërës i referohet krijimit të komponentëve tepër të vegjël (p.sh., funksioneve) brenda një sistemi, që shpesh rezulton në rritje të kompleksitetit, mbingarkesës operative dhe joefikasitetit të performancës. Lambda pinball është një anti-model i lidhur që mund të ndodhë në arkitekturat pa server kur funksionet (p.sh., AWS Lambda, funksionet Azure) e thërrasin tepër njëri-tjetrin në zinxhirë të fragmentuar, duke çuar në vonesë, sfida të debuggingut dhe testimit, dhe vëzhgueshmëri të reduktuar. Këto anti-modele shoqërohen me formimin e një monoliti të shpërndarë.
Këto anti-modele shpesh adresohen përmes zbatimit të kufijve të qartë të domenit, të cilët bëjnë dallimin midis ndërfaqeve publike dhe atyre të publikuara. Ndërfaqet publike janë ndërfaqe teknikisht të arritshme, të tilla si metodat, klasat, pikat fundore të API-t ose shkaktarët, por ato nuk vijnë me garanci formale stabiliteti. Në të kundërt, ndërfaqet e publikuara përfshijnë një kontratë të qartë stabiliteti, duke përfshirë versionimin formal, dokumentimin e plotë, një politikë të përcaktuar të zhvlerësimit dhe shpesh mbështetje për pajtueshmërinë prapa. Ndërfaqet e publikuara mund të kërkojnë gjithashtu mirëmbajtjen e shumë versioneve njëkohësisht dhe respektimin e proceseve formale të zhvlerësimit kur futen ndryshime prishëse.
Zinxhirët e fragmentuar të thirrjeve të funksioneve shpesh vërehen në sisteme ku komponentët (funksionet) pa server bashkëveprojnë me burime të tjera në modele komplekse, ndonjëherë të përshkruara si arkitekturë spageti ose një monolit i shpërndarë. Në të kundërt, sistemet që shfaqin kufij më të qartë zakonisht i organizojnë komponentët pa server në grupe kohezive, ku ndërfaqet e brendshme publike menaxhojnë komunikimin ndërkomponentësh dhe ndërfaqet e publikuara përcaktojnë komunikimin përtej kufijve të grupit. Ky dallim nxjerr në pah ndryshimet në garancitë e stabilitetit dhe angazhimet e mirëmbajtjes, duke kontribuar në zvogëlimin e kompleksitetit të varësisë.
Për më tepër, modelet që lidhen me zinxhirin e tepërt të funksioneve pa server ndonjëherë adresohen përmes strategjive arkitekturore që theksojnë integrimet e shërbimeve vendase në vend të funksioneve individuale, një koncept i referuar si mentaliteti pa funksione. Megjithatë, kjo qasje vihet re se përfshin një kurbë më të pjerrët të të mësuarit, dhe kufizimet e integrimit mund të ndryshojnë edhe brenda të njëjtit ekosistem të shitësit të cloud-it.
Raportimi në bazat e të dhënave pa server paraqet sfida, pasi marrja e të dhënave për një shërbim raportimi mund të thyejë kontekstet e kufizuara, të zvogëlojë afatin kohor të të dhënave, ose të bëjë të dyja. Kjo vlen pavarësisht nëse të dhënat tërhiqen direkt nga bazat e të dhënave, të merren nëpërmjet HTTP-së ose të mblidhen në grupe. Mark Richards e quan këtë si anti-model raportimi i arritjes së të dhënave. Një alternativë e mundshme ndaj kësaj qasje është që bazat e të dhënave të shtyjnë në mënyrë asinkrone të dhënat e nevojshme në shërbimin e raportimit në vend që shërbimi i raportimit t'i tërheqë ato. Ndërsa kjo metodë kërkon një kontratë të veçantë midis shërbimeve dhe shërbimit të raportimit dhe mund të jetë komplekse për t'u zbatuar, ajo ndihmon në ruajtjen e konteksteve të kufizuara duke ruajtur një nivel të lartë të afatit kohor të të dhënave.
