Server-Side WebAssembly

Slides van Jesse Wellenberg bij devCampNoord

Transcript

1. Server-Side WebAssembly Jesse Wellenberg Cloud & Software Engineer
2. What is WebAssembly (WASM)? › Binary instruction format close to CPU instructions › Common compilation target › Run native code in a browser, at near-native speed
3. 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
4. Compiling WebAssembly Runtimes • Browsers • Wasmtime • Wasmer WebAssembly Binary
5. 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
6. 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
7. › Very narrow in scope › Extensible › Unopinionated › No attached ecosystem › Open web standard How is WASM different?
8. Calling WASM Add ( 20, 50 ) 70 Print() { Console.WriteLine(“Hello”); } Add ( int, int ) Print () Guest Print () Host Log: “Hello”
9. 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
10. 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 )
11. 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
12. Capability Based Security › Explicity define the ‘capabilities’ the module has on execution › Grant Access to: › Files/folders › Network paths › Environment variables › Stdin/Stdout/Stderr
13. WASI High-Level CountLines (“demo.txt”) 10 CountLines (file) ReadFile() Guest ReadFile() Host demo.txt
14. WASI High-Level CountLines (“hello.txt”) ReadFile() demo.txt Host CountLines (file) ReadFile() Guest
15. 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
16. DEMO: Working with WASI in C#
17. 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
18. 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
19. Components High-level WIT host guest CountLines (int, int) print (int, int) Guest Host CountLines (string) print (string)
20. WIT as abstraction interface key-value { get: func(key: string) -> string set: func(key: string, value: string>) -> option<string> } default world kv-world { export exports: self.key-value } Key- Value
21. 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
22. DEMO: WASM Microservice with SpiderLightning
23. WASI vs Docker
24. 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!
25. 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
26. 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
27. 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
28. 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
29. Thank you! Questions? https://github.com/yeseh/dnn-wasi-demo
30. Let‘s connect! @yeseh https://xpirit.com Jesse Wellenberg Cloud & Software Engineer jwellenberg@xpirit.com /in/jesse-wellenberg