Slide 1

Slide 1 text

1 WebAssembly for the backend Adrian Cole OSS Engineer

Slide 2

Slide 2 text

Open Source late bloomer Currently all-in on wazero.io http-wasm.io and projects that use them 2 I’m Adrian from Tetrate codefromthecrypt on GitHub

Slide 3

Slide 3 text

Agenda Overview of WebAssembly Decouple programming language choice Safely run a binary inside yours Breaking the monolith part two Perils of programming wasm Closing thoughts 3 I work on these things and feel they are under-discussed

Slide 4

Slide 4 text

Not Agenda Web programming practice Smart Contracts, web3, etc. Edge functions Attempts to retrofit Docker WAGI aka CGI part two 4 There is a lot of content on these things, and we only have forty minutes!

Slide 5

Slide 5 text

Dive into WebAssembly 5 How more languages got into the browser, with a dash of jargon

Slide 6

Slide 6 text

WebAssembly is an embeddable virtual machine and bytecode format 6 crypto crypto = WebAssembly.instantiate(cryptoWasm) crypto[sign](ptr, len) ptr, len = copyToWasm(crypto, toSign) crypto.rs

Slide 7

Slide 7 text

7 ● Oracle JCP ● Dominates the backend ● Language bias. Ex field instructions ● Other languages share object model, GC, stdlib ● W3C Working Group ● Dominates the browser ● Hardware bias. Ex SIMD instructions ● Other languages bring their own object model, GC, stlib Virtual Stack Machines

Slide 8

Slide 8 text

WebAssembly host WebAssembly guest Is the embedding process e.g. a web browser, desktop application or microservice. Controls the guest e.g. instantiates guests, invokes their functions Might export functions e.g. functions that allow file access Is compiled to bytecode e.g. a %.wasm file the host compiles to machine code Has its own memory Functions work via numeric parameters or memory Might require functions e.g. will fail to start if functions aren’t available Host ~= VM Guest ~= module

Slide 9

Slide 9 text

Application Binary Interface (ABI) Services agree on how to communicate via Remote APIs. Compilers and components agree via ABI. The most common ABI used outside the browser is WASI. It defines functions similar to POSIX file I/O, clocks and env variables. 9 https://wasi.dev/

Slide 10

Slide 10 text

WebAssembly host WebAssembly guest wasi_snapshot_preview1 Importable functions: args_get clock_time_get env_get random_get fd_write … Required Exports memory: “memory” function: “_start” 


Slide 11

Slide 11 text

ABI are documentation, sometimes just markdown files! 11 Example: clock_time_get

Slide 12

Slide 12 text

WebAssembly for re-use avoid porting or rewriting code in another language 12

Slide 13

Slide 13 text

Wasm cannot directly affect resources like files. Guests call imported host functions with pointers to shared memory they own. 13 out, err := run(ctx, fi leFS(path), "dcraw", "-e", "-c", "input") Safely run a binary inside yours _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 14

Slide 14 text

Breaking the monolith part two WebAssembly as an alternative to microservices for some use cases 14

Slide 15

Slide 15 text

APIs, APIs, ABIs? We’ve learned you can break large codebases into smaller ones with micro services, communicating over APIs. We can sometimes use WebAssembly instead. Define supported ABIs and let users provide custom functions. 15 WARNING: WebAssembly is constrained and difficult. It may not be the right fit for you!

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Breaking the CLI monolith WebAssembly as a way to modularize a command-line tool 17

Slide 18

Slide 18 text

18 ● Security and misconfiguration policy begs for modularity ● Sites prefer custom policy vs ignoring alerts or not seeing them. ● Policy needs code for analysis and classification

Slide 19

Slide 19 text

19 Challenges of a CLI ● Trivy is ultimately a CLI, built for several operating systems on several architectures. ● Packaging for Docker, GitHub Actions etc is easiest with a static binary. ● Getting into the default build isn’t viable or relevant for all policy.

Slide 20

Slide 20 text

Trivy provides an SDK which implements their custom ABI for config and analysis. Modules are installed locally or via OCI repository. 20 Trivy + wasm = site friendly policy trivy.dev acme-cves.wasm acme-cves.go Tinygo Trivy SDK ghcr.io/acme

Slide 21

Slide 21 text

Breaking the sidecar monolith WebAssembly as a way to modularize deeply embedded infrastructure 21

Slide 22

Slide 22 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 custom libraries dynamically. 22

Slide 23

Slide 23 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 24

Slide 24 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 25

Slide 25 text

Sidecars define the WebAssembly ABI they support Dapr (golang) runs http-wasm guests. It also allows use of WASI, though doesn’t require it. Middleware compatible with these ABI can change in any way without changing Dapr. 25

Slide 26

Slide 26 text

26 ● http-handler ABI implements HTTP server middleware ● The ABI defines functions the host and guest are required to implement ● Implementations exist for Go http.Handler and Node.js express, with more coming soon http-wasm.io

Slide 27

Slide 27 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 28

Slide 28 text

Perils of programming wasm Stick with pre-built binaries and SDKs while you can! 28

Slide 29

Slide 29 text

29 1. Download a pre-built binary 2. Compile your own binary, possibly with an SDK 3. Directly import and export wasm functions wasm 3 ways

Slide 30

Slide 30 text

SDKs implement the ABI, and compilation steps are abnormal 30 SDK example in TinyGo Global config Not stdlib Not go http-wasm/http-wasm-guest-tinygo

Slide 31

Slide 31 text

You can directly access imported functions by (module, name) pair 31 Manual example in Rust Import name No strings Import module

Slide 32

Slide 32 text

Compilers are different or at least need different flags. Performance varies and is runtime specific. Benchmark! There are other ways to polyglot! 32 ● Features like reflection usually don’t work ● Wasm has no parallelism, so garbage collection is inline ● WebAssembly has no standard library, so binaries can get big. programming WebAssembly is trickier than normal code

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

WebAssembly is a new way to modularize software safely and without RPC. 34 ● You can embed your code into other binaries and visa versa with WebAssembly ● Many projects use an SDK approach to enable success ● WebAssembly is evolving and will be different next year 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