WebAssembly sul server: i container leggeri alla prova del carico reale

L’idea è semplice e potente: compilare il servizio in un modulo WebAssembly e farlo girare in una sandbox che parte in millisecondi, consuma pochi megabyte e non sa nulla della macchina che lo ospita. Per il serverless e per l’edge — dove il cold start è il nemico e la densità è il guadagno — è la combinazione che i container tradizionali non hanno mai offerto davvero.

Funzioni di trasformazione, filtri, plugin eseguiti dentro piattaforme altrui: qui Wasm è già in produzione e i numeri sono quelli promessi. L’avvio si misura in millisecondi contro le centinaia dei container, e su uno stesso nodo si impacchettano un ordine di grandezza in più di tenant, con un isolamento che non dipende dal kernel condiviso.

Il modello dei componenti, con le sue interfacce tipate, sta facendo nascere il pezzo che mancava: un ecosistema di moduli riusabili tra linguaggi diversi. Scrivere un’estensione in Rust e usarla da un host in Go senza FFI artigianale è il genere di cosa che cambia le architetture dei prodotti estensibili.

Il quadro cambia appena servono thread veri, accesso ricco al sistema, librerie native mature: lì l’ecosistema Wasm è ancora giovane e ogni eccezione costa una trattativa con il runtime. Migrare un monolite esistente non ha quasi mai senso; i container con il loro tooling collaudato — registry, orchestratori, osservabilità — restano la casa naturale dei servizi di lunga vita.

La lettura giusta non è la sostituzione ma la specializzazione: i container per i servizi, Wasm per le funzioni e per il codice di terzi da eseguire in sicurezza. Le piattaforme che li fanno convivere fianco a fianco sono già qui, e sono loro la vera notizia.