WASM Components: The Quiet Standard That's About to Eat Microservices

Containers won. That argument is over. A decade ago the question was whether you'd ship a VM or a container, and the container won so completely that “deploy” and “push a Docker image” became the same sentence for most teams. Kubernetes ate the orchestration layer, and the whole industry standardized on shipping a slice of Linux with your code stapled to it.

Here's the thing nobody wants to say out loud. The unit we settled on is enormous. A container that runs 200 lines of business logic still drags a userland, a package manager, and a base image that's measured in hundreds of megabytes. It boots in the hundreds of milliseconds. It has ambient access to a kernel it mostly doesn't need. We got used to it because the tooling is great and the abstraction is familiar, not because it's the right size for the job.

The next unit is smaller. It boots in microseconds. It can only touch what you hand it. And almost nobody is calling it a container, because it isn't one. It's a WebAssembly component, and the standard under it, the Component Model plus WASI Preview 2, just crossed the line from “interesting” to “in production at Akamai and American Express.” I want to make the case for why this is the quiet story of cloud infrastructure right now.

This is not the “Wasm in the browser” story

Let me clear the obvious confusion first, because WebAssembly still reads as “that thing that runs C++ in a browser tab.” That was the first act. It matters here only as proof that the sandbox and the bytecode format are solid. The second act, the one that eats microservices, is entirely server-side, and it rests on two pieces most people have never heard of: the Component Model and WASI.

Plain Wasm modules are sealed boxes. They speak in integers and linear memory. A module can export a function, but if that function wants to hand you a string or a struct or a list, the two sides have to secretly agree on a memory layout, and nothing in the spec enforces it. That's fine for a single self-contained blob. It's useless as a way to compose software out of independently built parts.

The Component Model fixes exactly that. It adds an interface-type system on top of core Wasm, so a component declares in a typed contract what it imports and exports: records, lists, results, streams, all of it.^[8] Two components compiled from two different languages can call each other through that contract without ever agreeing on a memory layout. A Rust component can hand a typed record to a Go component and it just works, because the ABI is the standard, not a private handshake.

WASI Preview 2 is where it got real

A component that can only talk to other components is a nice toy. To do real work it needs to reach the outside world: sockets, HTTP, clocks, files, environment. That's WASI, the WebAssembly System Interface. And the version that matters, WASI Preview 2, shipped as WASI 0.2.0 on January 25, 2024, built entirely on the Component Model.^[1]

Preview 1 was the old thing, a POSIX-flavored flat API that tried to look like a stripped-down libc. Preview 2 threw that shape out. Instead of one big syscall surface, it defines domain worlds: wasi-cli for command-line programs, wasi-http for request/response services, wasi-sockets for raw networking. Each world is a typed set of interfaces the host grants explicitly. Your component doesn't get a filesystem because it exists. It gets a filesystem because the host handed it one.

That inversion is not a small thing. The default security posture of a container is “can do almost anything, please configure seccomp and AppArmor and drop capabilities to lock it down.” The default posture of a component is “can do nothing until the host wires an interface into it.” For anyone who has spent a weekend auditing what a base image can actually reach, that flip is the whole reason to care.

The numbers are the argument

I'm allergic to infrastructure hype, so let me put the case on the numbers instead of the vibes. A Wasm component typically cold-starts in microseconds to low milliseconds, commonly cited as 10 to 100 times faster than a container. A lightweight module lives in single-digit megabytes of memory where the equivalent containerized service wants tens to hundreds. That is not a rounding-error improvement. That is a different order of magnitude on the two costs that dominate a serverless bill: how fast you can start, and how much memory you hold while you run.

Cold start is the one that quietly kills serverless economics. If starting a function takes 300ms, you keep instances warm to hide it, and warm instances are just servers you're renting to do nothing. Kill the cold start and you can actually scale to zero and back without the user feeling it. Microsecond starts make “spin up a fresh isolate per request” a reasonable thing to do instead of a thing you architect around.

And the cost shows up in real migrations, not just benchmarks. One reported move took a Kubernetes batch process handling tens of thousands of orders, rebuilt it as Wasm components, and cut compute cost by 60 percent with no loss of performance. Sixty percent is the kind of number that gets a platform team a meeting with the CFO, and it comes from the same place every time: you stopped paying to run a Linux distribution around every little piece of logic.

WASI 0.3 fixed the thing that was actually holding it back

For all that, WASI Preview 2 had a real wart, and if you tried to build something serious on it you hit it fast: async was bolted on. The Component Model didn't have a native notion of concurrency, so anything asynchronous went through an awkward start/finish/subscribe polling dance layered on top of a wasi:io package full of pollables and stream handles. It worked, but it was the kind of thing that leaks into every interface and makes people write “we're watching this, not adopting yet” in their architecture docs.

