Come cambia la gestione dei software lato server con WebAssembly: Docker senza container

Parlando dell’evoluzione dell’infrastruttura software lato server, nel corso degli ultimi anni siamo passati piuttosto rapidamente dallo schema tradizionale, che prevedeva l’utilizzo di hardware fisico, a schemi basati su virtualizzazione e containerizzazione.

In passato, infatti, installavamo e configuravamo meticolosamente i sistemi operativi e le applicazioni su ogni macchina fisica provvedendo quindi a gestire e ad aggiornare manualmente ciascun software, uno per uno.

Successivamente, con la diffusione delle macchine virtuali, le cose sono diventate più semplici. Così gli amministratori di sistema hanno cominciato a creare, copiare, spostare e clonare macchine virtuali condivise tra più server fisici. La virtualizzazione ha però mantenuto la necessità di installare sistemi operativi e applicazioni nelle macchine virtuali.

Come spieghiamo nell’articolo sulle differenze tra macchine virtuali e container, è stata poi la volta della containerizzazione. I container non virtualizzano l’intero hardware “sottostante” bensì solamente il sistema operativo: resi popolari da Docker, hanno semplificato la predisposizione delle applicazioni in un contesto minimalista che non influisce sul funzionamento delle altre applicazioni installate sul sistema operativo host.
Con i container resta comunque d’obbligo la distribuzione “in bundle“, ovvero nello stesso pacchetto delle applicazioni, delle corrispondenti librerie e componenti runtime.

WebAssembly (abbreviato Wasm) si appresta a rivoluzionare ancora una volta l’intero scenario.

Perché WebAssembly introduce un nuovo approccio lato server: Docker senza container

WebAssembly (Wasm) è uno standard aperto che definisce un formato di istruzioni binario che consente la creazione di eseguibili “portabili”, quindi direttamente utilizzabili sulle varie piattaforme (a dispetto del sistema operativo in uso e della configurazione hardware), a partire da un’ampia molteplicità di linguaggi. Abbiamo già visto cos’è WebAssembly e già allora, nel 2017, chiarivamo come aveva avuto origine sul Web e perché è supportato da tutti i principali browser.

Addirittura, grazie ad appositi tool come Emscripten, applicazioni legacy possono essere trasferite ed eseguite su un browser comunicando direttamente attraverso codice JavaScript caricato lato client.

WebAssembly ha permesso di eseguire applicazioni tradizionali nel browser, indipendentemente dal dispositivo in uso: alcuni esempi degni di nota sono Google Earth e la libreria OpenCV per la visione artificiale.

Oggi esistono runtime Wasm che possono essere eseguite al di fuori del browser, ad esempio direttamente su sistemi operativi tradizionali come Linux, Windows e macOS. Poiché non possono fare affidamento sulla disponibilità di un motore JavaScript, comunicano con il “mondo esterno” utilizzando interfacce diverse, come WASI (WebAssembly System Interface).
Il bello è che anche in questo caso è necessario compilare un’applicazione come modulo Wasm una volta sola: lo stesso binario potrà quindi essere eseguito e utilizzato ovunque.

Come spiegano Asen Aleksandrov e Daniele Lopez di Wasm Labs (VMware OCTO), WebAssembly introdurrà una vera rivoluzione in ambito server: le sue caratteristiche tecniche e la portabilità consentono la distribuzione delle applicazioni senza richiedere dipendenze a livello di sistema operativo e la loro esecuzione senza rigidi vincoli sul piano della sicurezza.
WebAssembly è insomma il successore dei container e il prossimo passaggio logico nel deployment delle infrastrutture software lato server.

Proprio di recente Docker ha annunciato l’introduzione del supporto per WebAssembly in collaborazione con il runtime WasmEdge: di Docker più Wasm si parla in questa pagina ufficiale. Rispetto ai tradizionali container, l’immagine del contenitore non deve più contenere il sistema operativo, runtime e librerie necessarie per l’applicazione: diventa sufficiente un singolo binario Wasm.

Docker ha reso i container la strada da percorrere quando si desidera ottenere un’applicazione portabile. Tuttavia, oltre alle grandi dimensioni dell’immagine, i container sono legati all’architettura della piattaforma su cui vengono eseguiti. Con Wasm l’immagine diventa “portabile per davvero”.

E questo non vale solo per i progetti realizzati usando linguaggi compilati ma anche per quelli che poggiano su linguaggi interpretati: in un altro articolo spieghiamo le differenze tra compilazione e interpretazione: una volta compilata in Wasm, qualsiasi piattaforma con un runtime Wasm è infatti in grado di gestire linguaggi interpretati anche se l’interprete in sé non fosse mai stato compilato in modo nativo per la specifica piattaforma.