[candiddevmike]

I still don't understand the benefit of running a Go app on a cloud provider using this. Anyone want to help me?

Is it an edge play for using something like Cloudflare Workers?

Is it cheaper vs standard serverless/container deployments? Go apps can already scale to 0 for these use cases.

[viccuad]

It consolidates Go compiled to WASI as an alternative of doing containers. Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar.

There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine". Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us. We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm.

IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host.

The next step for the official Go compiler is to export the function symbols, to allow for WaPC.

[rockwotj]

How is the Universal Policy Engine different than Open Policy Agent?

[viccuad]

Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet!

In a nutshell, with Kubewarden we strive to build the universal policy engine by:

- Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone.

- This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference.

- Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc.

- Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc.

- Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows.

- Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc.

- Vendor neutral, CNCF project, open source, developed in the open.

[Thaxll]

As if WASI does not need specific architecture and kernel features?

[DanielHB]

Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.

[carbotaniuman]

WASI runners are just an application. I guess you need your kernel to run prograns and have syscalls, but that is a low bar.

[Thaxll]

Docker needs the 3.10 kernel which is 10 years old.

[est31]

It also needs root access, and 3.10 is only the lowest supported kernel. Not a docker expert but I could bet that they only support a subset of features there.

What I do know is that docker images are specific to the host architecture, supporting either one architecture, or a blessed list. wasm binaries on the other hand aren't. wasm can theoretically also run on bare-metal embedded scenarios without an OS entirely.

[mbertschler]

But it needs Linux, while wasm runtimes are available for all OSes natively

[dilyevsky]

It’s basically what jvm should have been but never delivered:

1. Could be an edge/iot play (tho not with standard go toolchain bc those binaries are huge and slow)

2. Trusted environment makes it interesting for all kinds of sbom-related usecases. Think weapons tech, space, etc

3. On the container side things are less clear to me but may offer better startup time, reduced footprint etc

4. Finally, for plugabble software it’s most interesting option personally. It’s basically 2.) but with focus on DX over security

[alecthomas]

I believe the primary benefit is the sandboxing, but I imagine there are secondary benefits such as that the host platform can be any CPU architecture or OS.