WASM Cloud

What is WASM Cloud trying to solve?

Lets ask - what a typical “Development Iteration” look like?

1. Start of with your Napkin Drawings - conceptual vision of what is it you want to build
2. Initial Prototype, prove that it works
3. Then, Figure out how to scale

The challenge is between #2 and #3 there is more often a complete rewrite. As the author claims- Virtually nothing from prototype is written in a way it is scalable.

The goal of the project is to “Ship Napkins to Production” directly.

1. Draw your conceptual map of how your application should look like
2. Fill in the blanks with your business logic and just push it - boom!!
3. Don’t worry about any of the non-sense in between.
4. Remove all the boiler plate and let developer write only Business logic.

How is this achived?

Using the “Actor Model” and the out of the box boilerplate infrastructure. Personally, I a fan of Actor Model, as its easy to just write a function which has a single responsibility. If you have ever worked with Threads and IPC(Interprocess communication) - you would know the overheads that come in managing them. With the Actor model you have an input queue, an output queue and the function in between. Developer shall write only the function. Function would read from the input queue, process and write it to the output queue. The infrastructure should take care of running the actor, as a thread or process and also manage the input/output queue, data transfer, serialization etc. One of the popular implementation of Actor model is AKKA.

From the authors:

The creators of wasmCloud believe that we can not only change the way developers build software for the better, but make it easier to secure, deploy, maintain, observe, and upgrade that software as well–all while reducing the amount of boilerplate we have to copy and paste.

Example:

Lets look at their Hello World example.

Interesting snippets:

    #[derive(Debug, Default, Actor, HealthResponder)]
    #[services(Actor, HttpServer)]
    struct HelloActor {}

    /// Implementation of HttpServer trait methods
    #[async_trait]
    impl HttpServer for HelloActor {
      //Actual Impl
    }

• HelloActor is the name of your actor
• The two lines with “#” above the actor name igenerate - at compile time - nearly all of the scaffolding needed to build an actor.
• The HealthResponder term generates a function that automatically responds to health check queries from the wasmCloud host.
• The #[services(…)] line declares the servicesthat your actor implements, and generates message handling code for those interfaces.
• All actors implement the Actor interface.
• The HttpServer entry declares that the actor will also implement that interface, and requires an implementation of that trait’s method: handle_request.

Conclusion:

I am fan of distributed computing: designing and writing scalable application. Maybe the concept of wasmCloud doing the heavy lifting sounds easy; but I belive its a very hard problem. Coz: when we actually get our hands dirty with actual application design - challenges like: managing states, versioning, schema management/registry, idempotency, trade offs w.r.t CAP theorm, heterogeneous system etc..all comes in. Also, given what Docker + Kubernetes eco system already provides - finding the right architecture to use wasmCloud would be a challenge. But this is definitely a place lot of things can be improved and room for optimization. Star’ed the project for now, will be following it closely.

Reference: WASM Cloud, GitHub