WebAssembly (Wasm) in Cloud Native

Running WebAssembly workloads on Kubernetes and serverless platforms for near-native performance, instant cold starts, and sandboxed multi-tenancy.

Overview

Wasm beyond the browser

WebAssembly (Wasm) was designed for the browser. Its properties (compact binary format, near-native speed, sandboxed security and language agnosticism) make it increasingly attractive for server-side and cloud-native workloads.

WASI: the server-side enabler

WASI (WebAssembly System Interface) gives a standardized, capability-based interface to OS resources (file system, networking, clocks) without exposing the OS directly. A module compiled for WASI runs on any runtime that implements the interface.

> [!TIP] That is portability even containers do not fully achieve, because container images are tied to Linux.

The runtime landscape

Wasmtime — Bytecode Alliance; used by Fastly
WasmEdge — CNCF sandbox project, optimized for edge and cloud
Spin — Fermyon's application framework built on Wasmtime
WASM-Workers-Server — Workers-style server runtime

The OCI working group is standardizing Wasm distribution through OCI registries, so a module can be pushed and pulled like a container image.

Where Wasm beats containers

Cold starts for scale-to-zero serverless — Microseconds — 100ms–1s
Multi-tenant sandboxing — Each module in its own memory sandbox, no shared state — Tenants share a kernel
Edge computing (Fastly, Cloudflare Workers) — Single-digit MB binaries — Hundreds of MB

Kubernetes integration

The crun runtime supports Wasm workloads, and runwasi provides containerd shims for Wasmtime and WasmEdge. The binary runs directly as a container workload: no JVM, no interpreter, no full OS image.

Not a container replacement today

Mature networking — API middleware
Persistent storage — Plugin systems
GPU access — Edge inference
Policy enforcement: OPA evaluates policy in Wasm, Envoy runs Wasm HTTP filter plugins

> [!IMPORTANT] Wasm fits short-lived, stateless, latency-sensitive workloads; long-running stateful services stay in containers.

Key concepts

WASI (WebAssembly System Interface): Capability-based API for Wasm modules to access OS resources (files, network, clocks) in a sandboxed, portable way. WASI Preview 2 (2024) introduces a component model for composable Wasm modules.
Wasmtime: Bytecode Alliance Wasm runtime written in Rust. Used by Fastly Compute, AWS Lambda (Rust runtime uses Cranelift, Wasmtime's JIT). Reference implementation for WASI.
WasmEdge: CNCF-incubating Wasm runtime optimized for cloud and edge. Supports WASI, Kubernetes via containerd shim, and has extensions for networking and AI/ML inference.
Spin (Fermyon): Framework for building serverless Wasm applications. Provides HTTP triggers, key-value storage, SQLite, and Redis bindings. Runs on Wasmtime; deployable to Kubernetes via SpinKube.
runwasi: CNCF project providing containerd shims for Wasm runtimes. Enables Kubernetes to run Wasm workloads alongside container workloads using runtimeClassName in Pod specs.
Component model: WASI Preview 2 feature: composable Wasm modules with typed interfaces (WIT — WebAssembly Interface Types). Enables building applications from independently-compiled, language-agnostic Wasm components.

When to use it

Evaluating Wasm vs containers for edge, serverless, or multi-tenant plugin architectures
Interview questions about emerging cloud-native runtimes beyond Docker and containerd
Understanding why Cloudflare Workers and Fastly Compute use Wasm instead of containers
Designing plugin systems that need safe multi-tenant code execution (e.g., Envoy Wasm filters)
Exploring scale-to-zero serverless patterns where container cold start latency is prohibitive

Interview questions

What advantages does WebAssembly offer over containers for edge and serverless computing?