CloudNative Meets WebAssembly: Exploring Wasm's Potential to Replace Containers

Slide 1

Slide 1 text

Kohei Ota / Senior Field Engineer @ Open Engineering, Apple YAPC::Hakodate 2024 CloudNative Meets WebAssembly Exploring Wasm's Potential to Replace Containers

Slide 2

Slide 2 text

Wasm (WebAssembly) basic

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Wasm is… • NOT the “Assembly”! • Originally derived from asm.js, a subset designed to run   non-JavaScript applications in the browser  → Such as those written in C or C++, mainly for use cases like games that go beyond the limits of HTML5 + JS • Has stricter type constraints than JavaScript and functions like an "intermediate language" After Mozilla proposed asm.js in 2013 it evolved into WebAssembly (Wasm), and starting around 2017-2018, various tools began being ported to Wasm such as Vim, FFmpeg, and others.

Slide 5

Slide 5 text

Basic Wasm model Compilation Execution Language

Slide 6

Slide 6 text

Basic Wasm model Compilation Execution Language Modern browsers can execute Wasm on the same runtime layer as JS There are runtimes like Wasmer/ Wasmtime/WasmEdge in order to run Wasm apps on Operating Systems

Slide 7

Slide 7 text

Browser Wasm execution details • JavaScriptCore / V8 / SpiderMonkey can execute Wasm binary directly • (For Chromium) Lifto ff interpreter converts functions in .wasm into machine language, and TurboFan (also used for JS) optimizes functions that are called often, re-compiles and caches the machine code • Because it’s browser based, it cannot violate anywhere further than the browser, such as direct access to host fi lesystem, host memory and plugged devices

Slide 8

Slide 8 text

What Changes • Compile target is changed in static languages like Swift / C / Go / Etc. • Executed within a sandbox-by-default environment • High inter-language-operability

Slide 9

Slide 9 text

Different Compilation Target

Slide 10

Slide 10 text

Current compilation in existing languages Swift: swift build --swift-sdk x86_64-swift-linux-musl Golang: GOOS=linux GOARCH=amd64 go build main.go

Slide 11

Slide 11 text

Current compilation in existing languages Swift: swift build --swift-sdk x86_64-swift-linux-musl Golang: GOOS=linux GOARCH=amd64 go build main.go Compiled binaries cannot run on a host with different OS/CPU Why? → ABI is not compatible

Slide 12

Slide 12 text

Common Components in the ABI • CPU-dependent de fi nition including instruction set • Call numbers of system calls used • Call information for dynamically linked shared libraries

Slide 13

Slide 13 text

Windows Darwin Linux BSD Intel (AMD) ARM RISC-V PowerPC MIPS Compiler

Slide 14

Slide 14 text

Windows Darwin Linux BSD Intel (AMD) ARM RISC-V PowerPC MIPS Compiler Even for daily development use Mac / Linux / Win x Intel / Arm is 6 patterns

Slide 15

Slide 15 text

When compiling for Wasm swift build --swift-sdk wasm32-unknown-wasi GOOS=wasip1 GOARCH=wasm go build -o main.wasm main.go

Slide 16

Slide 16 text

When compiling for Wasm swift build --swift-sdk wasm32-unknown-wasi GOOS=wasip1 GOARCH=wasm go build -o main.wasm main.go Point the build target to Wasm when cross compiling the code

Slide 17

Slide 17 text

Basic Wasm model Compilation Execution Compilation  Language For Compilation Language

Slide 18

Slide 18 text

Dynamic (Script) Languages

Slide 19

Slide 19 text

For Perl (Because we are at a Perl conference) • There’s WebPerl for Wasm adoption with Perl… • But the code base hasn’t changed in 4 years and the maintainer shared that they have limited time for the project • It runs on Node.js(V8), but no speci fi c timeline for WASI support

Slide 20

Slide 20 text

For Ruby • Load Ruby.wasm through JS on a browser Or • Load the release binary of github.com/ruby/ruby.wasm on Wasm runtimes such as Wasmtime on server

Slide 21

Slide 21 text

For Python • Major 2 runtime impls: Pyodide and Wasmer’s py2wasm • The former is the browser version of CPython • The latter is a fork of Nuitka (an OSS that can compile Python to an executable single binary)

Slide 22

Slide 22 text

Basic Wasm model For Script Language Compilation Execution Script Language Lightweight interpreter on Wasm App Code

Slide 23

Slide 23 text

More common to run the script on a language runtime compiled for Wasm

Slide 24

Slide 24 text

What is it like to run “a Wasm app” from a dev POV? • Generate a Wasm binary and ignite on a Wasm runtime Or • Put the script on a language runtime on Wasm and execute on it

Slide 25

Slide 25 text

What is it like to run “a Wasm app” from a dev POV? • Generate a Wasm binary and ignite on a Wasm runtime Or • Put the script on a language runtime on Wasm and execute on it This is one of the factors that makes look like containers

Slide 26

Slide 26 text

“Calling” Wasm on a browser Language .wasm Binary Lightweight interpreter App Code Load .wasm from JavaScript

Slide 27

Slide 27 text

