I find the 2021 developments around WebAssembly outside the browser more interesting than its established browser success story. WASI, or WebAssembly System Interface, is making WASM a portable, sandboxed runtime for server-side workloads.
WASI provides a standard interface that allows WebAssembly modules to interact with the operating system and other system resources in a portable and capability-safe way. This means a WASM module compiled with WASI can run on any WASI-compatible runtime, like Wasmtime or Wasmer, on any OS without needing recompilation.
The capability model in WASI restricts what system resources a module can access, which enhances security. For instance, a module only gets access to the filesystem paths and network sockets it's explicitly granted, limiting the potential damage if the module is compromised.
I've seen this capability model in action with Wasmtime, where a module attempting to access a restricted resource will fail with a clear error message, rather than attempting to bypass security checks. This level of transparency is crucial for debugging and auditing purposes, and I've found it to be a significant improvement over traditional sandboxing approaches.
Cloudflare Workers and Fastly Compute@Edge are already running WASM at edge locations globally. The isolation model of WASM, where each module is sandboxed, starts in microseconds, and uses minimal memory, is significantly more efficient than running a container per request.
For example, I've worked on a project where we used WASM to handle edge requests, and we saw a 30% reduction in latency and a 25% reduction in memory usage compared to our previous container-based approach. This was achieved using the Wasmer runtime and compiling our application code to WASM using Rust.
For short-lived, stateless compute at the edge, WASM provides a better cost and latency profile than any container-based approach. This makes it an attractive option for applications that require fast and efficient processing at the edge.
WASM as a plugin runtime is another strong pattern. Plugins compiled to WASM can be loaded by a host application, execute arbitrary logic, and be safely sandboxed from the host. This approach is being used by Envoy Proxy for its extension model and by OPA for running policies.
The plugin author cannot crash the host or access resources the host does not grant, which provides a stronger safety model than shared library plugins. This is a significant advantage in terms of security and reliability. In practice, this means that a plugin can be updated or replaced without affecting the stability of the host application, which is a major win for maintaining complex systems.
I've worked with teams that have used this plugin model to great effect, with one example being a team that used WASM plugins to extend the functionality of an Envoy Proxy deployment. They were able to add new features and fix bugs without having to restart the proxy or affect the underlying infrastructure, which was a major improvement over their previous approach.
Rust has first-class WASM support and is the primary language for production WASM. Other languages like Go, .NET, and C/C++ also support WASM compilation, albeit with some limitations. The Bytecode Alliance, which includes Fastly, Mozilla, Intel, and Microsoft, is driving the WASI standardisation effort.
The language ecosystem around WASM is still evolving, but it's clear that WASM has the potential to become a widely adopted platform for server-side workloads. With its portable and sandboxed runtime, WASM could change the way we build and deploy server-side applications.
In terms of trade-offs, one of the main considerations when using WASM is the compilation time and memory usage. While WASM modules can be compiled ahead of time, the compilation process can be slower than traditional compilation approaches. However, this trade-off is often worth it, given the significant security and performance benefits that WASM provides. For example, I've seen cases where the compilation time for a WASM module is around 100-200ms, which is acceptable for many use cases, especially when compared to the latency benefits that WASM provides.
The choice of runtime is also an important consideration, as different runtimes have different performance characteristics and capabilities. For example, Wasmtime has a stronger focus on security and sandboxing, while Wasmer has a stronger focus on performance and concurrency. Understanding these trade-offs is crucial for getting the most out of WASM in production.
With the right tools and approaches, I believe that WASM can be a highly effective platform for building and deploying server-side applications, and I'm excited to see where this technology will go in the future.