- WebAssembly i WASI na strani servera pružaju prenosivo, izolovano okruženje za izvršavanje koje može pokretati gotovo nativni kod na različitim arhitekturama bez isporuke kompletnih slika gostujućeg operativnog sistema.
- Integracija s ekosistemom kontejnera putem OCI runtime okruženja, shimova i anotacija omogućava Wasm modulima da se ponašaju kao kontejneri, a istovremeno pružaju mnogo manje slike i brže pokretanje.
- Pravi sistemi poput Apache APISIX-a i Cloudflareovog BigPineapple DNS resolvera već koriste Wasm dodatke za sigurno proširenje funkcionalnosti uz snažnu izolaciju.
- Iako je podrška najveća za Rust/C/C++, tekući rad na jezicima, GC-u, kriptografiji i alatima brzo proširuje opseg slučajeva upotrebe Wasm-a na serverskoj strani, spremnih za produkciju.
WebAssembly više nije samo onaj kul trik za pokretanje Dooma ili Photoshopa u pregledniku; tiho je postao jedna od najperspektivnijih osnova za server-side computing, izolaciju i prenosivost. Tokom posljednjih nekoliko godina, okruženja za izvršavanje, standardi i alati oko Wasm-a i WASI-ja su se razvijali toliko brzo da ih mnogi arhitekti sada vide kao ozbiljan gradivni blok za cloud-native platforme, edge computing, gateway-e, pa čak i DNS resolvere.
Ako ste ikada osjećali da je razumijevanje Wasma na strani servera komplicirano jer su koncepti raštrkani između kontejnera, POSIX-a, Kubernetesa, gateway-a i niskonivojskih okruženja za izvršavanje, niste sami. U ovom članku ćemo proći kroz širu sliku: šta je WebAssembly, zašto WASI mijenja pravila igre na serveru, kako se uspoređuje i integrira s kontejnerima i CRI-jem, kako stvarni projekti poput API gateway-a i masivnih DNS resolvera koriste Wasm u produkciji, te kako izgledaju trenutna ograničenja i budući pravci.
Od moćnog preglednika do univerzalnog niskonivojskog okruženja za izvršavanje
Web preglednik se razvio od jednostavnog preglednika dokumenata do univerzalne platforme za aplikacije, a WebAssembly je jedan od ključnih razloga zašto. Ne tako davno, velika opterećenja poput 3D igara, VR/AR-a ili napredne vizualizacije podataka zahtijevala su izvorne desktop aplikacije; danas, mnoga od ovih iskustava glatko funkcionišu unutar kartice zahvaljujući Wasmu.
Formalno, WebAssembly je format instrukcija niskog nivoa, zasnovan na steku, dizajniran kao prenosiva ciljna platforma za kompajlere, sličan po duhu asemblerskom jeziku, ali standardizovan za web i šire. Njegov binarni format predstavlja kompaktan, arhitektonski nezavisan bajtkod koji se izvršava unutar virtuelne mašine ugrađene u sve moderne pretraživače.
U praktičnom smislu, WebAssembly vam omogućava da uzmete moćne jezike poput C, C++ ili Rusta i kompajlirate ih u neutralni ciljni kod kao što je wasm32, i isporučiti mali, samostalni binarni program koji radi u sandboxu bez obzira na to da li je osnovni CPU x86, x64 ili ARM. Ova kompilacija može biti unaprijed (AOT) ili upravo na vrijeme (JIT), ovisno o okruženju za izvršavanje.
Unutar preglednika, Wasm modul radi u sandbox okruženju sa strogim ograničenjima: ne može direktno pristupiti DOM-u ili proizvoljnim sistemskim resursima i komunicira s JavaScriptom putem eksplicitnog API-ja. Zato WebAssembly nije zamjena za JavaScript, već dodatak kodu kritičnom za performanse koji JS može pozvati kada je to potrebno.
Izvršavanje u sandboxu donosi nekoliko neposrednih prednosti: snažnu izolaciju, male binarne datoteke, dobro definiran uvoz/izvoz i model koji odgovara višejezičnom razvoju gdje se mnogi jezici kompajliraju u isti prenosivi format. Vremenom, ekosistem je prerastao okvire C/C++/Rusta i uključio eksperimentalne ili djelomične ciljeve za jezike poput Go, Java, Python i drugih, čak i ako se zrelost znatno razlikuje.
Sigurnost, prenosivost i analogija sa POSIX-om
Podrazumevano, WebAssembly modul nema pristup vanjskom svijetu: on manipuliše memorijom i brojevima, a svaka interakcija sa datotekama, satovima, socketima ili umrežavanjem mora biti eksplicitno odobrena od strane hosta putem uvoza. Ovaj stav „zabranjivanja po defaultu“ jedan je od glavnih razloga zašto je Wasm atraktivan izvan preglednika.
Situacija neobično podsjeća na rani svijet Unixa, gdje su različiti sistemi nudili malo drugačije interfejse za uobičajene operacije poput datoteka ili umrežavanja. Ta fragmentacija je otežavala prenošenje aplikacija između Unix varijanti.
POSIX se na kraju pojavio kao standardni interfejs operativnog sistema kako bi programi mogli koristiti konzistentan API za komunikaciju s više Unix-sličnih kernela. Nakon što je aplikacija napisana u POSIX-u, njeno premještanje između sistema bilo je mnogo lakše, čak i ako je svaki OS imao svoje vlastite interne komponente.
WebAssembly izvan preglednika naišao je na sličan problem: pojedinačni hostovi bi izlagali ad-hoc funkcije za I/O, vrijeme ili slučajnost, ali nije postojao zajednički ugovor. Svako okruženje za izvršavanje moglo je izmisliti vlastite API-je, što je bilo odlično za eksperimente, ali užasno za prenosivost.
WASI: WebAssembly sistemski interfejs
Da bi se riješila ta fragmentacija i WebAssembly postao ozbiljna serverska opcija, zajednica je uvela WASI, WebAssembly sistemski interfejs. WASI definira standardizirani skup sistemskih API-ja na koje se Wasm moduli mogu osloniti za interakciju s datotekama, satovima, umrežavanjem i drugim osnovnim resursima na prenosiv način.
Na WASI su utjecali projekti poput CloudABI-ja i sam POSIX, ali s jačim fokusom na sigurnost zasnovanu na mogućnostima i sandboxing. Umjesto pretpostavke da proces može vidjeti cijeli datotečni sistem ili mrežni stek, WASI modul dobija precizne mogućnosti koje tačno opisuju kojim resursima može pristupiti.
Pod WASI-jem, WebAssembly modulu više nije potrebna potpuna virtuelna mašina u pregledniku; može se pokretati na laganom okruženju za izvršavanje koje implementira WASI API-je i prevodi ih na osnovni operativni sistem. To okruženje za izvršavanje može se ugraditi u aplikacije, koristiti kao CLI ili uključiti u platforme višeg nivoa.
WASI je namjerno modularan: postoji osnovni skup primitiva (često nazvanih wasi-core) za osnovne operacije poput datoteka i utičnica, te dodatne prijedloge kao što su wasi-nn za opterećenja neuronskih mreža ili proširenja specifična za domenu za IoT i blockchain. Ova modularnost omogućava različitim platformama da implementiraju samo one dijelove koji su im potrebni.
Runtime okruženja poput Wasmtime-a, Wasmer-a ili WasmEdge-a implementiraju WASI i djeluju kao most između prenosivog Wasm bajtkoda i instrukcija glavnog procesora. Oni su odgovorni za sprovođenje sandbox-a, upravljanje uvozom/izvozom i mapiranje WASI poziva na izvorne sistemske pozive na siguran način.
Zašto je WebAssembly na strani servera toliko važan
Kada imate prenosivi bajtkod, sistemski interfejs orijentisan na mogućnosti i polje optimizovanih okruženja za izvršavanje, postaje prirodno da se zapitate: može li WebAssembly postati računarski sloj opšte namjene na serverima i na rubu mreže? To je upravo vizija na koju se klade mnogi igrači u ekosistemu.
Jedna od najcitiranijih izjava na ovom području došla je od suosnivača Dockera, Solomona Hykesa, koji je poznato tvrdio da da je WASM+WASI postojao 2008. godine, Docker možda nikada ne bi bio potreban. Osnovna ideja je da Wasm na serveru može pružiti pakovanje i izolaciju slično kontejneru bez isporuke kompletnog gostujućeg operativnog sistema.
Što se tiče sigurnosti, WASI-jev standardni pristup je znatno strožiji od tradicionalnih modela procesa. Čak i ako korisnik koji pokreće Wasm modul ima pune privilegije na hostu, sam modul prima samo minimalne mogućnosti deklarirane unaprijed. Ako vaša aplikacija treba samo čitati datoteke, zlonamjerna ovisnost ne može tiho otvoriti sockete ili rekonfigurirati umrežavanje, jer te mogućnosti ne postoje sa stanovišta modula.
Sa stanovišta prenosivosti, Wasm binarne datoteke kompajlirane za ciljeve poput wasm32-wasi Može se pokretati nepromijenjeno na Linuxu, Windowsu, macOS-u i različitim CPU arhitekturama, sve dok je dostupno kompatibilno okruženje za izvršavanje. Ovo je bliže dugo obećanom "kompajliraj jednom, pokreni svugdje" nego kontejnerima, koji i dalje zahtijevaju različite slike za različite arhitekture.
Performanse su također uvjerljive: uklanjanjem cijelih gostujućih operativnih sistema i izgradnjom kompaktnog bajtkoda, Wasm opterećenja mogu postići gotovo izvornu brzinu s dramatično bržim vremenima pokretanja u odnosu na tradicionalne kontejnere. Za opterećenja osjetljiva na latenciju ili kratkotrajna, vrijeme hladnog pokretanja postaje glavni faktor razlikovanja.
Wasm protiv kontejnera: prijatelji, a ne neprijatelji
Na prvi pogled, WebAssembly na strani servera zvuči kao direktan konkurent kontejnerima: oba su načini za pakovanje koda i zavisnosti i njihovo pokretanje izolovano na hostu. Ali u praksi, odnos je više simbiotski nego suparnički.
Današnji ekosistem kontejnera vrti se oko alata poput Dockera, containerda i formata slika Open Container Initiative (OCI). Visokonivoska okruženja za izvršavanje, kao što je containerds, pružaju standardni API za upravljanje kontejnerima (pokretanje, zaustavljanje, izvršavanje, logovi), dok delegiraju posao niskog nivoa „pravim“ okruženjima za izvršavanje, kao što je runc, crun or youki.
U tom steku se obično nalazi sloj podmetača koji prevodi generičke pozive tipa containerd u specifične instrukcije koje razumije niskonivojsko okruženje za izvršavanje. Ovdje priča o WebAssembly-ju postaje zanimljiva: ako shim može predstaviti Wasm modul kao da je običan kontejner, alati višeg nivoa ne moraju znati razliku.
Projekti poput runwasi rade upravo to: oni omogućavaju containerdu da pokreće Wasm module kao da su OCI kontejneri korištenjem shima koji komunicira s Wasm runtime okruženjem kao što je WasmEdge umjesto runc. Iz perspektive containerda, to je još uvijek samo pokretanje "kontejnera"; ispod haube, Wasm modul se učitava i izvršava pomoću WASI-ja.
Ova spretnost omogućava "kontejnere bez kontejnera": sloj orkestracije, infrastruktura za evidentiranje i alati misle da rade s tradicionalnim kontejnerima, dok je stvarno opterećenje lagani Wasm binarni fajl kojem nije potreban cijeli gostujući operativni sistem. Iste komande (run, exec, logs) i ista Kubernetes mašinerija (RuntimeClass, implementacije) može se ponovo koristiti.
Ujedinjena okruženja za izvršavanje: crun, youki i OCI slike za Wasm
Iako su shimovi poput runwasija moćni, oni također kompliciraju postavljanje jer sada imate više runtime okruženja i shim binarnih datoteka za instaliranje i održavanje. Ovo postaje posebno teško u orkestriranim okruženjima kao što je Kubernetes, gdje konfiguracija tokom izvođenja nije trivijalna.
Novija okruženja niskog nivoa, kao što su crun (Crveni šešir) i youki (bazirani na Rustu) imaju drugačiji pristup: cilj im je da podrže i tradicionalne kontejnere i Wasm module direktno kao OCI runtime okruženja. Umjesto da im trebaju odvojene shim binarne datoteke, oni pregledaju anotacije na OCI slikama kako bi odlučili hoće li pokrenuti puni kontejner ili izdvojiti i izvršiti Wasm modul.
S ovim modelom, izgradnja Wasm "slike kontejnera" je jednostavna kao i kompajliranje vašeg modula za wasm32-wasi, postavljanje .wasm datoteka u minimalnoj OCI slici (često FROM scratch) i dodavanjem odgovarajuće napomene koja signalizira da se radi o Wasm opterećenju. Alat poput buildah ili Docker zatim može izgraditi i poslati ove slike kao i bilo koje druge.
Rezultat je mnogo čistiji stek gdje containerds komunicira s jednim OCI runtime okruženjem, a to runtime okruženje transparentno bira kako izvršiti svaku sliku. Za operatere, ovo smanjuje mentalne troškove; za developere, to znači da se Wasm radna opterećenja integriraju u postojeće cjevovode, registre i tokove implementacije.
Praktične prednosti nisu trivijalne: Wasm slike su obično mnogo manje od slika kontejnera, što smanjuje vrijeme prijenosa i potrebe za pohranom. Jedno ilustrativno poređenje iz VMware-ovog Wasm Labs-a pokazalo je da slika Python kontejnera ima preko 1 GB, u odnosu na otprilike 6.8 MB za sliku Python-a zasnovanu na Wasm-u - drugim riječima, razlika je za redove veličine i izuzetno je važna za IoT, rubne čvorove i okruženja s ograničenim propusnim opsegom.
Wasm na strani servera u API gateway-ima: primjer APISIX-a
API gateway-i su prirodno rješenje za WebAssembly na strani servera jer već djeluju kao programabilni posrednici gdje su latencija i izolacija kritični. Apache APISIX pruža konkretan, produkcijski primjer kako se Wasm može integrirati u takve sisteme.
Tradicionalno, APISIX je gradio svoj ekosistem dodataka oko Lua jezika, koristeći fleksibilnost OpenRestyja i NGINX-a. Lua dodaci (plugins) se pokreću direktno unutar gateway-a, što je moćno, ali izaziva neke nedoumice: dijeljeno globalno stanje, rizik da jedan dodatak koji se loše ponaša utiče na druge i sigurnosna ograničenja kada se proizvoljni skript kod izvršava u istom adresnom prostoru kao i glavni gateway.
Dodavanjem podrške za WebAssembly dodatke koji su u skladu sa proxy-wasm ABI, APISIX omogućava programerima da pišu ekstenzije u programskim jezicima višeg nivoa kao što su C++, Go i Rust, uz očuvanje snažnog sandbox-a. Specifikacija proxy-Wasm, koju je prvobitno predstavio Envoy, definira stabilan ABI za L4/L7 proxyje tako da se dodaci (plugins) mogu povezati s događajima poput zaglavlja HTTP zahtjeva, tijela, trailera i odgovora.
Ispod haube, APISIX se oslanja na wasm-nginx-module koji implementira proxy-Wasm ABI preko NGINX-a i Lua-e. Kada APISIX uđe u određenu fazu (na primjer, fazu pristupa), on poziva Lua funkcije koje, zauzvrat, pozivaju C funkcije kao što su ngx_http_wasm_on_http, koji mapiraju fazu na proxy-Wasm povratne pozive poput proxy_on_http_request_headers or proxy_on_http_response_body.
Ti povratni pozivi se zatim izvršavaju unutar Wasm VM-a, obično Wasmtime-a ili WasmEdge-a, i mogu pregledati ili mijenjati zahtjeve i odgovore unutar granica koje dozvoljava ABI. Ako se dodatak sruši ili ne radi ispravno, to se dešava unutar izolovane instance virtuelne mašine, umesto da se sruši ceo proces gateway-a.
Iz perspektive programera, izgradnja takvog dodatka može uključivati pisanje Go koda uz... proxy-wasm-go-sdk, kompajlirajući ga u .wasm datoteku pomoću TinyGo-a (jer Go-ova izvorna WASI podrška još uvijek nije potpuna), konfiguriranje APISIX-a za učitavanje tog modula, a zatim njegovo povezivanje s rutom. Nakon što je omogućen, dodatak može uraditi bilo šta, od ubrizgavanja grešaka ili prilagođene autorizacije do prepisivanja odgovora u hodu.
Wasm virtuelne mašine i uloga Wasmtime-a i WasmEdge-a
Implementacije WebAssembly-ja na strani servera u velikoj mjeri se oslanjaju na specijalizirane virtualne mašine koje mogu sigurno i efikasno izvršavati Wasm i implementirati WASI. Dva najčešće korištena su Wasmtime i WasmEdge.
Wasmtime, koji održava Bytecode Alliance, fokusira se na to da bude brzo, sigurno i ugradivo okruženje za izvršavanje WebAssembly-ja i WASI-ja. Može se koristiti kao CLI alat ili integrirati kao biblioteka u druge sisteme, a često se bira za opća radna opterećenja ili kao referentna implementacija.
WasmEdge, nasuprot tome, naglašava lagano, visokoperformansno izvršavanje za rubna i cloud-native okruženja. Optimizovan je za brzo pokretanje i malu upotrebu memorije, što ga čini odličnim izborom za mikroservise, platforme bez servera i mrežne prolaze gdje su uobičajene mnoge kratkotrajne instance.
U scenariju APISIX, wasm-nginx-module delegira izvršenje jednoj od ovih virtuelnih mašina; modul učitava kompajlirani .wasm datoteku u memoriju i izlaže funkcije hosta (na primjer, za pristup zaglavljima ili pisanje logova) u skladu s proxy-Wasm ABI-jem. Budući da VM implementira WASI, isti dodatak se, u principu, može pokretati na drugim hostovima koji poštuju isti interfejs.
BigPineapple: WebAssembly unutar Cloudflareovog 1.1.1.1 resolvera
Cloudflare je prvobitno koristio Knot Resolver s Lua-baziranim plugin modelom kako bi dodao funkcije poput DNS-a preko HTTPS-a, evidentiranja, ublažavanja napada zasnovanih na BPF-u i dijeljenja keš memorije. Ova fleksibilnost je bila odlična na početku, ali je naišla na nekoliko problema: blokiranje I/O unutar povratnih poziva moglo je zaustaviti petlju pojedinačnog događaja, korištenje keš memorije bilo je neefikasno u velikim razmjerima, a svi dodaci su dijelili jedno Lua stanje, što je izolaciju i debuggiranje činilo bolnim.
Kako je promet rastao, timu je bio potreban dizajn koji bi precizno rješavao blokirajuće zadatke, skalirao se na više jezgara i nudio bolju izolaciju između ekstenzija. Počeli su tako što su Knot Resolver omotali Rust servisom i na kraju zamijenili rekurzivnu jezgru novom asinhronom arhitekturom izgrađenom na Tokiu, koristeći Rustovu async/await sintaksu za izražavanje složenih tokova na čitljiv način.
Novi dizajn je uveo jasnu podjelu odgovornosti: serverska komponenta prima klijentske upite i pretvara ih u uniformne okvire; radni zadaci obrađuju rezoluciju; modul keša koristi ARC algoritam za zamjenu; biblioteka rekurzora upravlja logikom DNS rekurzije; provodnik upravlja odlaznim prometom prema autoritativnim serverima; a sandbox modul hostira priključna proširenja.
Unutar ovog okvira, sandbox je mjesto gdje WebAssembly dolazi do izražaja. Umjesto direktnog ugrađivanja Lua jezika unutar glavnog procesa, BigPineapple pokreće dodatke kao Wasm module koristeći Wasmer runtime. Svaki modul radi u svojoj izolovanoj instanci sa namenskom memorijom, a host izvozi skup funkcija koje moduli mogu pozivati za interakciju sa DNS porukama, metrikama i drugim resursima.
Asinhroni ulazno/izlazni promet, keširanje i odlazni promet u BigPineappleu
Arhitektura BigPineapple-a pokazuje kako asinhroni Rust i pažljivo upravljanje resursima dopunjuju WebAssembly. Na dolaznoj strani, serverska komponenta osluškuje više interfejsa i protokola (UDP, TCP, DoH, itd.), umotavajući svaku dolaznu poruku u apstraktnu reprezentaciju "okvira" sa metapodacima.
Ovi okviri se pretvaraju u asinhrone zadatke koje radnici preuzimaju iz reda čekanja, rješavajući ih istovremeno koristeći biblioteku rekurzora. Ovo izbjegava klasični problem petlje događaja gdje bi spori povratni poziv blokirao sav ostali promet.
Keš koristi dizajn adaptivnog zamjenskog keša (ARC) umjesto običnog skladišta ključ-vrijednost, prateći nedavnost i učestalost kako bi zadržao popularne unose, a istovremeno izbacio manje korisne. Ovo izbjegava ponašanje "isprazni sve kada se napuni" kod nekih ranijih pristupa i elegantnije rješava uvredljive obrasce poput nabrajanja zona.
Umjesto slijepog multicastinga unosa keša svim čvorovima u podatkovnom centru (što je ranije dovodilo do sinhronizovanog ispiranja keša i skokova latencije), BigPineapple koristi konzistentno heširanje kako bi usmjerio upite za istu domenu na podskup čvorova. Ti čvorovi implicitno dijele stanje keša opslužujući sličan promet, povećavajući omjer pogodaka i smanjujući opterećenje uzvodnih autoritativnih servera.
Na odlaznoj strani, provodni modul upravlja vezama sa uzvodnim DNS serverima, prateći metrike poput vremena povratnog putovanja, kvaliteta usluge i gubitka paketa. Uklanja duplikate istovremenih uzvodnih upita za isto pitanje, bira najbolji transport i rutu (uključujući i putem Argo Smart Routinga kada je to korisno) i inteligentno ponovo pokušava kada je to potrebno.
WebAssembly kao granica izolacije u DNS-u
BigPineappleov sistem dodataka je tipičan primjer upotrebe za Wasm na strani servera kao izolacijsku granicu oko nepouzdanog ili eksperimentalnog koda. Umjesto pokretanja dodataka u istom memorijskom prostoru kao i resolver, svaka Wasm aplikacija je zatvorena u sandboxu: može pristupiti samo vlastitoj linearnoj memoriji i svim pozivima hosta koji su eksplicitno izloženi.
Iz perspektive hosta, igra ulogu sličnu kernelu operativnog sistema u odnosu na procese: upravlja resursima, kontroliše raspoređivanje i definiše površinu sistemskih poziva. Iz perspektive modula, to je samo program s nekim uvezenim funkcijama i početnom ulaznom tačkom.
Granicu između hosta i gosta nameće WebAssembly runtime (u ovom slučaju Wasmer), koji presreće pristupe memoriji, hvata nevažeće operacije i posreduje u svim uvozima/izvozima. Host izlaže "pozive hosta" (analogno sistemskim pozivima) koje gost može koristiti za čitanje DNS poruka, generisanje logova, objavljivanje metrika ili otvaranje socketa unutar dobro definiranih ograničenja.
S druge strane, domaćin također zna za određene funkcije unutar gosta, koje se ponekad nazivaju "trampolini". Ove trampoline omogućavaju pozivanje povratnih poziva ili zatvaranja pohranjenih u memoriji gosta sa strane hosta, što je ključno za funkcije poput fazno specifičnih hook-ova (prije keša, poslije keša, prije odgovora i tako dalje).
Da bi se nosilo s asinhronim ponašanjem, platforma mapira Rustovu Future apstrakciju na pozive hosta: gostujući modul može zatražiti I/O putem poziva hosta, a host registruje waker tako da se povezani zadatak nastavlja kada se I/O završi. Ovo omogućava složenim dodacima da izvršavaju operacije bez blokiranja bez zamrzavanja glavne petlje resolvera.
Troškovi i zaobilazna rješenja za izolaciju Wasm-a
Sva ova izolacija nije besplatna; WebAssembly sa sobom nosi određene troškove kojima dizajneri platforme moraju pažljivo upravljati. Budući da gosti ne mogu direktno čitati memoriju hosta, podaci se moraju kopirati ili mapirati u regije memorije gosta, što može biti skupo za sisteme visokog protoka.
BigPineapple ublažava ovo tako što prethodno dodjeljuje velike memorijske regije u adresnom prostoru gosta i mapira dijeljenu memoriju u te praznine. Nakon što host uredi ovo mapiranje, gostujući kod može čitati dijeljene podatke bez ponovljenog kopiranja, značajno smanjujući opterećenje po zahtjevu.
Još jedan izazov je kriptografija: današnji osnovni skup instrukcija WebAssembly-ja ne uključuje hardverski ubrzane primitive za algoritme poput AES-a ili SHA-2. Projekti poput WASI-crypto imaju za cilj standardizaciju prenosivog interfejsa za kriptovalute koji može iskoristiti prednosti hardvera hosta, ali dok takvi standardi ne budu u potpunosti dostupni i široko implementirani, platforme često prebacuju posao koji je težak za kriptovalute nazad na host.
Cloudflare se suočio s ovim s Oblivious DoH (oDoH), gdje resolver treba dešifrirati upite klijenata, obraditi ih, a zatim šifrirati odgovore. Implementacija hibridnog šifriranja javnim ključem (HPKE) isključivo u Wasm-u bila bi neefikasna, pa su delegirali HPKE za hostovanje poziva i primijetili do 4 puta veća poboljšanja performansi u poređenju sa isključivo Wasm implementacijom.
Jezička podrška: jaka za Rust/C/C++, slabija za ostale
Zrelost Wasm-a na strani servera uveliko zavisi od izvornog jezika i njegovog ekosistema. Za sistemske jezike poput Rusta i C/C++, podrška je relativno solidna: alati znaju kako da ciljaju wasm32-wasi, a mnoge standardne biblioteke ili rade odmah po instalaciji ili imaju dobro održavane podložne pločice (shimove).
Za jezike višeg nivoa kao što su Java, Python ili JavaScript, slika je mješovitija. Standardne biblioteke često pretpostavljaju direktan pristup funkcijama OS-a ili JIT kompajlerima, što se ne mapira jasno na trenutna Wasm okruženja za izvršavanje. Upravljanje memorijom, refleksija, modeli niti i FFI mogu predstavljati prepreke.
Ipak, postoji veliki zamah: CPython projekat ulaže posvećene napore u izradu WebAssembly verzije s podrškom za osnovnu standardnu biblioteku, a VMware-ov Wasm Labs pruža male OCI slike koje sadrže Python interpreter kompajliran u Wasm. Ove slike su dramatično manje od tradicionalnih Python kontejnera, što pokazuje jasne prednosti čak i u ovoj ranoj fazi.
Slične inicijative postoje i za mnoge druge jezike, uključujući one popularne u umjetnoj inteligenciji i internetu stvari (IoT), s projektima poput WasmEdgea koji prilagođavaju funkcije za zaključivanje o strojnom učenju i edge-native radna opterećenja. Ekosistem povezivanja (na primjer, pokretanje Wasm modula iz Pythona putem wasmer-python) se također brzo širi.
Prednosti iz stvarnog svijeta i trenutna ograničenja
Kada kombinujete sve ove dijelove - WASI, integraciju kontejnera, API gateway-e, DNS resolvere i jezičke runtime-ove - prednosti WebAssembly-ja na strani servera postaju vrlo jasne. Manje slike ubrzavaju implementaciju i čine scenarije na rubu mreže i u IoT-u izvodljivim; gotovo nativne performanse i vremena pokretanja na nivou mikrosekunde otvaraju vrata za radna opterećenja vođena događajima i bez servera; snažno „sandbox“ okruženje omogućava sigurnije računarstvo s više zakupaca u cijelom steku.
Istovremeno, važno je ne precijeniti trenutno stanje tehnike: Wasm na strani servera je još uvijek mlad i nije univerzalna zamjena za kontejnere ili virtuelne mašine. Mnogi scenariji produkcijskog nivoa ograničeni su na jezike sa zrelom Wasm podrškom, a alati za otklanjanje grešaka, uočljivost i profiliranje performansi još uvijek sustižu korak.
Funkcije poput memorije sakupljane smećem, bogatijih modela obrade niti i prvoklasne kriptografije aktivno se razvijaju u grupama za standarde WebAssembly-ja, ali još nisu univerzalno dostupne. Ovo može otežati izvršavanje jezika koji zavise od sofisticiranih GC ili funkcija konkurentnosti.
Uprkos ovim upozorenjima, nivo investicija glavnih igrača - provajdera cloud usluga, kontejnerskih platformi, dobavljača pretraživača i infrastrukturnih kompanija - snažno ukazuje na to da će serverski Wasm i WASI nastaviti da dobijaju na značaju kao dopuna kontejnerima i kao nova osnova za sigurno, prenosivo računarstvo. Rani korisnici u oblastima kao što su mrežni pristupnici (gateway), računarstvo na rubu mreže (edge computing), DNS i sistemi dodataka (plug-in) već dokazuju da je tehnologija dovoljno robusna za zahtjevna okruženja s velikim prometom.
Posmatrajući slučajeve upotrebe sa platformi za sadržaj kompajliranih u Wasm, cloud-native gateway-e poput APISIX-a i internetskih rezolvera poput Cloudflare-ovog 1.1.1.1, teško je ignorisati koliko je brzo WebAssembly izrastao iz kurioziteta preglednika u ozbiljnog konkurenta za budućnost server-side i edge computinga, s mnogo prostora za evoluciju i sazrijevanje.
