WebAssembly pe partea de server și WASI: următorul nivel de calcul

Acasă » Python » WebAssembly pe partea de server și WASI: următorul nivel de calcul

WebAssembly nu mai este doar acel truc interesant pentru a rula Doom sau Photoshop în browser; a devenit discret una dintre cele mai promițătoare fundații pentru server-side computing, izolare și portabilitate. În ultimii ani, runtime-urile, standardele și instrumentele din jurul Wasm și WASI au evoluat atât de rapid încât mulți arhitecți îl văd acum ca o componentă importantă pentru platformele cloud-native, edge computing, gateway-uri și chiar resolvere DNS.

Dacă ați simțit vreodată că înțelegerea WASM pe partea de server este complicată, deoarece conceptele sunt împrăștiate între containere, POSIX, Kubernetes, gateway-uri și runtime-uri de nivel scăzut, nu sunteți singuri. În acest articol vom trece în revistă imaginea de ansamblu: ce este WebAssembly, de ce WASI schimbă jocul pe server, cum se compară și se integrează cu containerele și CRI, cum proiectele reale, precum gateway-urile API și rezolverele DNS masive, utilizează WASM în producție și cum arată limitările actuale și direcțiile viitoare.

De la o putere a browserului la un runtime universal de nivel scăzut

Browserul web a evoluat de la un simplu vizualizator de documente la o platformă universală pentru aplicații, iar WebAssembly este unul dintre motivele principale pentru acest lucru. Nu cu mult timp în urmă, sarcinile de lucru grele, cum ar fi jocurile 3D, VR/AR sau vizualizarea avansată a datelor, necesitau aplicații desktop native; astăzi, multe dintre aceste experiențe rulează fără probleme într-o singură filă datorită Wasm.

Formal, WebAssembly este un format de instrucțiuni de nivel scăzut, bazat pe stivă, conceput ca o țintă portabilă pentru compilatoare, similar ca spirit cu un limbaj de asamblare, dar standardizat pentru web și nu numai. Formatul său binar reprezintă un bytecode compact, independent de arhitectură, care se execută în interiorul unei mașini virtuale încorporate în toate browserele moderne.

În termeni practici, WebAssembly vă permite să luați limbaje puternice precum C, C++ sau Rust și să le compilați într-o țintă neutră, cum ar fi wasm32și să livreze un fișier binar minuscul, autonom, care rulează într-un sandbox, indiferent dacă procesorul subiacent este x86, x64 sau ARM. Această compilare poate fi în avans (AOT) sau just-in-time (JIT), în funcție de timpul de execuție.

În browser, modulul Wasm rulează într-un mediu sandbox cu limite stricte: nu poate accesa direct DOM-ul sau resursele arbitrare ale sistemului și comunică cu JavaScript printr-o API explicită. De aceea, WebAssembly nu este un înlocuitor drop-in pentru JavaScript, ci mai degrabă un companion pentru codul critic pentru performanță pe care JS îl poate apela atunci când este nevoie.

Execuția într-un sandbox aduce mai multe beneficii imediate: izolare puternică, fișiere binare mici, importuri/exporturi bine definite și un model care se potrivește dezvoltării poliglote, unde multe limbaje se compilează în același format portabil. În timp, ecosistemul a crescut dincolo de C/C++/Rust pentru a include ținte experimentale sau parțiale pentru limbaje precum Go, Java, Python și altele, chiar dacă maturitatea variază mult.

Securitate, portabilitate și analogia POSIX

În mod implicit, un modul WebAssembly nu are acces la lumea exterioară: manipulează memoria și numerele, iar orice interacțiune cu fișiere, ceasuri, socket-uri sau rețele trebuie să fie permisă explicit de gazdă prin importuri. Această postură de „refuzare implicită” este unul dintre principalele motive pentru care Wasm este atractiv în afara browserului.

Situația amintește în mod ciudat de lumea Unix timpurie, unde diferite sisteme ofereau interfețe ușor diferite pentru operațiuni comune, cum ar fi fișierele sau crearea de rețele. Această fragmentare făcea dificilă portarea aplicațiilor între variantele Unix.

