Slide 1

Slide 1 text

WebAssembly auf dem Server und in der Cloud Thorsten Hans @ThorstenHans Cloud-Native Consultant mit Fermyon Spin

Slide 2

Slide 2 text

Consultant @ Thinktecture #Azure #Containers #CloudNative #Wasm [email protected] thinktecture.com thorsten-hans.com @ThorstenHans Microsoft MVP | Docker Captain Thorsten Hans

Slide 3

Slide 3 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 4

Slide 4 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 5

Slide 5 text

WebAssembly (Wasm) • It’s virutal machine that processes stack-based instructions • Instruction are in binary format • High performance runtime that devs can target using “almost” every language* * https://www.fermyon.com/wasm-languages/webassembly-language-support Introduction

Slide 6

Slide 6 text

WebAssembly (Wasm) • Fast 🏃 • Near native execution performance, leveraging available hardware capabilities • Safe 💪 • Wasm is a sandboxed, memory-safe execution environment • Portable 🧊 • All major browsers support Wasm & multiple ”server” Wasm runtimes available Introduction

Slide 7

Slide 7 text

WebAssembly System Interface (WASI) • Platform Integration 🧬 • WASI is a wrapper for underlying platform (OS) capabilities • Think of things like File:: open() • Portable 🧊 • WASI could become the default compiling target for EVERYONE! • Secure 👮 • Permissions can be defined per app (module) Introduction

Slide 8

Slide 8 text

Portability Introduction https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Slide 9

Slide 9 text

Security Introduction https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Slide 10

Slide 10 text

Security Introduction https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Slide 11

Slide 11 text

Security Introduction https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Slide 12

Slide 12 text

Security Introduction https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Slide 13

Slide 13 text

WebAssembly Gateway Interface (WAGI) • Use WebAssembly modules as HTTP handlers • Think of a hyper-focused microservices runtime • Comman Gateway Interface (CGI) implementation • HTTP headers become environment variables • HTTP payloads are piped to stdin • HTTP responses must be written to stdout Introduction

Slide 14

Slide 14 text

WebAssembly will change the way we architecture distributed systems in the future

Slide 15

Slide 15 text

Why?

Slide 16

Slide 16 text

• Cloud-vendor interest: • They can put more apps on a compute resource as today • Wasm and WASI give them a strict security and isolation model • Wasm workloads are way smaller than everything else • They can scale to zero due to super-fast bootstrapping Intro Why will Wasm have such a big impact?

Slide 17

Slide 17 text

• Developer interest: • We can use any language that compiles to wasm32_wasi • We can ship just the app (not the webserver, not the OS) • We can reduce cloud spendings • Workloads will be cheaper because they consume way less resources and execute faster Intro Why will Wasm have such a big impact?

Slide 18

Slide 18 text

Wasm on the server relates to containers in the same way containers related to virtual machines 10+ years ago

Slide 19

Slide 19 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 20

Slide 20 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 21

Slide 21 text

Fermyon Spin is: • A serverless runtime build using Wasm, WASI, and the WebAssembly Component Model (leveraging wasmtime internally) • A collection of SDKs for many popular languages • A super focussed developer tooling Intro Let’s get everybody on track! 🦀

Slide 22

Slide 22 text

Let’s meet Fermyon Spin Walk through the demo application Demo

Slide 23

Slide 23 text

• Spin provides triggers that the runtime uses to invoke our code • The runtime instantiates our Wasm Module and invokes our code • Currently, Spin provides the following triggers • HTTP • Publish / Subscribe Let’s meet Fermyon Spin Triggers & Outputs

Slide 24

Slide 24 text

Outputs allow our code to interact with the surrounding world • Databases (SQLite, MySQL & PostgreSQL) • Key-Value Storage (SQLite, Redis) • Publish / Subscribe (Redis Channels) • Outbound HTTP Let’s meet Fermyon Spin Triggers & Outputs

Slide 25

Slide 25 text

• Considering Fermyon Spin, try to spot reactive parts of your application • Check if necessary libraries are available for the wasm32_wasi platform • Deploy Fermyon Platform to your infrastructure of trust Intro How to adopt Wasm on the server / in the cloud

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 28

Slide 28 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 29

Slide 29 text

Regardless of whether we must invoke backend APIs or 3rd party endpoints, Outbound HTTP is an easy to grasp, yet important capability provided by the Spin SDK. Patterns & Practices Outbound HTTP

Slide 30

Slide 30 text

Outbound HTTP leveraging the Spin SDK Demo

Slide 31

Slide 31 text

Configurability is mission-critical when building software that is executed in different environments. Spin apps are no exception here. We must use proper mechanisms to deal with sensitive and non-sensitive configuration data. Patterns & Practices Configuration Management

Slide 32

Slide 32 text

• The Spin Manifest spin.toml is the center of gravity. All configuration aspects are defined here. • We use variables to specify non-sensitive configuration data • For sensitive configuration data, we can use HashiCorp Vault • We link HashiCorp Vault to our app using a runtime-config file Patterns & Practices Configuration Management

Slide 33

Slide 33 text

Configuration data for Spin apps Demo

Slide 34

Slide 34 text

• Publish is achieved using the Spin SDK • Constructing messages is up to us, which means we can modernize (read: replace containers) with ease, using cloudevents or by mimicking existing messages • When subscribing to messages, we must implement filters on our own Patterns & Practices Publish / Subscribe

Slide 35

Slide 35 text

Publish / Subscribe in distributed apps with Spin Demo

Slide 36

Slide 36 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 37

Slide 37 text

• Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda

Slide 38

Slide 38 text

• With Spin, Fermyon demonstrates how WebAssembly will change the way we build software for the next wave of cloud-computing • We’re able to combine best from both worlds, Containers and WebAssembly to build distributed architectures for the upcoming years • Available Spin SDKs and plain WAGI support makes it super easy to get started (using any language that compiles to Wasm) Conclusion

Slide 39

Slide 39 text

• Hyperscalers want Wasm to drive hardware utilization, lift smaller application packages, get proper isolation and security in place and scale horizontally to and from 0 without facing the dilemma of cold-start times (Looking at you, Azure Functions *scnr*). • Application developers on the otherside had to tacklequite some pitfalls to adopt Wasm (SDKs., dev tooling, etc) • From my point of view, Fermyon is able to close the gap and drive Wasm adoption on the server and in the cloud to whole new level Conclusion

Slide 40

Slide 40 text

Thanks for your attention @ThorstenHans @Thinktecture