That's the wall WASI 0.3.0 knocked down. It shipped on June 11, 2026 from the Bytecode Alliance, and it puts async natively into the Component Model.^[2] Concurrency becomes first-class through stream<T>, future<T>, and async func right in the type system. The old start/finish/subscribe pattern is gone. You describe a streaming interface as a stream in the contract, and the runtime handles the plumbing.

The part that made me sit up is that WASI 0.3 deletes the wasi:io package entirely. Pollables and input/output streams don't live in a separate library anymore, they fold into the Component Model's canonical ABI directly.^[2]And the model underneath is completion-based, the same shape as io_uring on Linux and IOCP on Windows, rather than the readiness-polling model it replaced. If you've done systems work, completion-based async is the design you actually want at scale, and seeing a portable bytecode standard adopt it is a real signal the people building this know what production looks like.

The runtime story is tracking right behind the spec. Wasmtime 45 already runs the WASI 0.3.0 release candidate, and Wasmtime 46 is set to ship WASI 0.3.0 with Component Model Async enabled by default.^[2]Once async-by-default lands in the reference runtime, the “we're waiting for it to mature” excuse gets a lot thinner.

Who's actually running this

This is the part that moved it out of the “neat standard” column for me. Standards are cheap. Production traffic is not. And there is now real production traffic.

Start with Akamai and Fermyon. Fermyon built Spin, the WebAssembly runtime and developer tooling, and on December 1, 2025 Akamai announced it was acquiring the company and folding server-side Wasm FaaS into its edge network.^[3]That's a CDN with real scale deciding that Wasm components are how it does compute at the edge, not a science project. Fermyon Wasm Functions on Akamai reached general availability and scale to 75 million requests per second across edge and cloud, demonstrated live at KubeCon 2025 assembling dynamic content for a mock e-commerce site.^[4]That's running on Akamai's footprint of over 300,000 servers across roughly 4,300 points of presence.^[4]

Then there's wasmCloud, the CNCF runtime built around the component model. It was accepted into the CNCF on July 13, 2021 and promoted to Incubating maturity on November 8, 2024.^[5] Getting to Incubating in the CNCF is not a participation trophy, it means real adopters and a governance track record. And the marquee adopter is a name you know: American Express is building an enterprise, multi-tenant internal Function-as-a-Service platform on wasmCloud out of Wasm components, wrapping business logic in a security-decorator component and a platform component.^[6]To be fair about where it stands, Amex's platform had not yet reached production at the time of its 2024 to 2025 conference talks. But a bank architecting its internal FaaS around components instead of containers tells you which way the serious money thinks this is going.

And Spin itself keeps maturing as a product. Fermyon released Spin 3.0as generally available on November 11, built on the component model, adding “selective deployments” that let platform engineers repackage components into different microservice configurations without disrupting how developers work.^[7]Read that feature again. You take the same components and reshape them into whatever microservice topology you want at deploy time. That's a thing containers genuinely can't do, because a container is a fixed bundle, and it's the kind of composition the Component Model was designed for.

Docker isn't fighting this, it's hosting it

The reflex objection is “fine, but my whole world is Docker and Kubernetes, this is a rip-and-replace.” It isn't, and the reason is the smartest part of the rollout. Docker added native WebAssembly support through the containerd runwasi shim, so a WASI Wasm module runs with a plain docker run right next to your Linux containers.^[9] The shim supports multiple runtime backends: Wasmtime, WasmEdge, Wasmer, and Spin.

This is the adoption path that makes it real. You don't throw out Kubernetes. You schedule a Wasm workload the same way you schedule a container, on the same cluster, through the same control plane. The component just happens to be a hundred times smaller and start a hundred times faster. Migration stops being a bet-the-platform rewrite and becomes “swap one service and watch the bill.” That's exactly how containers themselves crept in fifteen years ago, one service at a time, next to the VMs, until one day the VMs were the exception.

Where this actually lands

Let me be honest about the timeline, because I don't want to sell you a revolution that's three years out. The standard isn't “done” yet. The WASI roadmap targets a WASI 1.0 and Component Model 1.0 release in late 2026 or early 2027, reached through a train of backwards-compatible 0.3.x point releases.^[10]So the version number on the box still starts with a zero. If your team's rule is “no zero-dot dependencies in the critical path,” you have a real reason to wait a beat.

But “pre-1.0” and “not in production” are not the same thing, and the whole point of this piece is that they've come apart. Akamai is serving 75 million requests a second on it. A CNCF Incubating runtime has a global bank building on it. The reference runtime is about to turn on async by default. The spec just cleared the one design problem, native async, that gave the cautious a legitimate reason to hold off.

The way I read it, we're at the exact moment containers were around 2014. The core idea is proven, the early adopters are in production, the tooling is rough in spots, and the people who move now are going to look prescient in three years. Containers didn't win because they were elegant. They won because they were a better-sized unit than the VM, and the industry eventually noticed. Wasm components are a better-sized unit than the container in exactly the same way, and the standard finally caught up to the ambition. I don't think it's a question of whether. I think it's a question of who notices first.