WASM-Native Orchestration | Hacker News Reader

WASM-Native Orchestration

wasmcloud.com

102 pointsfofoz63 comments

I feel like this landing page has so many buzzwords I don't quite understand what the application/project itself is, but I do understand it's universal, runs everywhere and can run anything anywhere.

Could someone who knows what it is, give a simpler description? Is it a OS/kernel? Runtime? Orchestrator? Self-hosted platform? Cloud platform?

k8s is for docker containers, this thing is like k8s but for wasm (and even uses similar apis).

Ok, so wasmCloud is like Kubernetes, but then I don't understand their tagline: "Build, manage, and scale Wasm apps across any cloud, K8s, or edge" or the "Run wasmCloud standalone or on Kubernetes" part.

Why would you want to run a orchestrator (wasmCloud) on top of another orchestrator (Kubernetes)? Are they competitors? No, then it wouldn't make sense to run it on Kubernetes, so that makes them complements?

You use k8s to manage the machines where wasmCloud runs, and wasmCloud to manage the WASM apps that run on top of it. That's at least my understanding.

And then you run QEMU-WASM[1] on that so you can run your Docker containers safely inside a Linux VM...

[1]: https://ktock.github.io/qemu-wasm-demo/

Gary was a visionary: https://www.destroyallsoftware.com/talks/the-birth-and-death...

As one of the co-founders of CNCF wasmCloud, I can say this talk was ABSOLUTELY an inspiration for what we've been working towards!

That's what people do in enterprises because they have security controls and processes around k8s with too much investment. It's a no-go telling people to "just run this binary on this VM/baremetal machine", understandably.

We've got a few examples on our website from users that (in my opinion) use wasmCloud more for its strengths as a distributed computing platform. Often there's central k8s infrastructure where wasmCloud runs and connects to wasmCloud hosts running on edge devices. https://wasmcloud.com/blog/2024-10-22-webassembly-adoption-t....

Me personally, I run all my side projects off of a wasmCloud binary on Oracle's always free tier instance and it's been pretty awesome.

Apparently something that can replace docker or build on top of it. Buzzword here once again.

It's a grift as far as I can tell.

Question for everyone - I've long wondered if it would be possible to use WASM to create a p2p "cloud" to reduce reliance on datacenters?

My thought would be to encrypt all data packets prior to shuffling them into the network, and have some sort of incentive for people to keep their devices running on the network to enhance reliability - probably with a blockchain of sorts that serves as the main "map" of content in the network.

The dream goal would be to create a digital "data cooperative" that enables opt-in selling of your data/usage habits, with a default setting of total privacy. Ideally this would be backed by the blockchain to close the loop on the incentive for usage.

Is there already something like this that I'm not aware of? Are there any areas of research I should look into?

You mean like BOINC? But with crypto?

You can't trust third party compute.

Perhaps we could:

https://en.m.wikipedia.org/wiki/Homomorphic_encryption

Someone far smarter than me could probably tell us if this actually works in the real world?

Maybe, but are you saying that you could perform an operation like "if string startswith("www") then ..." without decryption? That sounds enormously complicated.

And even so, it would be leaky, because you could follow the execution path and deduce things about the data.

So in summary it sounds implausible, but I may be wrong.

yes it's certainly possible. i don't know if it exists but there are many things like it. not exactly what you describe, but many blockchains use wasm as the contract execution runtime. also, it kind of sounds like filecoin but with compute. i'm sure "protocol labs" has a project close to what you are talking about.

edit: the hard part to note is probably the "trust" part. might be trickier to solve than just giving incentives.

Thanks for putting me on to Protocol Labs! It's a wealth of super cool projects.

Protocol Labs here — are you familiar with Fluence or Bacalhau projects? Those might be good starting points.

Thank you! So glad you responded, Fluence seems to be very much along the lines of what I'm thinking.

