A holy grail of modern enterprise architecture is the separation of concerns between infrastructure and business logic code. Ideally, application developers want to focus on business logic and are not concerned about how to manage and scale applications. That is the “serverless” paradigm.
In cloud-native environments, a commonly used approach is service mesh. The service mesh allows application units, or microservices, to run in distributed runtimes or containers. These runtimes are also called sidecars. The service mesh also provides a data plane, or API proxies, to manage data in and out of the sidecar microservices, as well as a control plane to configure policies for the data plane.
As microservices become more modular and lighter on one hand, and take over more complex application logic (eg AI inference) on the other hand, there is a growing need for lightweight runtimes for both sidecars and data plane proxies to improve system performance and reduce resource consumption by the growing infrastructure. After all, it is absurd to spin up a Docker container and guest OS just to execute a microservice function that has 10 lines of code.
Lightweight runtime for sidecar microservices
For sidecar frameworks that support multiple application runtimes, we could simply embed WasmEdge applications into the sidecar through its C, Go, Rust, or Node.js SDKs. A good example is Dapr. We have a template project that showcases how to run WasmEdge microservices as Dapr sidecars.
However, widely used service meshes, such as CNCF’s Linkerd, uses Kubernetes to manage sidecars. To that end, WasmEdge provides an OCI-compliant wrapper for its WebAssembly runtime and supports network sockets in WebAssembly to listen for incoming API requests directly. That allows WasmEdge applications to be managed directly by container tools and act as sidecar microservices.
Lightweight runtime extension for the API proxy
The API proxy is another crucial component in the service mesh. It manages and directs API requests to sidecars in a manner that keeps the system scalable. Developers need to script those proxies to route traffic according to changing infrastructure and ops requirements.
Seeing widespread demand for this type of application, the community came together and created the proxy-wasm spec. It defines the host interface WebAssembly runtimes must support in order to plug into the proxy. WasmEdge is a WebAssembly runtime that supports proxy-wasm, enabling it to be used as extensions for Envoy, MOSN, and other proxies.
WebAssembly in service mesh is a fast-growing field in the cloud-native landscape. Just in the past 6 months, the CNCF accepted 3 WebAssembly projects into its sandbox — WasmEdge, wasmCloud, and Krustlet — with more on the way! If you are interested in these new technologies and their applications, meet us at the upcoming KubeCon and CloudNativeCon North America and Cloud Native Wasm Day. You can meet us in person in Los Angeles or online!