Ključne točke
- Že nekaj let nam obljubljajo, da bodo brezstrežni izračuni (serverless) odprli novo dobo brez konkretnega operacijskega sistema za izvajanje aplikacij. Povedali so nam, da bo taka struktura rešila številne težave s skalabilnostjo. V resnici pa je vse drugače.
- Čeprav mnogi brezstrežno tehnologijo obravnavajo kot novo idejo, segajo njene korenine vse do leta 2006, ko sta se pojavila Zimki PaaS in Google App Engine — v obeh primerih se uporablja brezstrežna arhitektura.
- Obstajajo štiri razlogi, zakaj je brezstrežna revolucija obtičala: od omejene podpore programskim jezikom do težav s težo.
- Brezstrežni izračuni niso tako neuporabni. Vsekakor ne. Vendar jih ne smemo obravnavati kot neposredno zamenjavo strežnikov. Za nekatere aplikacije so lahko priročno orodje.
Strežnik je mrtev, naj živi strežnik!
Tako se sliši bojni klic privržencev brezstrežne revolucije. Dovolj je, da površno preletite industrijske medije v zadnjih nekaj letih, in zlahka lahko pridete do zaključka, da je tradicionalni strežni model mrtev ter da bomo čez nekaj let vsi uporabljali brezstrežne arhitekture.
Kot že ve vsak v industriji, in kot smo tudi sami navedli v našem članku o , temu ni tako. Kljub številnim članom o prednostih , ta se še ni zgodila. V resnici , da je ta revolucija morda obtičala.
Nekatera od obljub za brezstrežne modele so bila nedvomno uresničena, vendar ne vse. Daleč od vsega.
V tem članku želim raziskati razloge za takšno stanje. Zakaj je pomanjkanje prilagodljivosti brezstrežnih modelov še vedno ovira za njihovo širšo uporabo, čeprav ostajajo koristni v določenih, jasno opredeljenih okoliščinah.
Kaj so obljubljali privrženci brezstrežnih izračunov
Preden se podamo k težavam brezstrežnih izračunov, si poglejmo, kaj so morali zagotoviti. so bile številne in - občasno - zelo ambiciozne.
Za tiste, ki niso seznanjeni z izrazom, je tukaj kratka opredelitev. Brezstrežna računalništvo opredeljuje arhitekturo, v kateri se aplikacije (ali deli aplikacij) izvajajo na zahtevo v izvajalnih okoljih, ki so običajno gostovana na daljavo. Poleg tega se brezstrežni sistemi lahko gostijo tudi lokalno. V zadnjih nekaj letih je bila krepitev brezstrežnih sistemov glavna skrb sistemskih administratorjev in podjetij SaaS, saj ta arhitektura ponuja več ključnih prednosti v primerjavi s "tradicionalnim" modelom odjemalec-strežnik:
- Brezstrežni modeli ne zahtevajo, da uporabniki upravljajo lastne operacijske sisteme ali celo razvijajo aplikacije, združljive z določenimi operacijskimi sistemi. Namesto tega razvijalci ustvarijo skupno kodo, jo naložijo v brezstrežno platformo in opazujejo njeno izvajanje.
- Viri v brezstrežnih okvirih so običajno zaračunani na minuto (ali celo sekundo). To pomeni, da stranke plačajo le za čas, ko se koda dejansko izvaja. To se ugodno razlikuje od tradicionalne oblačne VM, kjer je stroj večino časa neaktiven, vendar za njega še vedno plačate.
- Problem razširljivosti je bil prav tako rešen. Viri v brezstrežnih okvirih so dodeljeni dinamično, kar pomeni, da sistem zlahka obvlada nenadne skoke povpraševanja.
Skratka, brezstrežni modeli zagotavljajo fleksibilne, poceni in razširljive rešitve. Presenetljivo je, da te ideje prej nismo kdaj koli razmislili.
Je to resnova nova ideja?
Dejansko ideja ni nova. Koncept, ki uporabnikom omogoča plačilo samo za čas, ko se koda dejansko izvaja, obstaja od takrat, ko je bil uveden v okviru leta 2006, in približno ob istem času je Google App Engine ponudil zelo podoben način rešitve.
Dejansko je to, kar zdaj imenujemo "brezstrežni" model, starejše od mnogih tehnologij, ki jih danes imenujemo "nativno oblačne", in ki zagotavljajo skoraj enako. Kot smo že omenili, so brezstrežni modeli v bistvu samo nadaljevanje poslovnega modela SaaS, ki obstaja že več desetletij.
Tudi priznati moramo, da brezstrežna arhitektura ni arhitektura FaaS, čeprav sta si blizu. FaaS je v bistvu del brezstrežne arhitekture, osredotočen na računanje, vendar ne predstavlja celotnega sistema.
Kaj torej vse to pompa? No, ker se hitrost penetracije interneta v državah v razvoju hitro povečuje, tudi povpraševanje po računskih virih narašča. Na primer, v mnogih državah z hitro rastočimi sektorji elektronskega poslovanja preprosto ni računalniške infrastrukture za aplikacije na teh platformah. Tu nastopijo plačane brezstrežne platforme.
Težave brezstrežnih modelov
Težava je v tem, da brezstrežni modeli imajo... težave. Ne razumite me narobe: ne trdim, da so slabi sami po sebi ali da ne zagotavljajo pomembne vrednosti za nekatere podjetja v določenih okoliščinah. Vendar pa glavno trditev «revolucije» — da bo brezstrežna arhitektura hitro nadomestila tradicionalno — nikoli ne bo mogoče uresničiti.
Tukaj je, zakaj.
Omejena podpora programskim jeziku
Večina brezstrežnih platform omogoča zagon le tistih aplikacij, ki so napisane v določenih jezikih. To resno omejuje prilagodljivost in adaptabilnost teh sistemov.
Menijo, da brezstrežne platforme podpirajo večino glavnih jezikov. AWS Lambda in Azure Functions prav tako nudita ovojnico za zagon aplikacij in funkcij v nepodprtih jezikih, čeprav je to pogosto povezano z izgubo zmogljivosti. Tako za večino organizacij običajno ta omejitev nima velikega pomena. Toda tu je glavna težava. Predvideva se, da je ena od prednosti brezstrežnih modelov v tem, da se lahko manj znani, redko uporabljani programi uporabljajo ceneje, saj plačate le za čas njihovega izvajanja. Ti manj znani, redko uporabljani programi so pogosto napisani v… manj znanih, redko uporabljenih programskih jezikih.
To undermines one of the key advantages of the serverless model.
Povezanost z dobaviteljem
Druga težava pri brezservisnih platformah ali vsaj pri tem, kako so danes implementirane, je, da se običajno na operativni ravni precej razlikujejo. Standardizacija pri pisanju funkcij, uvajanju in upravljanju praktično ne obstaja. To pomeni, da migracija funkcij z ene platforme na drugo traja izredno dolgo.
Najtežji del prehoda na brezservisni model niso računske funkcije, ki običajno predstavljajo le koščke kode, temveč način, kako so aplikacije povezane s povezanimi sistemi, kot so shranjevanje objektov, upravljanje identitete in čakalne vrste. Funkcije je mogoče premakniti, vendar preostale dele aplikacije ni. To je popolna nasprotje obljubljenim cenovno ugodnim in prilagodljivim platformam.
Nekateri trdijo, da so brezservisni modeli nastali nedavno in da ni bilo časa za standardizacijo njihovega delovanja. Vendar niso tako novi, kot sem že omenil, in mnoge druge tehnologije v oblaku, kot so kontejnerji, so že postale veliko bolj uporabne zahvaljujoč razvoju in široki uporabi dobrih standardov.
Performansa
Računsko zmogljivost brezservisnih platform je težko izmeriti, deloma zato, ker prodajalci želijo zadržati informacije v skrivnosti. Večina trdi, da funkcije na oddaljenih, brezservisnih platformah delujejo tako hitro, kot na domačih strežnikih, razen nekaterih neizogibnih težav s zakasnitvijo.
Vendar pa nekateri dejstva pričajo o nasprotnem. Funkcije, ki prej niso bile izvajane na določeni platformi ali niso bile izvajane že nekaj časa, potrebujejo določen čas za inicializacijo. Verjetno je to posledica tega, da je bil njihov koda prenesena na manj dostopen nosilec podatkov, čeprav – kot pri merjenju učinkovitosti – večina prodajalcev ne bo povedala o prenosu podatkov.
Seveda obstajajo številni načini, kako to obiti. Eden od njih je optimizacija funkcij za kateri koli oblačni jezik, na katerem deluje vaša brezservisna platforma, vendar to nekoliko spodkopava trditev, da so te platforme 'prilagodljive'.
Drugi pristop je redno izvajati kritične programe za učinkovitos, da ostanejo "sveži". Ta drugi pristop je seveda nekoliko v nasprotju z dejstvom, da so brezstrešne platforme bolj ekonomične, saj plačate le za čas delovanja vaših programov. Oblačni ponudniki so uvedli nove načine za zmanjšanje hladnih zagonov, vendar mnogi zahtevajo "proširitev na enega" (scale to one), kar podvaja prvotno vrednost FaaS.
Težavo "hladnega zagona" je mogoče delno rešiti z zagon brezstrešnih sistemov z lastnimi sredstvi, vendar to prinaša lastne stroške in ostaja nišna možnost za ekipe z dobrimi viri.
Ne morete zagnati celotnih aplikacij
Nazadnje, morda najpomembnejši razlog, zakaj brezstrešne arhitekture v bližnji prihodnosti ne bodo nadomestile tradicionalnih modelov: na njih (ponavadi) ni mogoče zagnati celotnih aplikacij.
Z drugimi besedami, to ni smiselno z vidika stroškov. Vaš uspešen monolit verjetno ni vreden pretvorbe v niz štiridesetih funkcij, povezanih z osmimi viri, štiridesetimi čakalnimi vrstami in ducatom primerkov DB. Iz tega razloga je brezstrešno bolje prilagojeno za nove razvojne projekte. Skoraj nobene obstoječe aplikacije (arhitekture) ni mogoče preseliti. Lahko migrirate, vendar se boste morali začeti znova.
To pomeni, da se v prevladujočem številu primerov brezstrešne platforme uporabljajo kot dopolnilo k internim strežnikom za izvajanje nalog, ki zahtevajo obsežne izračune. To jih zelo razlikuje od dveh drugih oblik oblačnih tehnologij - vsebniki in virtualne naprave, ki ponujajo celostni način izvajanja oddaljenih izračunov. To ponazarja eno od težav pri prehodu z mikroservisov na brezstrešne sisteme.
Seveda, to ni vedno težava. Sposobnost občasne uporabe ogromnih računalniških virov, brez nakupa lastne opreme, lahko prinese resnične in dolgoročne koristi za mnoge organizacije. Ampak, če se nekatere aplikacije nahajajo na notranjih strežnikih, medtem ko so druge na brezstrežni oblačni arhitekturi, postane upravljanje na novi ravni zapletenosti.
Naj živi revolucija?
Kljub vsem tem pritožbam, nimam nič proti brezstrežnim rešitvam. Odkrito. Razvijalci morajo le razumeti – še posebej, če prvič raziskujejo brezstrežne modele – da ta tehnologija ni neposredna zamenjava strežnikov. Namesto tega se seznanite z našimi nasveti in viri o in se odločite, kako najbolje uporabiti ta model.
Izvor: habr.com