Is there a good entry point to understanding the project that you can recommend? The website is drenched in crypto-speak, and I'm very much outside of that community. Just looking for an overview/white paper to be able to get my bearings before digging deeper.

You would need Middle-out compression for this to scale. Lepton from Dropbox uses Middle-out to compress jpg images.

I believe this is what the Spritely Institute (https://spritely.institute/) is working on with Spritely Goblins (distributed computing using object capabilities) and Hoot (Scheme to wasm compiler).

The new freenet has some interesting ideas related to this in the form of "contracts" and "delegates", which are essentially distributed WASM programs with their own memory. It sounds a lot like what you're describing: https://docs.freenet.org/components/contracts.html

pretty sure https://taubyte.com does just this

Too much marketing fluff on the website. How about showing simple example as how is it easier or useful to deploy some service to fly.io , AWS or GCP or maybe a Postgres deployment to Digital Ocean, Render or whatever. I want to use it but before I want to know how can I move my dependency from managed XYZ and easily run/manage my own deployment of databas, services.

It sounds obvious when you say it, and I appreciate the feedback! Marketing fluff is nice for messaging, but we'll take a look at getting comparison examples more front-and-center.

Hey! I’ve been a maintainer of wasmCloud since 2019, I’m glad it sparked some interest and I appreciate the time spent going through the docs and QuickStart.

I’ll have to take another look and answer questions when I’m at the keyboard tomorrow! Appreciate all the feedback here, it’s really helpful to hear the fresh perspectives

(I see in the comments that more people have similar concerns)

ELI5 why is this not a solution looking for a problem? Not even this particular project, but WASM as a platform in general.

My point of view is that contenerization is the final step in reaching the "serverless" nirvana. Having a Docker (or similar) solves a platitude of problems, everyone develops in the same environment, deployment is fully reproducible and isolated, and so on.

I'm not a fan of pure "serverless" solutions as they hide too much moving parts inside a magic box.

Why is WASM seen as the next step?

Since you're asking for WASM in general.

How do you run a Python program using docker in the browser?

How do you run a Ruby function from a Scala library with docker?

You might be thinking that container is similar to a VM, but it is not. WebAssembly is suppose to be something akin to a universal “web ISA” (Instruction set architecture with its own assembly instructions, thus, “WebAssembly”) which all modern browsers support. This means that technically, one is able to compile a binary once and run anywhere, something that is not entirely possible with containers.

Containers take seconds to start so a container must always be running. Wasm starts in microseconds and most Wasm platforms scale to zero by default because they do not suffer from cold starts.

Wasm also offers incredible density characteristics. The same application hosted in a container has a much larger footprint than the Wasm equivalent, ~hundreds of MBs to GBs compared to a typical Wasm app that is typically <10MBs and often KBs. Wasm is based around a linear memory model such that it supports binpacking by the runtime. Where a system may be able to run hundreds of containers, thousands of Wasm instances can be run by a single Wasm runtime.

The typical cost savings for using a Wasm-based serverless platform vs a container-based one is significant. This is dependent on the language and workload, but I generally expect +30% efficiency.

Containers are not secure by default and are generally not considered an appropriate sandbox. Wasm was designed to run in the web where sandboxability is a critical requirement and first principle of the design. For serverless, this means a single Wasm host may be multi-tenant. This is why Fastly, Shopify, and Cloudflare use Wasm for serverless workloads ($$$ + safety).

On the magic box concern, Wasm is pretty different from the other serverless approaches (isolates, BEAM, JVM-based, etc) that can be a bit more “magical”. A Wasm component can be inspected prior to compilation, the binary itself is a declarative definition of the capabilities needed to run as function imports. Those imports are standardized via WASI. This is one of several reasons why a Wasm binary is more portable than a container where it can run on any CPU architecture, operating system, and environment with different capabilities.

From a local development perspective, it’s so much easier to use a Wasm component that uses interfaces like the blobstore. For development I can use implementations I have in my local dev environment, e.g. a local FS, but in production I can use the same abstraction to connect to S3. This gives you serverless without requiring the entire services stack.

I've been developing on top of wasm (wasmtime, specifically) for several years now.

I personally have my doubts about how broadly the components specification (which this cloud platform seems to depend on) will be adopted. Maybe I'm just not very smart, but it feels like one of the things I loved the most about WebAssembly, its simplicity, is being lost.

To get even basic things done with WASI, you now have to figure out which flavor to pull in (preview 1, preview 2, ... need any async [0], that's coming preview 3?), learn a new IDL language [1] that defines the component's spec, figure out its codegen toolchain [2]. It's all very reminiscent of COM, CORBA and all the other times this has been tried in the past.

In any case, wasmtime is an amazing project and I'm grateful for it. They've already had to bifurcate the library to support WASI and components. I just hope non-WASI/component code retains its status as a first class citizen in the project.

[0] https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i... [1] https://github.com/WebAssembly/component-model/blob/main/des... [2] https://github.com/bytecodealliance/wit-bindgen

Thanks for your feedback. Components and WIT seem powerful to me, though. I'm building an execution environment on top of a niche programming language, and components allow me to easily extend it with libraries written in other programming languages without having to link my application against anything and use FFI.

To start with a bit of project history, we love Wasmtime and that’s our core runtime of choice! Before wasmCloud 1.0, e.g. from 2019-2023, we only used Wasm modules with our own custom ABI. Literally everyone was doing this at the time, to run Wasm you either needed to adopt a platform with a custom ABI or invent it yourself and re-solve all the same problems. The component model and its canonical ABI was a huge opportunity for us to stop maintaining our own and integrate into the ecosystem; now you see examples in projects like Moonbit which just work with wasmCloud out of the box, huge win for us https://www.moonbitlang.com/blog/component-model.

On the WASI side itself, I understand that moving WASI from p1 to p2 was a big but necessary leap. Everyone wanted sockets and HTTP and there was no easy way to rev the monolithic ABI of preview1 to add what was needed in small increments. That’s why you see adapters to move from p1 to p2, which wrap a Wasm module with component metadata, but a component actually just straight up contains the module (you can see it if you look at the textual representation.) We’ll have the same thing from p2 to p3. Not to mention, some systems that don’t support the component model like in Node.js actually “unbundle” the inner module from the component and that works just fine. So from what I understand, module support will never be dropped.

Oh, and though WIT can be in-your-face in these tutorials (as we try to leave a good offramp for folks to customize beyond the quickstart) WIT shouldn’t be necessary for most common use-cases. There are standardized interfaces that language toolchains may support out-of-the-box, e.g. TinyGo supporting wasi-cli by default with the wasip2 target. If you use the SDKs in wasmCloud or Rust crates like wstd, then the interfaces are selected automatically since they’re being used behind the functions in the SDK itself. It’s meant to be lower level and handled by toolchains and library developers.

Mh... I would be most interested in how this could be used for running a local-first software infrastructure cloud. Does anyone has maybe some infos in how it could be used in that way ?

Unless you're shopping for something that is wasm-centric, almost certainly the thing you want is openstack[1] (or possibly Apache CloudStack but I doubt it)

1: https://www.openstack.org/

Being similar to Kubernetes is nice and makes sense if your audience is familiar with Kubernetes but I can't grasp the advantage over Kubernetes. If you have to run agents on machines and pull artifacts from OCI registries, why not pull containers?

I can see clearly what you lose but not what you gain.

Their entire site seems to be "you want to run WASM apps and we're a great way to do that". But do I want to run WASM apps? Does anyone?

These people do https://landscape.cncf.io/?group=wasm

What I'm saying is that running WASM isn't an objective in itself. Just like running containers. Their site should tell me why I want to run WASM because I don't think I do.

Also your page is a list of things that support WASM, not ones that prefer or even value WASM (especially WASM outside the browser...)

Wasm gives lots of benefits and as a project in a new-ish ecosystem we like to tout it and our goals as being a Wasm-native orchestrator. I think in general though nobody should care about running Wasm at all, just like you shouldn't really care about running containers. The goal is to write code and then ship it, the unit of compute is irrelevant. All that being said obviously Wasm isn't a drop-in replacement for containers, but we're working on more and more use cases where you can use them instead. As a developer I don't want to worry about base containers and vulnerabilities outside of my code and cross-compilation and then have to think about Kubernetes of all things at the end of the day

> Wasm gives lots of benefits

Again, such as what?

And if that is true, why aren't some of them listed on the site? Instead of listing the advantages of wasmCloud compared to wasm no-cloud?

We actually used to start with a Wasm-first perspective by focusing on explaining what Wasm is before focusing on our value props. This is good feedback though, we should call these out with more in-depth resources for learning.

To name a few Wasm benefits: - Starts in microseconds, so we scale to zero - Isolation, Wasm can’t reach outside of its memory - Polyglot - Eliminates language silos - Capability-driven security (granular secure-by-default)

Oh man, we have struggled with this- and I wrote the copy under the Build / Compose / Run tab to try and surface what we felt were the most salient points.

For WebAssembly Components- we have tiny, portable code, with a standard ABI that lets us compose between languages. For execution, 50 ns start time means that you can start on demand 'with no cold starts'; the converse is true - scaling to zero.

Because you can scale it and run it only when you need to you can be more reliable (run it in more places) while still operating in a cost efficient way.

It's a subtle story that can be hard to communicate. Thank you for the feedback, we're always trying to do better.

I've seen this project pop up two or three times in the last few days. I'm really excited about this and wasm in general and spent last night working through the docs page (https://wasmcloud.com/docs/intro/).

I set up hello world in TS, Rust and Go and went through the happy path of saying hello world. That was a really nice and encouraging dopamine hit.

My biggest critique is once you need to go any further and turn hello world into even something pretty small but useful, the wheels fall off fast. Almost immediately after the "ooooh cool" of creating a hello world container with `wash dev` and seeing it on port 8000, which was my favorite part, things started to get weird.

After the tutorial introduces `wash dev`, a sort of create-react-app for wasm that bootstraps the project, generates a ton of boilerplate and generates a hot-reloading server, the tutorials immediately introduces `wash up` and `wash ui`. I figured out `wash ui` is an admin dashboard of sorts. Why can't I just have admin dashboard as an option in my hosting command like `wash dev --dashboard=true`? It never really explains why I want `wash up` vs `wash dev`, where they differ, why they differ and why each exists. The `wash up` experience is much more clunky and, to be honest, I'd really just want to keep going with the same command that was working for me like `wash dev --dev` and then `wash dev --prod` with a heavy emphasis in the tutorial on the difference for each as it's really not clear.

Confusion aside, the project seems very optimized for everything up to `wash dev` and then gets weird after that. I originally tried to create three components: hello-go, hello-rust and hello-ts. I used `wash new component hello-{lang} --template-name hello-world-{language}` and it created a sub-directory for each component. Each sub-directory looks like it's own self-contained universe and it is not _at all_ clear how to get each component invoking other components (which is heavily emphasized as one of the killer apps throughout the introduction page). Furthermore, the `wash dev` command seems to only work within a single component. It is not clear how, if at all, I can run `wash dev` in the main directory and rebuild each component in its sub-directory (how I would like this to work). Also, it seems like each component's `.wadl` defines the component behavior (the url via spec.components[http-component]) but I don't want to think about each individual component, I really want to have one infra definition in root that defines the behavior of every component (particularly the spreadscaler and http address).

There are no examples for anything beyond super-trivial /get of hello world. Could you show a post? Can I run multiple components on different routes? What about different components on different ports? If the intent is to run a "super lambda" that handles all traffic and routes internally, at least show that as an example.

Finally after a lot of digging, I found a link to a multi-component example (https://github.com/wasmCloud/wasmCloud/tree/main/examples/ru...) which introduces a half dozen new tools and commands not discussed anywhere in the tutorials and introduces a ton a clunky steps. In my head, I was thinking about all the steps in a Github Action runner I would need to make this seamless and just thought...this ain't it.

Also, about half way through the docs make a throwaway reference to hosting with Wasmtime and JCo....wat? I thought the point of the wash tool was to take me from dev on localhost to hosting in production. Is it not? If not, make that _very clear_ in the docs.

To be clear: I _REALLY_ want WasmCloud to be successful. A lightning fast (virtually cold-start free) self-hostable, serverless function platform is my dream. I would love nothing more than a platform where I and/or a small team could write functions in Go/Rust/JS/TS/Python, bundle and deploy them to a serverless platform we host. It's even better that this platform out of the box provides support for metrics, monitoring, logging and tracing. The first article I read about you a few days ago I jumped out of my chair in joy that my dream was finally coming true. While I didn't dig into it too much, it seems the platform also provides idioms for distributed systems (some mechanism to distribute load across self-organizing hosts on different machines). The reality is more rough and after using it, it's not clear if I misunderstood what this project is and was confusing it for something else or if it just needs more polish and DX focus.

I am rooting for you so much and wanted to give this feedback as I can't think of anything better than a self-hosted cold-start-less distributed serverless function platform but the rough edges would mean either I incur a ton of CI automation to smooth the rough edges, or I just keep watching this project before adopting.

First off, thank you for the thoughtful feedback here, it’s great to hear you’ve found the docs useful!

I’ve read through your feedback and captured issues in our issue tracker for future improvements that will definitely go a long way towards making the experience better.

One particularly sticky point we’ve been working on is keeping our examples down-to-earth while still showing off the benefits. Everyone understands the CRUDdy HTTP -> Keyvalue microservice, and I think we have a tendency to overindex on that. What you mention about component composition as a strength and something that requires more tools and automation is a big opportunity for us.

Got a few issues started on this topic but many more to come (and please feel free to file more with questions):

https://github.com/wasmCloud/wasmcloud.com/issues/838 https://github.com/wasmCloud/wasmcloud.com/issues/839 https://github.com/wasmCloud/wasmCloud/issues/4129

Instead of a Postgres example, how about SQLite ? And it could be used to demonstrate the filesystem API/WIT.

I don't see the advantage of this over simply using kubernetes and the Kwasm Operator which adds WebAssembly support to Kubernetes nodes. No need for yet another flimsy later of abstraction.

Maybe after 5-10 years it will be mature enough to support many k8s features out of the box and can then replace k8s itself. But it is very far from that currently.

I’ve never used wasmcloud, but they claim the following advantage over k8s on this page: “Leverage WebAssembly components to extend Kubernetes and distribute applications across clouds, regions, clusters, and edges.”

I think they use NATS.io to include “edge” services, which is something that is challenging to do in a single k8s cluster.

I don’t think they are trying to replace k8s, but instead are solving a slightly different problem, which is attempting to build something somewhat like k8s, but with very different networking and security constraints.

One of the principles we do our best to follow as we build wasmCloud is the idea of "compatible with, but not dependent upon", and to that end we do in fact integrate very nicely with Kubernetes.

A recent blog post highlighted some of the work we’ve done to provide a Kubernetes Operator for wasmCloud: https://wasmcloud.com/blog/2025-01-09-wasmcloud-operator-bri...

This will provide you an equivalent experience to what you might expect from Kwasm, with the major difference being that you will not need to change the underlying Kubelet in any way while still getting the benefit of being able to deploy WebAssembly components natively on Kubernetes.

What are some real life use cases for this, instead of let's say edge functions or durable objects etc?

This is an abstraction on top of edge functions. So you do not have to tie into a provider like Cloudflare. At least that is suggested.

An orchestration engine like this will replace k8s one day. Kubernetes is great for enterprise development, but just too knowledge intense to get most out of it.

I think it starts to be interesting because wasm modules are so lightweight it opens interesting ways of orchestration.

Each node can easily have copy of every deployed module.

Having modules locally means you can skip network and just call functions in memory directly.

Startup time is also tiny.

Scaling by replication is so efficient that it becomes a whole new thing (on demand, extremely high upper limits, write easy serial code everywhere and scale it for concurrency).

etc.

The whole thing is lightweight and performant enough that it could as well be part of OS.

Looks like early days of the future and like people say has potential of dethroning docker.

K8s will probably eventually have first class support for wasm but it may not dovetail so much with their current setup.

If they don't keep up somebody else is going create wasm orchestration that takes advantage of that and this wasm-native orchestration seems to be doing just that.

Ie. this "link" type looks like wasm linking, it's a bit like dynamic linking of libraries for native apps.

I'm reading docs and barely following what actual mechanism is involved to enable any of the stuff they are selling. Am I correct in reading that this is like a modern version of the JVM with WASM in place of bytecode? So I can compile Python or Go or whatever into WASM and wasmcloud provides a portable runtime? So instead of packaging an entire containers worth of OS primitives, it's runtime with an API?

yes

there are couple of things also

ie. wasm modules can be published and consumed to/from oci registries, which is nice

this linking is interesting also - ie. in docker you don't dynamically load other container to import functionality, but with wasm you can and because they're small you can architect your system around independent modules that use each other directly

they use nats for comms

and you can probably run your orchestrated system in browser - may sound silly but it's interesting capability as well

Yes, just like you could do with CLR back in 2001.

"More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET. "

-- https://news.microsoft.com/2001/10/22/massive-industry-and-d...

Same old, sold with a rebranded package.

While edge functions and durable objects are both excellent examples of technologies that could be built using wasmCloud, they are (assuming we’re talking about either a CDN provider like Cloudflare, Fastly, Akamai or Cloud providers like AWS, Azure, GCP) not readily available in many environments.

An example brooksmtownsend linked to elsewhere in the thread is an industrial use case where one of the wasmCloud adopters is shipping a device running wasmCloud (and thus their Wasm components) locally within an industrial site: https://wasmcloud.com/blog/2024-10-22-webassembly-adoption-t...

So from a deployment perspective, not being tied to the public cloud/internet availability in general is a huge benefit.

But beyond deployment, due to the way wasmCloud is designed with the concept of capability providers and components, you are able to write providers that can integrate with any other existing protocols, services, software or hardware to make them available for your WebAssembly components to talk to.

In essence, you use WIT (think Protocol Buffers, but for WebAssembly) to describe the interface you would like your components to be able to call, and then you fulfill the interface from the providers and code generate the “guest” (or client-side) of the calling code for your WebAssembly components.

This means that you are not locked-in to the services and API's of your edge function provider and your function is portable to any cloud or edge.

Thanks, this helps a lot to understand it, feels quite exciting indeed.

Taking a quick look around on their website it seems you can have them host for you or self-host but absolutely requires k8s. If I'm wrong, point me to the doc that shows you how to self-host without k8s and I'll officially be excited.

It doesn’t require k8s — you run their agent binary on multiple hosts and they all get connected. You can deploy the same agent in k8s also if you want.

Yep that's right, we do not require k8s. There's a ton of existing infrastructure into k8s so we try to make it apparent how you integrate there. The local CLI, wash, is an example of how we run locally, it's just a Windows/Mac/Linux binary and then the WebAssembly components are architecture/OS agnostic.

We use NATS to connect distributed hosts and manage distributed state (e.g. no etcd) so as long as you can connect the NATS servers you can run anywhere.

Before they advertise this, they might want to fix their wasm shell:

>> wash build

requires go version 1.19 through 1.23, got go1.24

OOPS. It is an error from tinygo. They hit some snags upgrading to Go 1.24

Reply on news.ycombinator.com