Create an example microservice using WebAssembly

[Gedochao]

• example microservice representative for a cloud-native app compiled from Scala 3 to WebAssembly
• fulfill performance requirements
  • cold start <100ms
  • response time for a running app <50ms
  • <100mb memory usage
  • <1mb used per thread
  • compiling and linking <10 minutes
• test under traffic typical for a business application

[tanishiking]

There are multiple ways to deploy Wasm applications in cloud environments.

deploy to JS environemnt

One approach is the one mentioned in this blog post, (mentioned by @tgodzik) where only the business logic of the application is converted to Wasm, while communication with external systems is handled by JavaScript.
This can be used with any FaaS that supports JavaScript, such as AWS Lambda, or platforms like Cloudflare Workers that utilize V8 isolates.

With this method, it is possible to achieve deployment using the current Scala.js Wasm backend. However, the I don't see advantages over deploying Scala.js applications compiled to JavaScript (instead of Wasm). Perhaps the Wasm part might be slightly faster or the binary size slightly smaller, but the differences would be negligible.

Server side Wasm

Another approach involves converting applications into stand-alone Wasm (also known as "server-side Wasm") binaries and deploying them.

Stand-alone Wasm binaries are independent of JavaScript and interact with the system (e.g., HTTP communication or file access) through the WASI.

In this case, we can deploy these binaries

• on Kubernetes using container backends like runwasi
  • see https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools
  • https://opensource.microsoft.com/blog/2024/09/25/distributing-webassembly-components-using-oci-registries/
• or CNCF projects such as wasmCloud.
• Alternatively, we can use cloud services like Spin.

Currently, AFAIK, cloud providers such as GCP, AWS, and Azure do not offer FaaS specifically designed for server-side Wasm. As a result, deployment on them requires using Kubernetes.

One significant advantage of this approach is that it avoids the cold start delays caused by hypervisor-based OS startup, which is typical in environments like Lambda [1].

[1]: Comparative Performance Study of Lightweight Virtualization Used in Serverless Computing

On the other hand, the challenge lies in the fact that our current implementation of server-side Wasm for Scala.js relies on WASI preview 2 (Component Model). Unfortunately, the implementation status of this proposal in VM runtimes is still incomplete, and there is no VM at present capable of running our applications properly.

• wasmtime: Supports the Component Model but lacks support for Exception Handling.
• wasmedge: Supports Exception Handling but lacks support for the Component Model.

---

It comes down to two possible approaches we can take:

• Use the current implementation to build applications for JavaScript environments (however, I don't see much value in this approach).
• Although it will take time, continue working on the server-side Wasm implementation with the goal of deploying it to environments like Kubernetes. Over time, VMs are likely to implement both the Component Model and Exception Handling 🤞