Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — In 2026, WASM Is Not "Fast Assembly in the Browser"

Solomon Hykes (the Docker founder) tweeted a now-famous line back in 2019:

> "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker."

In 2026 that quote has stopped being aspirational and started being descriptive.

- **WASI Preview 2 went GA in January 2024**, and throughout 2025 every major runtime shipped full P2 compatibility. Wasmtime 26+, WasmEdge 0.14+, Wasmer 5+, and jco 1.x all execute P2 components.

- **The Component Model has stabilized**, so Rust, Go, JavaScript, Python, and Java code now compose through a single WIT interface. Polyglot is no longer a slogan; it is a standard.

- **Edge compute** has adopted WASM as the next generation isolation primitive after V8 isolates. Cloudflare Workers binds WASM natively, Fastly Compute@Edge was built on WASM from day one, and Cosmonic, Fermyon Cloud, and Wasmer Edge have grown into WASM-native PaaS offerings.

- **Docker Desktop officially supports WASM workloads** so `docker run --runtime=io.containerd.wasmedge.v1` boots a WASM module without a container. Kubernetes schedules these workloads via RuntimeClass and spin-operator.

- **Embedded and IoT** now treat WASM as a safe, OTA-updatable plugin model. Extism leads the charge.

This article walks through that landscape in 24-28 chapters. Every code snippet works on real toolchains as of May 2026, and every referenced URL is real.

> One-line takeaway: **"Where does my code run, with what authority, and who composes it?"** Those two questions decide 90% of WASM tooling choices in 2026.

Chapter 1 · Revisiting the Essence of WASM — Assembly, Isolation, Portability

WebAssembly is often introduced as "fast assembly," but its real essence rests on three axes.

| Axis | Meaning | Result |

| --- | --- | --- |

| Portable bytecode | Stack-machine-based virtual ISA | Same binary runs anywhere |

| Sandboxed by default | No direct access to host memory or syscalls | Clear trust boundary |

| Deterministic | Deterministic minus floating-point NaN quirks | Great cacheability and reproducibility |

The browser was just stage one. Since the 2017 MVP, the core spec has expanded to include reference types, multi-value, bulk memory, SIMD, threads, tail call, GC, exception handling, multi-memory, and function references. As of 2026, GC and exception handling are stable across every major runtime, which lets GC-heavy languages such as Java, Kotlin, OCaml, and Dart compile naturally.

**Crucial mental shift:** in 2026, WASM is not "a fast VM for C/Rust." It is **"a language-neutral component ABI."** That is why the Component Model in the next chapter is the real story.

Chapter 2 · WASI Preview 1 vs Preview 2 — From POSIX Mimicry to Capability Interfaces

Early WASI (WebAssembly System Interface) was a partial POSIX imitation. Functions like fd_read, fd_write, and path_open lived in a flat wasi_snapshot_preview1 interface that Rust's wasm32-wasi target called directly. Effectively, "POSIX lent by the runtime."

WASI Preview 2 (WASI 0.2) is different.

- All interfaces are described with **WIT (WebAssembly Interface Type)**. Instead of a flat list of functions, you get a **hierarchy of interfaces and worlds**.

- Standard P2 worlds: `wasi:cli/command`, `wasi:http/proxy`, `wasi:keyvalue/store`, `wasi:filesystem/types`, `wasi:sockets/network`, `wasi:logging/logging`, `wasi:clocks/wall-clock`, `wasi:random/random`.

- Each world exposes **only the authority the host explicitly imports**. If a module wants to see the host disk, the host has to wire in `wasi:filesystem` explicitly.

This is **capability-based security** in practice. There is no ambient authority floating around. A module can only do what it imported. Compared to container seccomp/capabilities/AppArmor, the model is far more explicit and composable.

The P1 to P2 migration was mostly done in 2025. Rust's wasm32-wasip2 target, TinyGo's wasip2, and jco's P2 component generation are the standard paths.

