Can WebAssembly Replace Docker? Insights from a Dapr Live Session

On September 9, the Qingyun live room hosted Michael Yuan (WasmEdge maintainer and Second State CEO) for an online talk titled “WebAssembly – Dapr’s high‑performance execution environment”. He introduced WebAssembly and Dapr and showed how to use the CNCF sandbox project WasmEdge on Dapr to build Go‑ and Rust‑based sidecars that run WebAssembly‑implemented business logic.

Q1: Will WebAssembly replace Docker?

Answer: WebAssembly will not replace Docker because Docker virtualizes an operating system while WebAssembly virtualizes a process, operating at different layers. WebAssembly may replace Docker in scenarios where Docker is unsuitable but isolation is required, such as micro‑services, edge computing, and automotive workloads. In practice they run side‑by‑side, orchestrated by Kubernetes or Dapr.

Q2: Which large projects are using WebAssembly?

Many micro‑service and service‑mesh projects are evaluating WebAssembly. Production users include Fastly, Cloudflare, and Shopify. Interested readers can attend the Cloud Native Wasm Day at KubeCon North America to see how companies worldwide adopt WebAssembly.

Q3: How is memory managed in Wasm and is there a Dapr‑Wasm demo?

The source code for Dapr‑Wasm is available at https://github.com/second-state/dapr-wasm. Memory management in WebAssembly is complex; languages like Rust handle it at compile time, producing lightweight, high‑performance, memory‑safe code. WasmEdge also supports JavaScript, providing a runtime‑based memory manager when compile‑time solutions are unavailable.

Q4: Is WasmEdge pre‑loaded or forked each time, and can it limit CPU/memory?

In the Dapr scenario each sidecar is forked, leveraging WebAssembly’s millisecond‑level startup time compared with Docker’s second‑level latency. Isolation includes file‑system and network access controls, and static memory allocation can enforce CPU and memory limits. The “gas” model from blockchain can also bound instruction execution. Integration with Kubernetes via runw and crunw enables systemd and cgroup‑based resource management.

Q5: How does this differ from running a native process?

Running a native process requires explicit language choice and lacks the container‑like isolation, security, and resource management that WebAssembly provides. Without these safeguards, a faulty native application can crash the host system and affect other processes.

References

Dapr‑Wasm source code: https://github.com/second-state/dapr-wasm WasmEdge JavaScript support:

https://www.secondstate.io/articles/run-javascript-in-webassembly-with-wasmedge/

crunw project:

https://github.com/second-state/crunw