Mega Mergers: Cloud-Native-Architekturen mit Containern und WebAssembly

Architekturen für den optimalen Betrieb in der Cloud bestehen nur aus Containern und laufen immer in Kubernetes! Blödsinn! Die Realität sieht ganz anders aus und wird sich dank WebAssembly (Wasm) in den kommenden Jahren noch mehr verändern. Durch die geschickte Kombination von Containern, Cloud-Diensten und WebAssembly können wir schon heute verteilte Architekturen entwerfen, die für die Zukunft gewappnet sind. In diesem Vortrag zeigt Cloud-Native-Experte Thorsten Hans wie Sie sich bereits jetzt WebAssembly auf dem Server und in der Cloud zunutze machen können, um sich optimal für die Zukunft aufzustellen. Let’s go!

Transcript

1. Mega Mergers Thorsten Hans @ThorstenHans Cloud-Native with Containers and WebAssembly
2. Cloud-Native Business Applications Day Uhrzeit Titel Sprecher 09:00 – 10:00 Cloud-Native-all-the-Things: Definition, Praktiken und Patterns Christian Weyer Thorsten Hans 10:30 – 11:30 Containerbasierte Entwicklung für .NET-Entwickler Tobias Fenster 12:00 – 13:00 Cloud-Native Generative AI mit Fermyon Serverless AI Thorsten Hans 15:15 – 16:15 Cloud-Native Microservices, on-premises oder in der Cloud – mit Dapr Christian Weyer 16:45 – 17:45 Mega Mergers: Cloud-Native-Architekturen mit Containern und WebAssembly Thorsten Hans
3. Consultant @ Thinktecture #Azure #Containers #CloudNative #Wasm thorsten.hans@thinktecture.com thinktecture.com thorsten-hans.com @ThorstenHans Microsoft MVP | Docker Captain Thorsten Hans
4. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
5. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
6. WebAssembly will change the way we architecture distributed systems in the future
7. Why?
8. • 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 <1msec Intro Why will Wasm have such a big impact?
9. • Developer interest: • They can use any language that compiles to wasm32_wasi • They can ship just the app • They can reduce cloud spendings • Same workloads will be cheaper because they consume less resources and execute faster Intro Why will Wasm have such a big impact?
10. Wasm on the server relates to containers in the same way containers related to virtual machines 10+ years ago
11. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
12. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
13. 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! 🦀
14. With Spin we can build • Reactive applications that respect to the key pillars of Wasm • Fast: Near-native speed • Lightweight: Super small distributable units (Wasm Modules) • Secure: Sandboxed execution environment Intro Let’s get everybody on track!
15. Let’s meet Fermyon Spin Walk through the demo application Demo
16. • 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
17. 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
18. • Considering Fermyon Spin? 💡 Try to spot reactive parts of your application • Check, if the 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
19. Where we started Architectural blueprint of the sample app
20. Where we landed Architectural blueprint of the sample app
21. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
22. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
23. When building HTTP-based applications with Spin we must • specify a route on which Spin should invoke our code • Implement code for handling different HTTP request types Although Spin SDK is tiny, it simplifies building full-fledged HTTP APIs Patterns & Practices
24. Routing capabilities in HTTP-based Spin applications Demo
25. 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
26. Outbound HTTP leveraging the Spin SDK Demo
27. 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
28. • 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
29. Configuration data for Spin apps Demo
30. • 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
31. Publish / Subscribe in distributed apps with Spin Demo
32. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
33. • Intro • Let’s meet Fermyon Spin • Patterns & Practices • Conclusion Agenda
34. • 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 wasm32_wasi) Conclusion
35. • 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
36. Thanks for your attention @ThorstenHans @Thinktecture