Chapter 3 · The Component Model — A Language-Neutral ABI as a Major Event

The Component Model adds two layers on top of WASM.

1. **Core module** — the existing .wasm: functions, memory, tables, globals.

2. **Component** — bundles multiple core modules and exposes WIT types (record, variant, list, option, result, resource, tuple, string) as external interfaces.

What the Component Model solves is **ABI negotiation across languages**. C and Rust manage memory directly. Go has a GC. JavaScript has GC plus JIT. They cannot call each other's functions directly. The Component Model sits between them with a canonical ABI and uses lift/lower operations to convert types.

Here is a snippet of a WIT interface definition.

package example:greeter@0.2.0;

interface api {

/// Build a greeting.

greet: func(name: string) -> string;

/// A counter resource.

resource counter {

constructor();

increment: func();

get: func() -> u64;

}

world greeter {

export api;

}

From this one WIT file:

- In **Rust**, `wit-bindgen` macros produce traits and implementation stubs.

- In **JavaScript**, `jco transpile` emits ES modules.

- In **Go**, `wit-bindgen-go` generates a Go package.

- In **Python**, `componentize-py` wraps Python code as a WASM component.

The caller does not know which language implemented the component. That is the promise of the Component Model.

Chapter 4 · Wasmtime — The Bytecode Alliance Reference Runtime

Wasmtime is effectively the reference implementation of WASM, maintained by the Bytecode Alliance. It is written in Rust and uses Cranelift codegen to AOT/JIT compile to x86_64, aarch64, and s390x.

Wasmtime 26.x is the current stable line in 2026. Highlights:

- **WASI Preview 2 full support** via the wasmtime-wasi crate.

- **Component Model first-class** via the wasmtime-component crate.

- **Pooling allocator** — reuse memory without fragmentation when running tens of thousands of instances.

- **Epoch-based interruption** — externally stop runaway loops.

- **Pre-compilation (.cwasm)** — AOT artifacts give cold starts in the tens of microseconds.

- **Async support** — clean integration with Tokio.

Wasmtime's beauty is that host embedding is straightforward. Here is the Rust flow for loading a component and calling a function:

use wasmtime::{Engine, Config, Store};

use wasmtime::component::{Component, Linker};

fn main() -> anyhow::Result<()> {

let mut config = Config::new();

config.wasm_component_model(true);

config.async_support(false);

let engine = Engine::new(&config)?;

let component = Component::from_file(&engine, "greeter.wasm")?;

let mut linker = Linker::new(&engine);

wasmtime_wasi::add_to_linker_sync(&mut linker)?;

let wasi = wasmtime_wasi::WasiCtxBuilder::new()

.inherit_stdio()

.build_p1();

let mut store = Store::new(&engine, wasi);

let instance = linker.instantiate(&mut store, &component)?;

let greet = instance.get_typed_func::<(String,), (String,)>(&mut store, "greet")?;

let (out,) = greet.call(&mut store, ("WASI 2026".into(),))?;

println!("{out}");

Ok(())

}

Spin, wasmCloud, and the Lambda Adapter all variant this same pattern internally.

Chapter 5 · Wasmer — Multi-Backend WASM and a Package Manager Mindset

Wasmer takes a different tack. From day one it offered **multiple compiler backends** (Cranelift, LLVM, Singlepass), and it shipped WAPM (the WebAssembly Package Manager) as an npm-style distribution channel.

In 2026, Wasmer 5.x leans into the following strengths:

- **LLVM backend at peak performance** — 90% of native speed.

- **WASIX** — its own extension of Preview 1 covering threads, signals, fork, exec, and TCP/UDP sockets. Python, Bash, and Postgres demos famously run on Wasmer.

- **Wasmer Edge** — its own edge PaaS that competes with Cloudflare Workers.

- **JS/Python/PHP integrations** — host-language agnostic SDKs.

Running Python on Wasmer is a one-liner:

wasmer run python/python --mapdir=/app:./app -- /app/main.py

WAPM bundles packages on top of the Component Model. In 2026, interop with OCI registries (GHCR, Docker Hub) accelerated, and pushing WASM components to ghcr.io is now a standard flow.

Wasmer's P2 support lagged Wasmtime briefly but caught up in 5.x. The combination of WASIX **and** P2 in one runtime is Wasmer's biggest differentiator.

Chapter 6 · WasmEdge — A Runtime Tuned for Cloud-Native and AI

WasmEdge went from CNCF Sandbox through Incubating and reached near-Graduated status in 2025. It is purpose-built for CloudOS, CDN, and AI inference.

- **AOT (Ahead-of-Time) compilation** via LLVM. Cold start is practically zero.

- **First-class Kubernetes workloads** through containerd-wasm-shims, CRI-O, Docker Desktop, and Kubernetes RuntimeClass.

- **AI plugins** — WasmEdge ggml (a llama.cpp backend), PyTorch, TensorFlow Lite, OpenVINO. Llama 3, Mistral, and Qwen run inference directly inside WasmEdge.

- **Networking extensions** — TLS, HTTP/2, and QUIC supplied by the host.

- **Language SDKs** — Rust, C, Go, Java, Python, and JavaScript (via QuickJS integration).

Since Docker Desktop 4.x, WasmEdge runs with a single flag: `docker run --runtime=io.containerd.wasmedge.v1`. On Kubernetes, you define a RuntimeClass:

apiVersion: node.k8s.io/v1

kind: RuntimeClass

metadata:

handler: wasmedge

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels: { app: hello-wasm }

template:

metadata:

labels: { app: hello-wasm }

spec:

runtimeClassName: wasmedge

containers:

- name: hello

image: ghcr.io/example/hello-wasm:0.1.0

WasmEdge has cleanly positioned itself as "the easiest way to run WASM on Kubernetes."

Chapter 7 · Spin (Fermyon) — A WASM Microservices Framework

Fermyon's Spin is something like "Express or Flask on top of WASM." One component plays an HTTP handler, Redis consumer, or cron trigger; components talk to one another through WIT.

Spin's core pieces:

- **spin.toml** — the manifest.

- **trigger** — http, redis, mqtt, cron, sqs, kafka.

- **wasi-keyvalue, wasi-sqlite, wasi-llm** — P2 interfaces provided by Spin acting as host.

- **Spin SDK** — Rust, Go, JS/TS, Python, .NET, and Java.

A minimal HTTP component manifest:

spin_manifest_version = 2

[application]

name = "hello-spin"

version = "0.1.0"

[[trigger.http]]

route = "/hello/..."

component = "hello"

[component.hello]

source = "target/wasm32-wasip2/release/hello.wasm"

allowed_outbound_hosts = ["https://api.example.com"]

key_value_stores = ["default"]

sqlite_databases = ["default"]

[component.hello.build]

command = "cargo build --target wasm32-wasip2 --release"

watch = ["src/**/*.rs", "Cargo.toml"]

Spin runs locally as a single binary (`spin up`) and deploys to Fermyon Cloud or to Fermyon Platform for Kubernetes via spin-operator. Think of it as "a WASM-native operational system for microservices."

In 2026, Spin integrated with LangChain/LlamaIndex-style AI workflows (`spin-llm`) and expanded into the edge AI server category.

Chapter 8 · wasmCloud — WASM on a Distributed Actor Model

wasmCloud is a CNCF Incubating project that bundles "WASM components + actor model + NATS messaging." Its core ideas:

- All business logic lives in **components (actors)**. A component knows only its WIT interfaces.

- External systems (DB, HTTP, key-value, blob storage) are owned by **providers (capability providers)**.

- The **lattice** (a virtual network built on NATS) routes between them.

This is dependency inversion, full stop. A component does not "call Redis." It "calls wasi:keyvalue/store." Whether the actual store is Redis, NATS KV, or Postgres is bound at deploy time by an operator in wadm (the wasmCloud Application Deployment Manager).

apiVersion: core.oam.dev/v1beta1

kind: Application

metadata:

spec:

components:

- name: hello

type: component

properties:

image: ghcr.io/example/hello:0.1.0

traits:

- type: spreadscaler

properties:

instances: 5

- type: link

properties:

target: redis-kv

namespace: wasi

package: keyvalue

interfaces: ["store"]

- name: redis-kv

type: capability

properties:

image: ghcr.io/wasmcloud/redis-kv:0.10.0

The ability to span the same lattice across multiple clouds, edge sites, and on-prem is what wasmCloud sells. Adobe, BMW, and Bosch appear as conference case studies.

Chapter 9 · Lunatic — A WASM Runtime Inspired by Erlang/Elixir

Lunatic carries BEAM (the Erlang VM) ideas — actors, supervisor trees, preemptive scheduling — into WASM. It is built in Rust and uses Wasmtime as its core.

- **Hundreds of thousands of lightweight processes** on a single node.

- **OTP-style supervisors** to oversee children.

- **Pure message passing**. No shared memory.

- **Distributed mode** for cross-node messaging.

It shines in workloads where concurrency dominates:

- Game servers, chat, collaboration tools.

- Long-running workflow engines.

- Multi-tenant SaaS that needs fine-grained isolation.

Where Spin is "a bundle of HTTP handlers," Lunatic is "BEAM on top of WASM." The two are not competitors; they live in different niches.

Chapter 10 · Extism — A Standard for Embedding WASM Plugins in Host Apps

Extism focuses on one question: "I want to extend my app with WASM plugins." Dylibso maintains it as OSS.

- Host SDKs: C, Rust, Go, JavaScript (Node + Browser), Python, Ruby, PHP, .NET, Java, Zig, Haskell, Elixir, OCaml.

- Plugin SDKs (PDK): Rust, Go, AssemblyScript, JS, Zig, C, Haskell.

- The interface is **WASM functions + memory + host functions**. A simpler ABI than the Component Model.

Common scenarios:

- **User-defined functions in databases and queues** — Cloudflare D1, Materialize, and Tessera run untrusted user code safely.

- **Extension points in CMSes and SaaS** — Sanity, GitHub Actions, internal workflow engines.

- **CLI tool plugins** — `awscli`, `kubectl`, and `terraform` can adopt external code safely.

Extism trades some of the Component Model's generality for **integration simplicity**. As of 2026 Extism 1.x is stable, and pulling plugins from OCI registries via `extism call oci://...` is standard.

Chapter 11 · JCO and StarlingMonkey — JavaScript Becomes a Component Too

JCO (JavaScript Component Object) is the JavaScript ↔ Component bridge from the Bytecode Alliance. jco 1.x is the stable line in 2026.

Key capabilities:

- `jco componentize app.js --wit ./wit -o app.wasm` — wrap JavaScript with **StarlingMonkey** (an embedded JS engine derived from SpiderMonkey) into a single component .wasm.

- `jco transpile component.wasm -o ./out` — turn a component into ES modules that Node.js or browsers can import.

- `jco run app.wasm` — execute a P2 component directly on Node.

StarlingMonkey is a slimmed-down SpiderMonkey for embedding — the next-generation JS-on-WASM runtime after Cloudflare workerd. Fastly Compute and Fermyon Spin picked StarlingMonkey for their JS component runtime.

JCO's real superpower is **TypeScript type generation**. It produces `.d.ts` files from WIT so callers get type-safe access to every component function and resource.

// app.js — input to jco componentize

export const api = {

greet(name) {

const { seconds } = now();

log('info', 'greeter', `now=${seconds}`);

return `Hello, ${name}! It is now ${seconds}.`;

};

This single file, after jco, becomes a component that can run on any host: Wasmtime, Spin, wasmCloud, or Cloudflare Workers.

Chapter 12 · Polyglot Compilation Paths — Rust, Go, C/C++, AssemblyScript, Python, Java, .NET

A short table of the canonical 2026 compilation paths.

| --- | --- | --- | --- |

The big 2024-2025 shift is that Python, Java, and .NET became componentizable. The old "C/Rust only" framing is obsolete.

Chapter 13 · WIT and wit-bindgen — Interface-First Development

How the Component Model really works in practice: **"write the WIT first, pick the implementation language second."**

`wit-bindgen` reads WIT and emits bindings for each language. Rust example:

wit_bindgen::generate!({

world: "greeter",

path: "./wit",

});

use exports::example::greeter::api::Guest;

struct Component;

impl Guest for Component {

fn greet(name: String) -> String {

format!("Hello, {name} from Rust WASM!")

}

export!(Component);

Build and componentize with wasm-tools:

cargo build --target wasm32-wasip2 --release

wasm-tools component new \

target/wasm32-wasip2/release/greeter.wasm \

-o greeter.component.wasm

wasm-tools validate greeter.component.wasm

The resulting `greeter.component.wasm` is identical whether you run it on Wasmtime, Spin, jco, or wasmCloud. That is the promise of the Component Model.

Chapter 14 · Cloudflare Workers and WASM — Modules on Top of V8 Isolates

Cloudflare Workers uses V8 isolates as its primary isolation unit and supports WASM as a first-class module.

- Bind WASM via `[[rules]]` plus `type = "CompiledWasm"` in `wrangler.toml`.

- A JS worker calls WASM exports directly.

- Limits: 32MB memory, 50ms CPU (free) or 30s (paid).

- In 2025, **direct execution of WASI Preview 2 components** entered beta — previously a JS shim was required.

A typical Rust to WASM to Workers flow:

cargo install wasm-pack

wasm-pack build --target web

wrangler deploy

Workers is powerful, but it does not support every aspect of the Component Model (arbitrary host imports, for example). Cloudflare instead supplies its own built-in bindings (KV, R2, D1, Queues, AI, Durable Objects).

Chapter 15 · Fastly Compute@Edge — The Prototype WASM-First Edge

Fastly Compute@Edge has been built on WASM (Wasmtime under the hood) since day one. There is no V8 isolate in between — WASM instances run directly.

- Cold start under 1ms thanks to pre-instantiation.

- First-class SDKs for Rust, JS, Go (TinyGo), and AssemblyScript.

- ESI (Edge Side Includes), KV Store, Config Store, Object Store, Secret Store.

- 2025 brought formal P2 component adoption; 2026 added direct execution of JS components built via jco.

Fastly's strengths are **logging and real-time metrics** and a broad set of certifications (SOC2, PCI, HIPAA). Media, e-commerce, and financial services tend to live on Fastly Compute.

Chapter 16 · AWS Lambda Web Adapter and WASM — Running Components on Lambda

As of 2026 AWS Lambda has **no first-class WASM runtime**. Two workarounds are standard:

1. **AWS Lambda Web Adapter** — run Wasmtime inside a Lambda container image and execute components there. See the `awslabs/aws-lambda-web-adapter` GitHub repository.

2. **Fermyon Spin on Lambda** — package Spin components inside the Lambda Adapter.

Lambda's ~350ms cold start versus Wasmtime's microsecond cold start is a tax the user pays. So serious WASM edge workloads tend to land on Fastly, Cloudflare, Fermyon Cloud, Cosmonic, or Wasmer Edge instead.

That said, AWS announced in late 2025 that Bedrock will accept WASM-based custom functions. Lambda gaining first-class WASM support within the next year or two is plausible.

Chapter 17 · Docker WASM and containerd-wasm-shims — WASM Without Containers

Docker Desktop 4.15+ shipped WASM workloads as official beta, and the feature went GA in 2025. The implementations are `containerd-shim-wasmtime`, `containerd-shim-wasmedge`, `containerd-shim-wasmer`, and `containerd-shim-spin`.

If an OCI image contains a WASM binary, one flag — `--runtime=io.containerd.wasmedge.v1` — runs it on the node. The container runtime starts a WASM instance instead of a container.

Kubernetes does the same via RuntimeClass. The result: a single node hosts both containers and WASM, and the scheduler matches workloads to runtimes automatically.

Chapter 18 · Capability-Based Security — Why WASM's Trust Boundary Is Tighter Than Containers'

Container isolation combines namespaces, cgroups, seccomp, and AppArmor in the Linux kernel. Powerful, but the trust depends on a single kernel — and one CVE can collapse the whole boundary.

WASM's isolation is different.

- **Memory** is a single linear region. A module sees only its own allocation.

- **Function calls** go through the import table. Unknown host functions cannot be called.

- **Syscalls do not exist as a concept**. The only path outward is through WASI imports.

- **Determinism** — same input plus same imports yields the same output. Caching, proofs, and reproduction are easy.

This model gives WASM a **tighter trust boundary** than containers. Containers say "you get everything; subtract what you don't need." WASM says "you get nothing; add what you do need."

For enterprise security teams the gap is enormous. Multi-tenant SaaS, user-code execution (Cloudflare Workers, Replit, Modal), untrusted plugins — in every one of these scenarios WASM is a safer answer than containers.

Chapter 19 · Performance — Cold Start, JIT, AOT, and Pre-Instantiation

Performance has no single answer. Separate three phases.

1. **Compilation** — turning .wasm bytecode into native code. JIT (Wasmtime default) versus AOT (WasmEdge, Wasmer LLVM, Wasmtime `--cache`).

2. **Instantiation** — attaching memory, tables, and globals to a compiled module to produce an executable instance.

3. **Execution** — actually calling functions.

The cold-start secret sauce is **pre-instantiation and pooling**.

- Wasmtime `--allow-precompiled` + .cwasm artifacts skip compilation entirely.

- A pooling allocator recycles instances — instantiation in tens of microseconds.

- Fastly Compute pre-loads every .wasm into the data plane and only allocates per-request instances.

Execution speed with the LLVM backend lands at 70-95% of native. SIMD, threads, and tail-call enabled workloads (image processing, crypto, ML inference) often exceed 90%.

Cold start comparison (numbers reported as of May 2026):

| Runtime | Cold start |

| --- | --- |

| AWS Lambda (Node) | ~350ms |

| Cloudflare Workers (JS isolate) | ~5ms |

| Fastly Compute@Edge (WASM) | `<1ms` |

| Wasmtime + pooling | ~50µs |

| WasmEdge AOT | ~30µs |

Chapter 20 · Polyglot Demo — Component in Rust, Called from JS

This chapter shows the Component Model in action. The WIT is the same greeter from chapter 3.

Rust implementation (`src/lib.rs`):

wit_bindgen::generate!({ world: "greeter", path: "./wit" });

use exports::example::greeter::api::{Counter, Guest, GuestCounter};

use std::cell::Cell;

struct Component;

impl Guest for Component {

fn greet(name: String) -> String {

format!("Hi, {name}!")

}

type Counter = CounterImpl;

}

struct CounterImpl(Cell<u64>);

impl GuestCounter for CounterImpl {

fn new() -> Self { Self(Cell::new(0)) }

fn increment(&self) { self.0.set(self.0.get() + 1); }

fn get(&self) -> u64 { self.0.get() }

}

export!(Component);

Build it and call from JS:

cargo build --target wasm32-wasip2 --release

wasm-tools component new target/wasm32-wasip2/release/greeter.wasm -o greeter.wasm

jco transpile greeter.wasm -o out --name greeter

node -e "import('./out/greeter.js').then(m => { const c = new m.api.Counter(); c.increment(); c.increment(); console.log(m.api.greet('JS'), c.get()); })"

The very same .wasm runs unchanged on Spin, wasmCloud, and the Wasmtime CLI. Polyglot is not a slide deck; it is executable code.

Chapter 21 · WASM and AI — LLM Inference and ggml on WASM

This momentum took off in 2024.

- **WasmEdge + llama.cpp (ggml)** — inference of Llama 3 8B from a single .wasm. A 1MB .wasm autodetects GPU/CPU backends.

- **wasi-nn** — WASI's ML interface. Unified surface for PyTorch, ONNX, OpenVINO, and TFLite.

- **Burn-wasm, Candle-wasm** — native Rust ML frameworks compiled to WASM.

- **Cloudflare Workers AI + WASM post-processing** — the model runs on Workers AI; a WASM component handles post-processing.

WasmEdge ggml's pitch is that **models ship in an OS- and hardware-independent way**. Drop the same .wasm onto Linux x86_64, macOS arm64, Raspberry Pi, or AWS Graviton and inference starts. That is a game-changer for embedded and edge AI.

Chapter 22 · LINE, NHN Cloud, Cybozu — WASM Adoption in Korea and Japan

In Korea and Japan, infrastructure and content companies are leading adoption.

- **LINE/LY** — evaluating WASM plugins in some messaging-backend sidecars, per their Tech-Verse 2024 talks.

- **NHN Cloud** — picked a WasmEdge-based runtime for the beta of its in-house edge functions, isolating user code on the Toast cloud edge.

- **Naver Cloud** — Naver Search and Smart Store explored WASM plugins for user-defined search post-processing (announced at DAN 2025).

- **Cybozu** — running an experiment to redesign kintone's plugin model on top of Extism in 2024-2025.

- **Sansan** — published a blog about migrating part of its business-card data pipeline to WASM components.

- **DeNA** — sharing common client/server logic for mobile games via Rust to WASM.

- **NTT Communications** — moved some node-side processing in its Smart Data Platform to WASM.

The common thread: WASM lands where **multi-tenant, plugin, or edge isolation problems** cannot be solved by containers alone.

Chapter 23 · Operations — Observability, Debugging, Deployment

As WASM has matured into production, observability has caught up.

- **wasmtime --profile=guest, --jitdump** — guest profiling that integrates with Linux perf.

- **WASI Logging (wasi:logging/logging)** — structured logs collected by the host and forwarded via OpenTelemetry.

- **wasi:observe (experimental)** — a spec for piping traces and spans from component to host.

- **Spin Trace + Fermyon Cloud Logs** — distributed tracing for Spin workloads.

- **wasmCloud + NATS Telemetry** — captures the in-lattice call graph as NATS metadata.

Debugging is still evolving, but in 2025 the combination of **.wasm with preserved DWARF debug info**, Wasmtime's `--gdb` mode, and Chrome DevTools' WASM debugger reached real-world usability. AssemblyScript and Rust emit good DWARF; Go still has gaps.

For deployment, pushing component .wasm files to OCI registries (ghcr.io, docker.io) and pulling them from Spin, wasmCloud, or Knative in a GitOps loop is the standard.

Chapter 24 · The Future — wasi-preview3, async/streams, wasi-gpu, wasi-threads

What's already on the horizon in mid-2026:

- **WASI Preview 3** — a spec accepting async/await as a first-class ABI. A late-2026 candidate is plausible.

- **Generalized wasi:io/streams** — unified async streams for every IO.

- **wasi:gpu (WebGPU on WASI)** — GPU compute as a capability. Decisive spec for ML inference and graphics.

- **wasi-threads** — multithreaded components. Currently experimental in Wasmtime.

- **Component ↔ Linux process model** — standardizing how a component maps 1:1 to a host process.

- The Bytecode Alliance's working groups are pushing these toward stability (Phase 4).

WASM is no longer a single spec but an IETF/W3C-style multilayer ecosystem governing interfaces.

Chapter 25 · Decision Tree — Which Runtime for Which Workload?

A practical guide to close.

| Workload | Recommendation |

| --- | --- |

| HTTP APIs at the edge | Fastly Compute@Edge, Cloudflare Workers, Spin + Fermyon Cloud |

| Sidecars in your own K8s cluster | WasmEdge + RuntimeClass, Spin + spin-operator |

| Distributed multi-cloud microservices | wasmCloud + NATS |

| AI inference (edge/embedded) | WasmEdge ggml, Wasmer + Burn |

| Plugins inside a host app | Extism |

| Concurrency-heavy services | Lunatic |

| Running user code (multi-tenant) | Wasmtime + epoch interruption + pooling |

| Layering on top of Lambda | Lambda Web Adapter + Wasmtime |

Four decision axes:

1. **Trust boundary** — does user-supplied code show up? If yes, WASM.

2. **Cold start** — do you need sub-millisecond? Then Fastly, Spin, or WasmEdge AOT.

3. **Language diversity** — polyglot? Pick Component Model first-class hosts (Wasmtime/Spin/wasmCloud).

4. **Operational model** — do you want K8s standards, or hand it off to a PaaS?

Answer those four questions and the tool almost picks itself.

Chapter 26 · Wrap-Up — Not "Post-Docker" but "Stronger Isolation on Top of Docker"

People ask whether WASM "will replace containers." The 2026 field answer is unambiguous: **WASM complements containers; it does not replace them**.

- Containers remain the best fit for OS-scoped isolation. Full-stack, OS-dependent, large workloads live there.

- WASM is the best fit for **function- and service-scoped isolation**. Untrusted code, multi-tenant plugins, polyglot ABIs, and edge workloads live in WASM.

The two coexist on K8s nodes. RuntimeClass routes workloads to the right runtime. Solomon Hykes's tweet was less "WASM would have replaced Docker" and more **"WASM can solve some of the same problems Docker addressed, with a different approach."**

These 26 chapters traced that different approach end to end. From writing one line of WIT — to that single line being implemented in Rust, Go, JS, or Python — to running unchanged on Wasmtime, Spin, wasmCloud, Fastly, and Cloudflare — the 2026 picture is a world where all of that happens at once.

> "Where does my code run, with what authority, and who composes it?" Answer those two questions clearly and you can carry the answer around as a single .wasm.

References

- WebAssembly homepage — https://webassembly.org/

- WASI homepage — https://wasi.dev/

- Component Model spec — https://component-model.bytecodealliance.org/

- Bytecode Alliance — https://bytecodealliance.org/

- Wasmtime docs — https://docs.wasmtime.dev/

- Wasmer docs — https://docs.wasmer.io/

- WasmEdge docs — https://wasmedge.org/docs/

- Fermyon Spin docs — https://developer.fermyon.com/spin

- wasmCloud docs — https://wasmcloud.com/docs

- Extism docs — https://extism.org/docs/overview

- JCO (JavaScript Component) — https://bytecodealliance.github.io/jco/

- wit-bindgen — https://github.com/bytecodealliance/wit-bindgen

- wasm-tools — https://github.com/bytecodealliance/wasm-tools

- Cloudflare Workers + WASM — https://developers.cloudflare.com/workers/runtime-apis/webassembly/

- Fastly Compute — https://www.fastly.com/documentation/guides/compute/

- AWS Lambda Web Adapter — https://github.com/awslabs/aws-lambda-web-adapter

- Docker WASM — https://docs.docker.com/desktop/wasm/

- Lunatic — https://lunatic.solutions/

- WASIX — https://wasix.org/

- StarlingMonkey — https://github.com/bytecodealliance/StarlingMonkey

- componentize-py — https://github.com/bytecodealliance/componentize-py

- containerd-wasm-shims — https://github.com/deislabs/containerd-wasm-shims

- Spin Operator (Kubernetes) — https://github.com/spinkube/spin-operator

- WasmEdge ggml plugin — https://github.com/second-state/WasmEdge-WASINN-examples

- Solomon Hykes tweet on WASM — https://twitter.com/solomonstre/status/1111004913222324225