Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM-Native Orchestration

wasmcloud.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: WASM-Native Orchestration

#51

Post by jcmfernandes »

zackangelo wrote: post #48

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…

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.

Re: WASM-Native Orchestration

#52

Post by joonas »

lenkite wrote: post #14

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.

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.

Re: WASM-Native Orchestration

#53

Post by joonas »

firtoz wrote: post #2

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

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.

Re: WASM-Native Orchestration

#54

Post by brooksmtownsend »

remram wrote: post #45
brooksmtownsend wrote: post #44

Earlier quoted context omitted.

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 co…

> 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)

Re: WASM-Native Orchestration

#55

Post by brooksmtownsend »

zeroq wrote: post #37

(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…

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 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).

Re: WASM-Native Orchestration

#56

Post by brooksmtownsend »

zeroq wrote: post #37

(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…

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.

Re: WASM-Native Orchestration

#57

Post by brooksmtownsend »

NewMountain wrote: post #13

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 tu…

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

Re: WASM-Native Orchestration

#58

Post by brooksmtownsend »

zackangelo wrote: post #48

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…

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.

Re: WASM-Native Orchestration

#59

Post by brooksmtownsend »

zackangelo wrote: post #48

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…

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.

Re: WASM-Native Orchestration

#60

Post by firtoz »

joonas wrote: post #53
firtoz wrote: post #2

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

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 adopte…

Thanks, this helps a lot to understand it, feels quite exciting indeed.
Post reply on HN