brooksmtownsend

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.

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)

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