POSIX a apărut în cele din urmă ca o interfață standard pentru sisteme de operare, astfel încât programele să poată utiliza o API consistentă pentru a comunica cu mai multe kerneluri de tip Unix. Odată ce o aplicație era scrisă în POSIX, mutarea ei între sisteme era mult mai ușoară, chiar dacă fiecare sistem de operare avea propriile componente interne.

WebAssembly în afara browserului s-a confruntat cu o problemă similară: gazdele individuale expuneau funcții ad-hoc pentru I/O, timp sau aleatoriu, dar nu exista un contract comun. Fiecare runtime își putea inventa propriile API-uri, ceea ce era excelent pentru experimente, dar teribil pentru portabilitate.

WASI: Interfața sistemului WebAssembly

Pentru a remedia această fragmentare și a face din WebAssembly o opțiune serioasă pe partea de server, comunitatea a introdus WASI, Interfața de Sistem WebAssembly. WASI definește un set standardizat de API-uri de tip sistem pe care modulele Wasm se pot baza pentru a interacționa cu fișiere, ceasuri, rețele și alte resurse de bază într-un mod portabil.

WASI a fost influențat de proiecte precum CloudABI și de POSIX în sine, dar cu un accent mai puternic pe securitatea bazată pe capabilități și sandboxing. În loc să presupună că un proces poate vedea întregul sistem de fișiere sau stiva de rețea, un modul WASI obține capabilități precise care descriu exact ce resurse poate accesa.

În cadrul WASI, un modul WebAssembly nu mai are nevoie de o mașină virtuală completă pentru browser; acesta poate rula pe un runtime ușor care implementează API-urile WASI și le traduce în sistemul de operare subiacent. Runtime-ul respectiv poate fi încorporat în aplicații, utilizat ca o interfață de comandă (CLI) sau conectat la platforme de nivel superior.

WASI este intenționat modular: există un set de bază de primitive (adesea numite wasi-core) pentru operațiuni de bază precum fișiere și socketuri și propuneri suplimentare, cum ar fi wasi-nn pentru sarcini de lucru ale rețelelor neuronale sau extensii specifice domeniului pentru IoT și blockchain. Această modularitate permite diferitelor platforme să implementeze doar piesele de care au nevoie.

Runtime-uri precum Wasmtime, Wasmer sau WasmEdge implementează WASI și acționează ca o punte între bytecode-ul portabil Wasm și instrucțiunile procesorului gazdă. Acestea sunt responsabile pentru aplicarea sandbox-ului, organizarea importurilor/exporturilor și maparea apelurilor WASI pe apelurile de sistem native într-un mod sigur.

De ce este WebAssembly pe partea de server atât de important

Odată ce aveți un bytecode portabil, o interfață de sistem orientată spre capabilități și un câmp de runtime-uri optimizate, devine firesc să ne întrebăm: poate WebAssembly să devină un strat de calcul de uz general pe servere și la marginea rețelei? Aceasta este exact viziunea pe care mizează mulți jucători din ecosistem.

Una dintre cele mai citate afirmații în acest domeniu a venit de la cofondatorul Docker, Solomon Hykes, care a afirmat faimoasa afirmație că, dacă WASM+WASI ar fi existat în 2008, Docker poate nu ar fi fost niciodată necesar. Ideea centrală este că WASM pe server poate oferi împachetare și izolare de tip container fără a livra un sistem de operare guest complet.

În ceea ce privește securitatea, postura implicită a WASI este semnificativ mai strictă decât modelele tradiționale de procese. Chiar dacă un utilizator care rulează un modul Wasm are privilegii complete asupra gazdei, modulul în sine primește doar capabilitățile minime declarate inițial. Dacă aplicația dvs. trebuie doar să citească fișiere, o dependență rău intenționată nu poate deschide discret socket-uri sau reconfigura rețeaua, deoarece aceste capabilități nu există din punctul de vedere al modulului.