“Calling” Wasm on a browser Language .wasm Binary Lightweight interpreter App Code Load .wasm from JavaScript WebAssembly.instantiateStreaming(fetch("simple.wasm"), importObject).then( (results) => { // Do something with the results! }, );

Slide 28

Slide 28 text

“Calling” Wasm on a container Language .wasm Binary Lightweight interpreter App Code Load an OCI image

Slide 29

Slide 29 text

“Calling” Wasm on a container Language .wasm Binary Lightweight interpreter App Code Load an OCI image FROM scratch COPY app-wasm-binary . ENTRYPOINT [“/app-wasm-binary”]

Slide 30

Slide 30 text

What Changes • Compile target is changed • Executed within a sandbox-by-default environment <— Browser Like • High inter-language-operability

Slide 31

Slide 31 text

What is “sandbox-by-default”?

Slide 32

Slide 32 text

Browser is like an OS that runs sandbox environments • Di ff erent process on each tab • That means CPU and memory space are secured/consumed separately • In modern security standards, it's common to ensure that user data is isolated between di ff erent browser tabs.

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Wasm specification includes… • Binary format - used by compilers and runtimes in common • Data structure - data types and formats Wasm handles for computing • Execution model - de fi nition of environment and behavior when processes are being executed

Slide 35

Slide 35 text

Again, key strengths of Wasm • Language and OS/CPU independent • Common binary format • Executable in sandboxed environment like browsers and VMs

Slide 36

Slide 36 text

Remind you of anything?

Slide 37

Slide 37 text

Containers?

Slide 38

Slide 38 text

Java Virtual Machine! ࠓ͙͢μ΢ϯϩʔ υ

Slide 39

Slide 39 text

Similarities between Java and Wasm • The compilation and execution model (JDK + JVM) • It’s been discussed about Docker vs JVM many times too • Run “anywhere” • WebAssembly (Wasm) gained popularity due to its easy setup for development and execution, and its growth in a CI/CD-friendly ecosystem. (Just IMO) • Java has no concept like “inter-language-operability”

Slide 40

Slide 40 text

What Changes • Compile target is changed • Executed within a sandbox-by-default environment • High inter-language-operability <— its just byte code

Slide 41

Slide 41 text

Inter-language-operability? 🧐

Slide 42

Slide 42 text

Again, key strengths of Wasm • Language and OS/CPU independent • Common binary format • Executable in sandboxed environment like browsers and VMs Inter-language-operability

Slide 43

Slide 43 text

Again, Wasm specification includes… • Binary format - Used by compilers and runtimes in common • Data structure - Data types and formats Wasm handles for computing • Execution model - De fi nition of environment and behavior when processes are being executed

Slide 44

Slide 44 text

Remind you of anything?

Slide 45

Slide 45 text

Java Virtual Machine!

Slide 46

Slide 46 text

Kohei Ota / Senior Field Engineer @ Open Engineering, Apple YAPC::Hakodate 2024 CloudNative Meets WebAssembly Exploring Wasm's Potential to Replace Containers JVM

Slide 47

Slide 47 text

Key differences from the JVM • Size of spec/impl (As of 2024, at least…) • Originating from highly sandboxed browsers, Wasm’s inherent limitations aim to avoid surpassing the browser environment • To enable non-browser Wasm environments, more POSIX-like capabilities were needed, leading to the creation of WASI.

Slide 48

Slide 48 text

WASI (WebAssembly System Interface) ? • WASI extends the browser-based Wasm runtime by o ff ering a portable, secure, POSIX-like, runtime-independent API. It covers infrastructure functions like I/O, sockets, WebGPU, as well as essential OS-provided features like random number generation, logging, and parallel processing. • As an extension of Wasm, it preserves key principles like CPU, OS, and language independence, open speci fi cation, and the security needed for running arbitrary code.

Slide 49

Slide 49 text

Wasm is used in production already on… • Running arbitrary applications in major browsers • Utilization in CDN-based edge cloud services • More advanced and fi ne-grained control in reverse proxies, beyond lua and mruby • A framework for FaaS, competing with AWS Lambda • A test execution platform in CI toolchains for Swift • A target runtime for applications in Docker and Kubernetes environments.

Slide 50

Slide 50 text

Benefits • Safe • Lightweight • Executable anywhere • Convenient runtime and ecosystem

Slide 51

Slide 51 text

Benefits • Safe • Lightweight • Executable anywhere • Convenient runtime and ecosystem

Slide 52

Slide 52 text

CDN FaaS Container Browser Lightweight Numbers of requests More limitations on platform → Yet more advanced functionality More interface support on WASI Support OCI format Support SQLɾStorageɾAI/ML use-cases… Run non-JS apps Game / Native apps Edge (on-device) AI

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Standardization activities for Wasm • ɾhttps://github.com/WebAssembly/meetings/ • ɾhttps://github.com/WebAssembly/proposals • ɾhttps://github.com/WebAssembly/WASI • ɾhttps://github.com/bytecodealliance/meetings • Good places to start checking out

Slide 55

Slide 55 text

• We launched Wasm related community recently  Please join us!

Slide 56

Slide 56 text

Key takeaways • Wasm has a lot of potential and future • WASI still needs to support more functionalities to replace containers • Maybe it won’t fully replace containers, but there will be cases where we *SHOULD* use Wasm over containers, and vice versa in practical and realistic future

Slide 57

Slide 57 text

Thank you