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.
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.
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):
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.
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).
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)
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.
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.
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
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.
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 relate 100%. Everyone at my current job is sick of the soul-crushing work as a software developer that people just accept as part of the job. The side projects are so fun, we just want to do that for our real job.