What is WebAssembly (WASM)?
› Binary instruction format close to CPU instructions
› Common compilation target
› Run native code in a browser, at near-native speed
Slide 3
Slide 3 text
WASM’s Good Sides
Portable Fast
Binaries are small
& Architecture-
independent
Run at near-native
Speeds
Secure
Sandboxed, memory-
safe execution
Language agnostic
Develop with many
different languages
What Can It Do?
Supported datatypes:
- Bytes
- Int32, Int64
- Float32, Float64
- Vectors
- Opaque references
Export functions for the host
to call
Import functions defined by
the host
Slide 6
Slide 6 text
What Can’t It Do?
Due to the sandboxed
nature of WASM, a module
can’t directly access the host
environment
No access to:
- Host memory
- Filesystem
- Network
- Environment variables
Slide 7
Slide 7 text
› Very narrow in scope
› Extensible
› Unopinionated
› No attached ecosystem
› Open web standard
How is WASM different?
How does it do it?
Write
“DevNet”
Greet ( int, int )
Guest
Host
Greet (&devNet, 6 )
Read
&devNet, 6
Write
“Hello, DevNet”
Read
“Hello, DevNet”
WASM Memory
Slide 10
Slide 10 text
How does it do it?
Greet ( int, int )
Guest
Host
Greet
(“DevNet”)
Generated Glue Code
Glue
“Hello,
DevNet”
Read
&devNet, 6
Write
“Hello, DevNet”
Greet (&devNet, 6 )
Slide 11
Slide 11 text
WebAssembly System Interface (WASI)
› Turns out, what makes WASM good
in the browser is what we want on
the server
› POSIX-like API to expose host
environment
› Host has full control how this access
is implemented
Portable
Fast
Language agnostic
Secure
Slide 12
Slide 12 text
Capability Based Security
› Explicity define the ‘capabilities’ the
module has on execution
› Grant Access to:
› Files/folders
› Network paths
› Environment variables
› Stdin/Stdout/Stderr
Compiling C# To WASI
› .NET can’t go directly to WASM
outside of browser context (yet)
› dotnet-wasi-sdk
› Generate C entrypoint
› Compile to WASI via clang
› Limited functionality
› Can’t import/export functions in C#
› Write C code that does this
Slide 16
Slide 16 text
DEMO: Working with WASI in C#
Slide 17
Slide 17 text
WebAssembly Components
› Layer on top of Core WASM
› Still a single binary
› Main goals:
› Interact with WASM in a way that’s
native to the host language
› Cross-language composition of
multiple components
› Stage 1 proposal
› Looks like the future direction of
WASM
Slide 18
Slide 18 text
WebAssembly Interface Types (WIT)
interface host {
print: func(x: string)
}
interface guest {
count-lines: func(x: string) -> s32
}
default world line-counter {
import imports: self.host
export exports: self.guest
}
Implemented by host,
imported by the
component
Exported by the
component
Definition of the
component
WIT as abstraction
interface key-value {
get: func(key: string) -> string
set: func(key: string, value: string>) -> option
}
default world kv-world {
export exports: self.key-value
}
Key-
Value
Slide 21
Slide 21 text
Composing components
Key-Value
Http
Server
Message bus
Business
logic
› Imagine we’re a platform for
serverless function execution
› Platform provided bindings
› Update without impacting users
› User only has to care about their
business logic component
Slide 22
Slide 22 text
DEMO: WASM Microservice with SpiderLightning
Slide 23
Slide 23 text
WASI vs Docker
Slide 24
Slide 24 text
WASI vs Docker
› “Hello World” console app in C#
› Dockerized with basic dockerfile
› Size on disk:
› ASP.NET Docker image: 211mb
› WASI: 9mb
› Compiled from Rust is another 4x
smaller!
Slide 25
Slide 25 text
WASI vs Docker
› WASI will be ‘lightweight’ class compute
› Fire-and-forget logic
› Very quickly spin up new environments
› WASI is not going to kill containers (yet)
› Docker probably better for longer-living services
› New docker features allow running them side by
side
Slide 26
Slide 26 text
What’s next for WASM
› WASI preview 2 is around the corner
› Component model!
› WASI implemented as components
› Standardizing a set of cloud interfaces
› Key-value
› messaging
› Blob store…
› Microsoft has made no official commitment,
but is watching closely
Slide 27
Slide 27 text
Get involved!
› Learn Rust!
› The entire WASM ecosystem is built in it
› Lots of fun stuff to build
› .NET equivalents for existing tooling
› Component implementations for Azure
services
› Experiments with WASI in real-world
scenarios
Slide 28
Slide 28 text
Some projects
› bytecodealliance/wasmtime-
dotnet
› Programatically run WASM with C#
› bytecodealliance/wit-bindgen
› Generate WASM component glue
code from WebAssembly interface
types
› deislabs/spiderlightning
› WASM microservices and cloud
capabilities
› fermyon/spin-dotnet-sdk