Request for new sandbox project: Dapr SDK for WasmEdge

[alabulei1]

1. Describe how the Dapr community will benefit from this project? Please, describe one or more scenarios.

The dapr_sdk_wasmedge project is a Rust SDK for the Dapr project. It provides an easy way for Rust-based microservices in WebAssembly (Wasm) containers to interact with Dapr sidecars. For the Dapr community, the project enables lightweight microservices, based on Wasm containers, to be deployed in Dapr networks along side with Linux container-based microservices. This is particularly important for Dapr applications deployed on the edge cloud, edge networks, and IoT edge devices.

Compared with traditional Linux VMs and containers, Wasm containers have the following advantages when running microservices.

• Secure: Wasm is a standard-based and well-tested security sandbox. Compared with Linux containers, Wasm has a well-defined capability-based security model, memory sandbox, a much smaller attack surface, and a much simpler software supply chain.
• Fast: Wasm microservices could cold start in a few milliseconds, which is orders of magnitude faster than Linux VM or containers.
• Lightweight: the size of a fully featured Wasm microservice could be under one MB, which is orders of magnitude smaller than comparable applications in Linux containers.

The architecture image above may help understand this project.

2. Which programming languages will be used?

The Rust programming language will be used to develop the microservices. The compilation target of the Rust programs is wasm32-wasi.

3. Does the project have any hard dependency on other technologies or cloud vendors? Example: Kubernetes, Azure, AWS, Terraform

Yes. This project depends on WasmEdge, a CNCF hosted WebAssembly runtime. The dependency is due to WasmEdge’s support for non-blocking networking sockets and the Rust tokio framework, which are crucial for efficient communications between the microservice and the sidecar.

4. Enumerate the repositories this project will need to be created.

We need to migrate a repo called dapr-sdk-wasi from second-state (the donor).

5. What is the ETA to have this project reach a stable version and graduate to the main Dapr organization?

Our goal for the dapr-sdk-wasi project is to support the entire range of Dapr APIs. We have successfully implemented the service invocation, state management, pub/sub, secrets and health APIs. We are still working on providing support for the bindings, actors, configuration, distributed lock, and metadata APIs. We anticipate that the project will reach a stable release by the end of 2023.

In line with the Dapr-Sandbox Graduation Request issue templates, our goal is to ensure that the dapr-sdk-wasi is used by at least three users, each deploying a unique scenario in production, before seeking to graduate to the main Dapr organization. We're confident that we'll be able to meet these requirements by 2024. and present a reliable and stable solution to the wider Dapr community.

6. Who are the maintainers of this project and corresponding employers?

Michael Yuan is responsible for the overall project and initial implementation of the service invocation API, state management API, secrets API, and health API.

Shreyas Atre is responsible for implementing pub/sub API, bindings API, actors API, configuration API, distributed Lock API, and metadata API. Shreyas is an independent consultant for Second State.

[codefromthecrypt]

Thanks for raising this. I made some comments below even though I'm not a dapr maintainer. While I work on wazero which is an alternative to wasmedge, I don't think the feedback is wazero specific. Hope it helps!

Does the project have any hard dependency on other technologies or cloud vendors? Example: Kubernetes, Azure, AWS, Terraform

Yes. This project depends on WasmEdge, a CNCF hosted WebAssembly runtime. The dependency is due to WasmEdge’s support for non-blocking networking sockets and the Rust tokio framework, which are crucial for efficient communications between the microservice and the sidecar.

Historically, dependencies that require CGO aren't actionable in dapr's main build. Since wasmedge requires native library installation on the host (accessed via CGO), this seems a non-starter even if it weren't also an interop issue.

Which programming languages will be used?

The Rust programming language will be used to develop the microservices. The compilation target of the Rust programs is wasm32-wasi.

A couple years ago, I think that a single language SDK of rust would make more sense. However, the primary programming language of Dapr is go. The current SDK is Go, and a wasm powered alternative should exist in Go source even if also in Rust or other languages like C. Late summer, Go supports WASI preview1 and TinyGo already does, so ruling in Go should be a requirement. This also reduces temptation to include non-standard crates or extensions to rust which only work with one runtime.

In other words, I think Go should be required as it not only allows a more fluid experience for maintainers and users, but it also avoids accidental lock-ins.

I'll stop at this, and in any case I think that end users (e.g. not second state employees or runtime authors like me) should pipe in about their experience and what they use it for. Ultimately things like this should be driven by users directly, especially since this is OSS.

My 2p!

[juntao]

Hi @codefromthecrypt

Thank you for the comments. However, the goal of this SDK is actually NOT to be part of the Dapr sidecar, which is where wazero fits in. 😂

Our goal is to have a SDK for microservices that utilize the Dapr sidecar. In another word, it is for microservice application developers who are Dapr users.

Here is a demo project that uses this SDK. It consists of 3 microservices to do image processing / AI inference etc, but utilizes the Dapr sidecar for service invocation and state management:

https://github.com/second-state/dapr-wasm

[codefromthecrypt]

@juntao thanks for the clarification.. so, this is another sidecar that talks to the dapr sidecar. I think this image from https://github.com/second-state/dapr-sdk-wasi could be lifted into the description, especially as there has been talk about an actually embedded (e.g. living in sidecar) way to access the dapr SDK apis.

I'll bow out, as this seems more like an ecosystem branding thing (moving repo without affecting dapr in any way). Cheers!

[alabulei1]

Hi @codefromthecrypt ，

Thanks for the kind suggestions. I will add the image to the proposal. Thanks!

[alabulei1]

@yaron2 I have renamed the project for WasmEdge. Thanks.

[yaron2]

Hi @alabulei1,

The Dapr STC has voted to approve this request for sandbox project. Congratulations. As a next step, we will create an org for you and invite you as a maintainer.

[alabulei1]

Hi @yaron2

Thanks. This is great news! We look forward to closer collaboration with the Dapr community!

Please let me know how I should proceed.

[yaron2]

@alabulei1 apologies for the late response, you will receive a notification this week to be invited to the dapr-sandbox org where you'll be able to move the SDK to. looking forward to it!

[alabulei1]

@alabulei1 apologies for the late response, you will receive a notification this week to be invited to the dapr-sandbox org where you'll be able to move the SDK to. looking forward to it!

Looking forward to it too!