Che la sfida abbia inizio

Non c’è ombra di dubbio sul fatto che i container Docker abbiano dominato la scena sul fronte cloud negli ultimi anni. Ora però, un’altra tecnologia si sta facendo largo ed è giunto il momento di capire se l’una può sostituire l’altra. Ma andiamo con ordine.

Piccolo ripasso: cosa sono i container Docker

Come anticipato nell’introduzione di questo articolo, Docker è ormai il segreto di Pulcinella. Chiunque si occupi di scrivere codice e di distribuirlo nel Cloud deve conoscere questa tecnologia. In ogni caso, per qui pochi ancora che non sapessero di cosa si tratta vediamo di fare un piccolo ripasso. Docker è una tecnologia che ci consente di racchiudere un’applicazione, e tutte le sue dipendenze, in un unico pacchetto pronto per essere eseguito. In una frase sola, la fatidica affermazione “però sul mio PC funziona” non la possiamo più usare!

I più esigenti poi possono raggruppare, e distribuire in colpo solo, applicazione e infrastruttura sfruttando Docker Compose, ed infine, piattaforme del calibro di Kubernetes sono utilizzate per eseguire i nostri container Docker in cluster di produzione e distribuire le risorse su una o più macchine a seconda delle specifiche esigenze.

Volendo riassumere il concetto possiamo affermare che un’immagine Docker è un insieme di istantanee del file system contenente tutto ciò di cui la nostra applicazione ha bisogno per funzionare. Ed in effetti, dal punto di vista della nostra applicazione, queste istantanee formano un singolo ambiente che appare proprio come un sistema operativo a tutti gli effetti.

Provate a pensare all’immagine Docker dell’applicazione web che avete appena completato, vi troverete sicuramente

• Una distribuzione di Linux, magari di quelle leggere, come Alpine
• I programmi di supporto, quali framewrok, pacchetti vari necessari all’applicazione stessa per funzionare
• la vostra applicazione ovviamente!

Ecco, l’unica attenzione è appunto preparare la distribuzione per Linux, ossia la più comune, o per Windows. Per il resto non dobbiamo preoccuparci di modificare la nostra applicazione perchè possa essere eseguita su Docker.

Riepilogando, quando prepariamo l’immagine per Docker dobbiamo tenere presente questi aspetti

• Il Sistema Operativo (Linux o Windows). Le immagini generiche non esistono!
• L’architettura del sistema che ospiterà il container. Sulla Raspberry PI possono girare solo immagini Linux compilate per processori ARM
• Non serve riscrivere l’applicazione affinchè possa essere distribuita tramite Docker (a meno che non stiamo parlando di vecchi framework, ma anche in questo caso … dipende)
• Le immagini Docker sono più leggere di una macchina virtuale e richiedono meno risorse quando vengono eseguite

Ok, ora possiamo considerarci cintura nera di Docker container.

I Moduli WebAssembly

Vediamo ora di conoscere l’altro attore di questa sfida, ovvero i moduli WebAssembly. Si tratta di applicazioni compilate, nulla di più, nulla di meno. Possiamo compilare un’applicazione Go, C#, Rust nel suo formato nativo e trovarci tra le mani un file binario da eseguire. Allo stesso modo potremmo compilare programmi scritti con gli stessi linguaggi direttamente in WebAssembly. A questo punto il binario ottenuto potrebbe essere eseguito su un runtime WebAssembly, ad esempio wasmtime, wamr o wagi.

Qual’è la prima differenza rispetto a Docker? Un modulo WebAssembly non viene fornito con un filesystem preconfezionato, e nemmeno con atre primitive di basso livello. Variabili d’ambiente, file, directory, timer e altre risorse di sistema possono invece essere collegate direttamente al nostro modulo.

Più che ad un container possiamo dire che un modulo WebAssembly è più simile ad un Pod di Kubernetes, nel senso che file system e variabili d’ambiente sono legati ad un container nel momento in cui questi viene avviato. La differenza fondamentale è che questa è proprio una caratteristica fondamentale di WASI (WebAssembly System Interface), come anticipato prima, uno degli standard di WebAssembly stesso. Fa parte di un runtime, non di un sistema orchestrazione come nel caso di Kubernetes.

I più attenti avranno già notato un punto di vantaggio rispetto a Docker. Il formato WebAssembly è neutrale, non è legato alla piattaforma, Linux o Windows come Docker appunto. Un singolo binario può essere compilato ed esguito su una varietà di sistemi operativi e architetture. WebAssembly permette al runtime di capire come vengono gestiti i file e le variabili d’ambiente quindi non ha bisogno di informazioni specifiche per la piattaforma.

Le limitazioni, al momento, arrivano dal fatto che le specifiche WASI non sono ancora complete, e questo impedisce a molte applicazioni esistenti di essere compilate in WebAssembly. Possiamo riassumere alcune limitazioni importanti

• Non esiste un modo per avviare un server di rete in WebAssembly
• Le specifiche dei socket sono ancora in fase di sviluppo
• Gli strumenti disponibili in rete sono ancora troppo acerbi per fornire supporto totale allo sviluppo di applicazioni a microservizi sfruttando solo WebAssembly

Per il momento, dunque, i container Docker possono dormire sonni tranquilli. Restano loro lo strumento ideale per eseguire servizi esistenti come database e/o broker di messaggi. Certamente l’orizzonte appare diverso per chi sviluppa applicazioni a microservizi. L’architettura WebAssembly promette di cambiare notevolmente le carte in tavola perchè, almeno sulla carta, appare più semplice, più veloce e soprattutto più facile da mantenere.

Docker o WebAssembly?

Al termine di questo dibattito possiamo proclamare un vincitore? Ovviamente no, la sola ed unica risposta degna di uno sviluppatore è Dipende!

Leggendo l’affermazione di Solomon Hykes, uno dei fondatori di Docker, si potrebbe pensare che WebAssembly sconfiggerà inevitabilmente i container, ma la soluzione più ovvia, al momento, pare essere quella di una convivenza complementare fra i due antagonisti.

Dalla parte dei container sicuramente va accredidato il fatto che i programmi esistenti non devono essere riscritti per essere eseguiti nei container stessi. Se un programma necessita di un elevato controllo del filesystem troverà la soluzione a container più amichevole, di certo meno restrittiva delle rigorose sandbox imposte da WebAssembly. La mancanza di specifiche per i socket di rete lasciano intendere che scalfire Docker & Co. non sarà una battaglia di breve durata.

Discorso completamente diverso se si tratta di scrivere microservizi, applicazioni web, handler di eventi, processi di Machine Learning, perchè in questo caso, WebAssembly ha già aperto nuove strade e nuove possibilità di sviluppo e di distribuzione. Oltre ai già citati punti di forza, i tempi rapidissimi di avvio e spegnimento dei moduli WebAssembly fanno sì che questi ultimi possano essere eseguiti su richiesta, il che li rende particolarmente economici e semplici da manutenere, un’accoppiate decisamente vincente.

Lo stesso Hykes, in seguito, ha rivisto il suo tweet

Staremo a vedere come evolverà la sfida … state collegati per avere aggiormenti sullo sviluppo.