Din punct de vedere al portabilității, binarele Wasm au fost compilate pentru ținte precum wasm32-wasi poate rula neschimbat pe Linux, Windows, macOS și diferite arhitecturi de procesor, atâta timp cât este disponibil un runtime compatibil. Acest lucru este mai aproape de promisiunea de mult timp „compilare o dată, rulare peste tot” decât containerele, care necesită în continuare imagini diferite pentru arhitecturi diferite.

Performanța este, de asemenea, convingătoare: prin eliminarea completă a sistemelor de operare guest și construirea pentru un bytecode compact, sarcinile de lucru Wasm pot atinge o viteză aproape nativă, cu timpi de pornire mult mai rapizi decât containerele tradiționale. Pentru sarcinile de lucru sensibile la latență sau de scurtă durată, timpul de pornire la rece devine un factor major de diferențiere.

Wasm vs. containere: prieteni, nu dușmani

La prima vedere, WebAssembly pe server pare a fi un concurent direct al containerelor: ambele sunt modalități de a împacheta codul și dependențele și de a le rula izolat pe o gazdă. Dar, în practică, relația este mai degrabă simbiotică decât adversă.

Ecosistemul de containere de astăzi se învârte în jurul unor instrumente precum Docker, containerd și formatul de imagine Open Container Initiative (OCI). Runtime-urile de nivel înalt, cum ar fi containerd, expun o API standard pentru gestionarea containerelor (execuție, închidere, executare, jurnale), delegând în același timp munca de nivel scăzut către runtime-uri „reale”, cum ar fi runc, crun or youki.

În acea stivă, există de obicei un strat shim care traduce apelurile generice containerd în instrucțiuni specifice înțelese de runtime-ul de nivel scăzut. Aici devine interesantă povestea WebAssembly: dacă un shim poate prezenta un modul Wasm ca și cum ar fi un container normal, instrumentele de nivel superior nu trebuie să știe diferența.

Proiecte precum runwasi fac exact asta: permit containerd să pornească modulele Wasm ca și cum ar fi containere OCI, utilizând un shim care comunică cu un runtime Wasm, cum ar fi WasmEdge, în loc de runc. Din perspectiva containerd, acesta abia începe un „container”; în interior, un modul Wasm este încărcat și executat cu WASI.

Această slăbiciune permite „containere fără containere”: stratul de orchestrare, infrastructura de jurnalizare și instrumentele cred că au de-a face cu containere tradiționale, în timp ce sarcina de lucru reală este un fișier binar Wasm ușor, care nu necesită un sistem de operare guest complet. Aceleași comenzi (run, exec, logs) și aceleași mașini Kubernetes (RuntimeClass, implementări) pot fi reutilizate.

Runtime-uri unificate: imagini crun, youki și OCI pentru Wasm

Deși shim-urile precum runwasi sunt puternice, ele complică și configurarea, deoarece acum aveți mai multe runtime-uri și fișiere binare shim de instalat și întreținut. Acest lucru devine deosebit de dificil în medii orchestrate, cum ar fi Kubernetes, unde configurarea runtime-ului nu este trivială.

Timpi de execuție de nivel scăzut mai noi, cum ar fi crun (Red Hat) și youki (bazate pe Rust) adoptă o abordare diferită: își propun să ofere suport atât containerelor tradiționale, cât și modulelor Wasm direct ca runtime-uri OCI. În loc să aibă nevoie de binare shim separate, acestea inspectează adnotările de pe imaginile OCI pentru a decide dacă să pornească un container complet sau să extragă și să execute un modul Wasm.

Cu acest model, construirea unei „imagini de container” Wasm este la fel de simplă ca compilarea modulului pentru wasm32-wasi, plasând .wasm fișier într-o imagine OCI minimală (adesea FROM scratch) și adăugând adnotarea corectă pentru a semnala că este vorba de o sarcină de lucru Wasm. Instrumente de genul buildah sau Docker poate apoi construi și distribui aceste imagini ca pe oricare alta.

Rezultatul este o stivă mult mai curată, în care containerd comunică cu un singur runtime OCI, iar acel runtime alege în mod transparent cum să execute fiecare imagine. Pentru operatori, acest lucru reduce efortul mental; pentru dezvoltatori, înseamnă că sarcinile de lucru Wasm se integrează în conductele, registrele și fluxurile de implementare existente.

