Microservices and WASM, Are We There Yet?

### Overview At OpenGovCon, Will Christensen (Defense Unicorns) and Kingdom Barrett (Weaveworks) discuss their investigation into using WebAssembly (WASM) for microservices and Kubernetes operators. Motivated by defense and government environments requiring an Authority to Operate (ATO), their goal was to explore whether WASM sandboxing could decouple continuous delivery of business logic from rigid infrastructure compliance. The authors set out to determine whether the ecosystem is mature enough for production microservices, concluding that while WASM excels in browsers and shows significant promise, server-side and microservice implementations currently face severe developer experience hurdles, tooling limitations, and integration friction.

### Key Topics - **ATO and Continuous Delivery**: The speakers envisioned building a core Go-based Kubernetes operator that dynamically loads polyglot WASM modules. This approach aims to enforce strict security boundaries, logging, and compliance on the host operator while enabling developers to write sandbox-contained logic without triggering an entire ATO re-certification. - **WASM Constraints vs. Capabilities**: Core WASM enforces strict sandboxing: no unpermissioned network access, restricted filesystem visibility, and an absence of native high-level types such as strings across boundaries. Passing data typically requires manual memory management and byte-offset pointers. - **Ecosystem & Runtimes**: The presenters evaluated various runtimes and frameworks including WASI, Wagi, Wasmer, Wasmtime, Spin, Wazero, and WasmEdge (written in C++). They also examined Kwasm, a Kubernetes operator modifying container runtimes via `runtimeClassName`, though noting it requires privileged node access and is not production- or ATO-ready. - **Language Support Disparities**: Rust remains a first-class citizen with mature tooling like `wit-bindgen` to handle type conversion between 32-bit and 64-bit integers. By contrast, interpreted languages (Python, Ruby) require compiling the entire interpreter into the WASM module, lack dynamic linking, and struggle with native C extensions. JavaScript runtimes (Node.js and Deno via V8) handle string passing smoothly out-of-the-box.

### Technical Details & Limitations - **Compilers and Performance**: The speakers reviewed three common WASM compiler backends: Singlepass (fastest compilation, slower runtime), Cranelift (balanced, used in Wasmer and Wasmtime), and LLVM (slowest compilation, fastest execution). In Rust-to-WASM scenarios lacking optimized bindings, pointer handling and string passing can incur severe performance penalties (up to 20x). - **Threading and Deadlocks**: When executing Go-compiled WASM modules inside Deno via `syscall/js`, calling Go's HTTP module caused deadlocks by violating V8's single-threaded event loop. - **Debugging and Tooling**: Tracing WASM stack traces across runtime boundaries remains difficult across languages. Additionally, online examples frequently rely on WebAssembly Text format (WAT) or simplistic math functions rather than real-world string and network handling.

### Demo & Takeaways Will Christensen demonstrated a GitLab CI/CD pipeline running on a Linode Kubernetes runner. The pipeline compiled Go to WASM and ran it under Deno, showing successful string argument passing and an Urban Dictionary search. The speakers concluded that while core WASM technology is solid, microservice adoption is not quite 'there yet' due to poor documentation, lack of cross-language patterns, and threading quirks. They urged the community to contribute real-world examples, documentation, and tooling improvements.