4 ms·

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

by firtoz 2y ago

stpedgwdgfhgdd 2y ago
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.
mirekrusin 2y ago
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.
- tootie 2y ago
  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?
  - mirekrusin 2y ago
    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
  - pjmlp 2y ago
    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-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001 https://news.microsoft.com/2001/10/22/massive-industry-and-d... Same old, sold with a rebranded package.
joonas 2y ago
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-telco-manufacturing-tech/#how-can-wasm-benefit-heavy-industry 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.
- firtoz 2y ago
  Thanks, this helps a lot to understand it, feels quite exciting indeed.

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

by firtoz 2y ago

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.

mirekrusin 2y ago

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.

tootie 2y ago
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?
- mirekrusin 2y ago
  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
- pjmlp 2y ago
  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-developer-support-for-microsoft-net-on-display-at-professional-developers-conference-2001 https://news.microsoft.com/2001/10/22/massive-industry-and-d... Same old, sold with a rebranded package.

joonas 2y ago

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-telco-manufacturing-tech/#how-can-wasm-benefit-heavy-industry 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.

firtoz 2y ago
Thanks, this helps a lot to understand it, feels quite exciting indeed.