Slide 1

Slide 1 text

1 WebAssembly for the backend Adrian Cole OSS Engineer

Slide 2

Slide 2 text

Open Source late bloomer All-in on wazero.io, the zero dependency WebAssembly runtime for Go 2 I’m Adrian from Tetrate codefromthecrypt on GitHub @adrianfcole

Slide 3

Slide 3 text

Should I stay or should I go? WebAssembly is about safely running 3rd party code. We’ll review non-browser use cases, in architecture order from high to low level. Integrations use wazero, but code run often isn’t Go. 3

Slide 4

Slide 4 text

Service architecture WebAssembly as a way to modularize deeply embedded infrastructure 4

Slide 5

Slide 5 text

WebAssembly allows decoupling without RPC. Tools like go-plugin allow you to define ABI as protobuf services. 5 knqyf263/go-plugin gRPC Host Guest Decoupled with gRPC API Decoupled with WebAssembly Monolith Breaking the Monolith Service

Slide 6

Slide 6 text

Sidecar monoliths Sidecars are usually monolithic, and while highly customizable, tricky to change. For example, Envoy versions are tightly coupled to Istio versions. Dapr is a static binary, so cannot load custom libraries dynamically. 6

Slide 7

Slide 7 text

Customizing sidecars with HTTP Middleware My App Middleware 1 Middleware 2 Middleware 3 Dapr Sidecar Request Response You install this You built this You configure this

Slide 8

Slide 8 text

You want to break the monolith My App Middleware 2 Middleware 3 Dapr Sidecar Request Response My Filter You can’t change this binary You built this You want to own this code

Slide 9

Slide 9 text

Sidecars define the WebAssembly function contract they support ABI is a contract between the host running wasm and the guest. It defines functions like an IDL. Dapr (golang) supports the http-wasm ABI, implementing the server side of an HttpHandler. Compatible middleware, compiled to wasm, can be replaced without changing Dapr 9

Slide 10

Slide 10 text

So.. WebAssembly can break the monolith My App Middleware 2 Middleware 3 Dapr Sidecar Request Response My Filter WebAssembly allows custom functionality in a static binary, based on an ABI contract http-wasm guest http-wasm host My Filter http-wasm/http-wasm-guest-tinygo v1.10

Slide 11

Slide 11 text

WebAssembly is a great extension model Wasm are binaries that can be distributed as files or OCI images. Inline 3rd party dynamically instead of baking more into the build Avoid problems of remote deployment and availability.

Slide 12

Slide 12 text

Container architecture WebAssembly plus WASI as a leaner container model 12

Slide 13

Slide 13 text

Containers images are platform specific Container images must be built for the intended OS + architecture. “FROM scratch” can reduce this to kernel+arch, but only for static binaries. Many applications require a base layer with dependencies like libc, complicating deployment 13

Slide 14

Slide 14 text

14 WebAssembly has no operating system ● Compiling to %.wasm removes platform dependencies ● You can compile it on linux and run it on windows ● wasm containers are emerging, but not mature

Slide 15

Slide 15 text

15 DIY WebAssembly containers work today if you mix abstractions Container integration means pushing a WebAssembly Virtual Machine into the container runtime. For example, wasmer or wasmtime in crun. Some goals of wasm containers is re- use of Dockerfile and OCI registries

Slide 16

Slide 16 text

Wasm containers are limited The POSIX layer used by containers is called WASI. There are only 44 usable system calls in the de- facto wasip1 version, supported by most compilers. Don’t assume programs will compile to WASI, become smaller, or run more efficiently. Measure! 16

Slide 17

Slide 17 text

WebAssembly isolates via a lightweight VM When applied to containers, WASI is like a limited operating system. WebAssembly is integrated into an OCI runtime like crun OCI integration gives WebAssembly the benefits of Dockerfile

Slide 18

Slide 18 text

Application architecture The most important thing about WebAssembly, is it is embeddable 18

Slide 19

Slide 19 text

19 ● Start a process (os/exec) ● Call a Foreign Function (CGO) Sometimes we want to call code we can’t import

Slide 20

Slide 20 text

Wasm cannot directly affect resources like files. Guests call imported host functions with pointers to shared memory they own. 20 out, err := run(ctx, fi leFS(path), "dcraw", "-e", "-c", "input") WASI commands are like os/exec but safer _start fd_read(input) args_get mem.Write(dcraw_-e_…) out.Write(mem) fi le.Read(mem) github.com/ncruces/RethinkRAW fd_write(stdout) memory dcraw.wasm wasi dcraw.c clang

Slide 21

Slide 21 text

21 Why use WebAssembly instead of normal FFI? github.com/ncruces/go-sqlite3 You can embed stateful processes into your application, provided they can be compiled to wasm and route I/O through WASI

Slide 22

Slide 22 text

Code may look similar, but wasm is very different than CGO 22 WebAssembly isn’t integrated like usual FFI, but it is safer. github.com/ncruces/go-sqlite3 Not C.CString Not unsafe.Pointer Dynamic not pre- defined in import “C”

Slide 23

Slide 23 text

Trivy provides an SDK which implements their custom ABI for config and analysis. Modules are installed locally or via OCI repository. 23 You can embed wasm or you can distribute it trivy.dev acme-cves.wasm acme-cves.go Tinygo Trivy SDK ghcr.io/acme

Slide 24

Slide 24 text

Wasm facilitates re-use without forking or FFI Something compiled to WASI can be used like a forked process. You can re-use foreign functions without the safety hazards. Apps can choose whether to leverage wasm internally, or expose it for plugins.

Slide 25

Slide 25 text

Programming WebAssembly It works, but also a work in progress 25

Slide 26

Slide 26 text

26 Zig can compile Zig and C/C++ TinyGo and Go can compile Go A tale of 2 compilers

Slide 27

Slide 27 text

27 Profiling with wzprof math.c math.go github.com/stealthrocket/wzprof

Slide 28

Slide 28 text

Programming WebAssembly is a work in progress Compilers are different or at least need different flags. Don’t make assumptions from blogs. Develop, profile and benchmark! Be prepared for more work than usual, usually more technical.

Slide 29

Slide 29 text

A few interesting developments Cool things on the way 29

Slide 30

Slide 30 text

Exciting project updates A SIG just started to extend the Kubernetes Scheduler with wasm kubernetes-sigs/kube-scheduler-wasm-extension Dapr v1.11 handles events with wasm (output binding) dapr/dapr Buf v1.16 started an alpha feature for protobuf plugins in wasm bufbuild/buf

Slide 31

Slide 31 text

That’s all, folks! Let’s recap 31

Slide 32

Slide 32 text

Star any project you enjoyed, including tetratelabs/wazero Join me #wazero on gophers slack! 32 ● WebAssembly impacts all layers of architecture ● OCI Dockerfile is a natural fit for WASI binaries ● Developers can use wasm instead of subprocesses or native libraries ● WebAssembly is evolving, so proceed with caution. Here are some good talks: Wasmer Things: An Upside Down Guide To WebAssembly by Edoardo Vacchi CGO-less Foreign Function Interface With WebAssembly by Takeshi Yoneda