Beneficiile practice nu sunt nesemnificative: imaginile Wasm sunt de obicei mult mai mici decât imaginile containerelor, ceea ce reduce timpii de transfer și nevoile de stocare. O comparație ilustrativă din Wasm Labs de la VMware a plasat o imagine de container Python la peste 1 GB, față de aproximativ 6.8 MB pentru o imagine Python bazată pe Wasm - cu alte cuvinte, o diferență de ordinul mărimii care contează enorm pentru IoT, nodurile de margine și mediile cu lățime de bandă limitată.

WASM pe server în gateway-urile API: exemplul APISIX

Gateway-urile API sunt o alegere naturală pentru WebAssembly pe partea de server, deoarece acționează deja ca intermediari programabili acolo unde latența și izolarea sunt critice. Apache APISIX oferă un exemplu concret, de nivel de producție, despre cum Wasm poate fi integrat în astfel de sisteme.

În mod tradițional, APISIX și-a construit ecosistemul de plugin-uri în jurul Lua, valorificând flexibilitatea OpenResty și NGINX. Plugin-urile Lua rulează direct în cadrul gateway-ului, ceea ce este puternic, dar ridică unele probleme: starea globală partajată, riscul ca un plugin cu comportament greșit să le afecteze pe celelalte și limitările de securitate atunci când codul de script arbitrar se execută în același spațiu de adrese ca gateway-ul principal.

Prin adăugarea suportului pentru plugin-urile WebAssembly care sunt conforme cu proxy-wasm ABI, APISIX permite dezvoltatorilor să scrie extensii în limbaje de nivel superior precum C++, Go și Rust, păstrând în același timp un sandboxing puternic. Specificația proxy-Wasm, introdusă inițial de Envoy, definește un ABI stabil pentru proxy-uri L4/L7, astfel încât plugin-urile să se poată conecta la evenimente precum anteturile, corpurile, trailerele și răspunsurile cererilor HTTP.

Sub capotă, APISIX se bazează pe o wasm-nginx-module care implementează proxy-Wasm ABI peste NGINX și Lua. Când APISIX intră într-o anumită fază (de exemplu, faza de acces), acesta apelează funcții Lua care, la rândul lor, invocă funcții C, cum ar fi ngx_http_wasm_on_http, care mapează faza la apeluri inverse proxy-Wasm, cum ar fi proxy_on_http_request_headers or proxy_on_http_response_body.

Aceste apeluri inverse sunt apoi executate în interiorul unei mașini virtuale Wasm, de obicei Wasmtime sau WasmEdge, și pot inspecta sau modifica cererile și răspunsurile în limitele permise de ABI. Dacă un plugin se blochează sau se comportă defectuos, o face în interiorul unei instanțe de mașină virtuală izolată, în loc să întrerupă întregul proces gateway.

Din perspectiva unui dezvoltator, construirea unui astfel de plugin ar putea implica scrierea de cod Go pentru proxy-wasm-go-sdk, compilându-l într-un .wasm fișier cu TinyGo (deoarece suportul nativ WASI al Go este încă incomplet), configurarea APISIX pentru a încărca acel modul și apoi atașarea acestuia la o rută. Odată activat, pluginul poate face orice, de la injectarea de erori sau autentificare personalizată până la rescrierea răspunsurilor din mers.

Mașinile virtuale Wasm și rolul Wasmtime și WasmEdge

Implementările WebAssembly pe server se bazează în mare măsură pe mașini virtuale specializate care pot executa Wasm și implementa WASI în mod sigur și eficient. Două dintre cele mai utilizate sunt Wasmtime și WasmEdge.

Wasmtime, administrat de Bytecode Alliance, se concentrează pe a fi un runtime rapid, sigur și integrabil pentru WebAssembly și WASI. Poate fi utilizat ca instrument CLI sau integrat ca bibliotecă în alte sisteme și este adesea ales pentru sarcini de lucru de uz general sau ca implementare de referință.

WasmEdge, prin contrast, pune accent pe execuție ușoară și de înaltă performanță pentru medii edge și cloud-native. Este optimizat pentru pornire rapidă și utilizare redusă a memoriei, ceea ce îl face potrivit pentru microservicii, platforme serverless și gateway-uri unde sunt comune multe instanțe de scurtă durată.

În scenariul APISIX, wasm-nginx-module deleagă execuția către una dintre aceste mașini virtuale; modulul încarcă fișierul compilat .wasm fișier în memorie și expune funcțiile gazdă (de exemplu, pentru a accesa anteturile sau a scrie jurnale) conform ABI-ului proxy-Wasm. Deoarece mașina virtuală implementează WASI, același plugin poate, în principiu, să ruleze pe alte gazde care respectă aceeași interfață.

BigPineapple: WebAssembly în cadrul rezolverului Cloudflare 1.1.1.1

Inițial, Cloudflare a folosit Knot Resolver cu un model de plugin bazat pe Lua pentru a adăuga funcții precum DNS prin HTTPS, înregistrare în jurnal, atenuarea atacurilor bazate pe BPF și partajarea memoriei cache. Această flexibilitate a fost excelentă la început, dar s-a confruntat cu mai multe probleme: blocarea I/O în interiorul apelurilor inverse putea bloca bucla de evenimente unice, utilizarea memoriei cache era ineficientă la scară largă, iar toate pluginurile aveau aceeași stare Lua în comun, ceea ce făcea izolarea și depanarea dificile.

Pe măsură ce traficul a crescut, echipa avea nevoie de un design care să gestioneze sarcinile de blocare în mod curat, să fie scalabil pe mai multe nuclee și să ofere o izolare mai bună între extensii. Au început prin a încapsula Knot Resolver cu un serviciu Rust și, în cele din urmă, au înlocuit nucleul recursiv cu o nouă arhitectură asincronă construită pe Tokio, utilizând sintaxa async/await a Rust pentru a exprima fluxuri complexe într-un mod lizibil.

Noul design a introdus o separare clară a responsabilităților: o componentă de server primește interogările clienților și le transformă în cadre uniforme; sarcinile worker se ocupă de rezoluție; un modul cache folosește un algoritm de înlocuire în stil ARC; o bibliotecă de recursori gestionează logica de recursiune DNS; un conductor gestionează traficul de ieșire către servere autoritare; iar un modul sandbox găzduiește extensii conectabile.

În acest cadru, intervine WebAssembly în sandbox. În loc să integreze Lua direct în procesul principal, BigPineapple rulează plugin-uri ca module Wasm folosind runtime-ul Wasmer. Fiecare modul rulează în propria instanță izolată cu memorie dedicată, iar gazda exportă un set de funcții pe care modulele le pot apela pentru a interacționa cu mesaje DNS, metrici și alte resurse.

I/O asincron, memorare în cache și trafic de ieșire în BigPineapple

Arhitectura BigPineapple demonstrează cum soluțiile asincrone Rust și gestionarea atentă a resurselor completează WebAssembly. Pe partea de intrare, o componentă a serverului ascultă pe mai multe interfețe și protocoale (UDP, TCP, DoH etc.), încadrând fiecare mesaj primit într-o reprezentare abstractă de tip „cadru” cu metadate.

Aceste cadre sunt transformate în sarcini asincrone pe care lucrătorii le preiau dintr-o coadă, rezolvându-le concomitent folosind biblioteca de recursori. Acest lucru evită problema clasică a buclei de evenimente, în care o apelare inversă lentă ar bloca tot restul traficului.

Memoria cache folosește un design adaptiv de memorie cache de înlocuire (ARC) în loc de un simplu stocator cheie-valoare, urmărind recența și frecvența pentru a păstra intrările populare în timp ce le elimină pe cele mai puțin utile. Acest lucru evită comportamentul de „golire a tuturor intrărilor când sunt pline” din unele abordări anterioare și gestionează mai elegant modelele abuzive, cum ar fi enumerarea zonelor.

În loc să transmită orbește intrări din cache către toate nodurile dintr-un centru de date (ceea ce anterior ducea la goliri sincronizate ale cache-ului și vârfuri de latență), BigPineapple folosește hashing consistent pentru a direcționa interogările pentru același domeniu către un subset de noduri. Aceste noduri partajează implicit starea cache-ului, deservind trafic similar, crescând ratele de accesare și reducând încărcarea pe serverele autoritative din amonte.

Pe partea de ieșire, un modul conductor gestionează conexiunile la serverele DNS din amonte, urmărind indicatori precum timpul de dus-întors, calitatea serviciului și pierderea de pachete. Acesta deduplică interogările simultane din amonte pentru aceeași întrebare, alege cel mai bun transport și rută (inclusiv prin Argo Smart Routing atunci când este benefic) și reîncearcă inteligent atunci când este necesar.

WebAssembly ca limită de izolare în DNS

Sistemul de plugin-uri al BigPineapple este un caz de utilizare tipic pentru Wasm pe server, ca o graniță de izolare în jurul codului neîncrezător sau experimental. În loc să ruleze plugin-uri în același spațiu de memorie ca și resolver-ul, fiecare aplicație Wasm este protejată prin sandbox: poate accesa doar propria memorie liniară, iar orice apeluri gazdă sunt expuse explicit.

Din perspectiva gazdei, joacă un rol similar cu kernelul unui sistem de operare în raport cu procesele: gestionează resursele, controlează planificarea și definește suprafața de apelare a sistemului. Din perspectiva modulului, este doar un program cu câteva funcții importate și un punct de intrare.

Limita gazdă/guest este impusă de runtime-ul WebAssembly (Wasmer în acest caz), care interceptează accesele la memorie, captează operațiunile nevalide și mediază toate importurile/exporturile. Gazda expune „apeluri gazdă” (analoage apelurilor de sistem) pe care guest-ul le poate folosi pentru a citi mesaje DNS, a emite jurnale, a publica metrici sau a deschide socketuri în limite bine definite.

Pe de altă parte, gazda cunoaște și anumite funcții din interiorul guestului, uneori denumite „trambuline”. Aceste trambuline permit invocarea unor apeluri inverse sau închideri stocate în memoria guestului din partea gazdei, ceea ce este crucial pentru caracteristici precum hook-urile specifice fazei (înainte de cache, după cache, înainte de răspuns și așa mai departe).

Pentru a gestiona comportamentul asincron, platforma mapează abstractizarea Future a lui Rust pe apelurile gazdă: un modul guest poate solicita I/O printr-un apel gazdă, iar gazda înregistrează un waker, astfel încât sarcina asociată să fie reluată la finalizarea I/O. Acest lucru permite pluginurilor complexe să efectueze operațiuni neblocante fără a îngheța bucla principală de resolver.

Costuri și soluții alternative pentru izolarea Wasm

Toată această izolare nu este gratuită; WebAssembly implică o anumită suprasarcină pe care proiectanții platformei trebuie să o gestioneze cu atenție. Deoarece oaspeții nu pot citi direct memoria gazdei, datele trebuie copiate sau mapate în regiuni de memorie pentru oaspeți, ceea ce poate fi costisitor pentru sistemele de mare randament.

BigPineapple atenuează acest lucru prin prealocarea unor regiuni mari de memorie în spațiul de adrese al oaspetelui și maparea memoriei partajate în aceste goluri. Odată ce gazda aranjează această mapare, codul oaspetelui poate citi datele partajate fără copiere repetată, reducând semnificativ costurile suplimentare per solicitare.

O altă provocare este criptografia: setul de instrucțiuni WebAssembly de bază actual nu include primitive accelerate hardware pentru algoritmi precum AES sau SHA-2. Proiecte precum WASI-crypto își propun să standardizeze o interfață portabilă pentru criptomonede care poate profita de hardware-ul gazdă, dar până când astfel de standarde vor fi pe deplin disponibile și implementate pe scară largă, platformele descarcă adesea munca crypto-grea înapoi către gazdă.

Cloudflare s-a confruntat cu această problemă cu Oblivious DoH (oDoH), unde un resolver trebuie să decripteze interogările clientului, să le proceseze și apoi să cripteze răspunsurile. Implementarea criptării hibride cu cheie publică (HPKE) exclusiv în Wasm ar fi fost ineficientă, așa că au delegat HPKE pentru a găzdui apeluri și au observat îmbunătățiri de performanță de până la 4 ori în comparație cu o implementare exclusivă în Wasm.

Suport lingvistic: puternic pentru Rust/C/C++, mai rudimentar pentru altele

Maturitatea WASM pe server depinde în mare măsură de limbajul sursă și de ecosistemul său. Pentru limbaje de sistem precum Rust și C/C++, suportul este relativ solid: lanțurile de instrumente știu cum să vizeze wasm32-wasi...și multe biblioteci standard fie funcționează direct din cutie, fie au șaibe bine întreținute.

Pentru limbaje de nivel superior, cum ar fi Java, Python sau JavaScript, situația este mai mixtă. Bibliotecile standard presupun adesea acces direct la caracteristicile sistemului de operare sau la compilatoarele JIT, care nu se mapează corect pe runtime-urile Wasm actuale. Gestionarea memoriei, reflecția, modelele de threading și FFI pot prezenta obstacole.

Cu toate acestea, există un impuls semnificativ: proiectul CPython depune eforturi dedicate pentru a produce o versiune WebAssembly cu suport pentru biblioteca standard de bază, iar Wasm Labs de la VMware oferă imagini OCI minuscule care conțin interpretorul Python compilat în Wasm. Aceste imagini sunt mult mai mici decât containerele Python tradiționale, prezentând beneficii clare chiar și în această etapă incipientă.

Inițiative similare există pentru multe alte limbaje de lucru, inclusiv cele populare în inteligență artificială și IoT, cu proiecte precum WasmEdge care adaptează funcții pentru inferența învățării automate și sarcini de lucru native la margine. Ecosistemul de legături (de exemplu, rularea modulelor Wasm din Python prin intermediul wasmer-python) se extinde și ea rapid.

Beneficii în lumea reală și limitări actuale

Când combinați toate aceste elemente - WASI, integrarea containerelor, gateway-urile API, resolverele DNS și runtime-urile de limbaj - avantajele WebAssembly pe server devin foarte clare. Imaginile mai mici accelerează implementarea și fac scenariile edge și IoT fezabile; performanța aproape nativă și timpii de pornire la nivel de microsecunde deschid uși pentru sarcini de lucru bazate pe evenimente și fără server; sandboxing-ul puternic permite o calculare mai sigură cu mai mulți utilizatori în întreaga stivă.

În același timp, este important să nu exagerăm cu stadiul actual al tehnologiei: WASM pe partea de server este încă la început și nu este un înlocuitor universal pentru containere sau mașini virtuale. Multe scenarii de producție sunt limitate la limbaje cu suport WASM matur, iar instrumentele legate de depanare, observabilitate și profilare a performanței încă recuperează terenul pierdut.

Caracteristici precum memoria colectată prin colectare a gunoiului, modele de threading mai bogate și criptografia de primă clasă sunt în curs de dezvoltare activă în cadrul grupurilor de standarde WebAssembly, dar nu sunt încă disponibile universal. Acest lucru poate îngreuna munca pentru rularea limbajelor care depind de caracteristici sofisticate de GC sau concurență.

În ciuda acestor avertismente, nivelul investițiilor din partea principalilor jucători - furnizori de cloud, platforme de containere, furnizori de browsere și companii de infrastructură - sugerează cu tărie că WASM și WASI pe partea de server vor continua să câștige teren ca o completare a containerelor și ca o nouă bază pentru calculul securizat și portabil. Primii utilizatori în domenii precum gateway-uri, edge computing, DNS și sisteme de plugin-uri demonstrează deja că tehnologia este suficient de robustă pentru medii solicitante, cu trafic intens.

Privind cazurile de utilizare de pe platforme de conținut compilate în Wasm, gateway-uri cloud-native precum APISIX și resolvere la scară internet, cum ar fi versiunea 1.1.1.1 de la Cloudflare, este greu de ignorat cât de repede a crescut WebAssembly dintr-o curiozitate a browserului într-un concurent serios pentru viitorul server-side și edge computing, cu mult spațiu rămas pentru a evolua și a se maturiza.