Think container orchestration different – WASM is coming Christoph Voigt & Max Körbächer | Co-Founder of Liquid Reply
A presentation at DevOpsCon London in April 2022 in London, UK by Max Körbächer
Think container orchestration different – WASM is coming Christoph Voigt & Max Körbächer | Co-Founder of Liquid Reply
Who are we? Max Körbächer Christoph Voigt Co-Founder and Kubernetes Platform Engineer at Liquid Reply Co-Founder and developer of Liquid Reply Former Enterprise Architect, focusing on Kubernetes and Cloud Native Infrastructure. Software Engineering background, having a focus on Cloud Native Infrastructureand Application-Architectures Contributing to the Kubernetes release team and related K8s technologies Contributing to the Kubernetes release team and related K8s technologies Servant for a 🐈 Father of two
Liquid Reply is the Kubernetes and Cloud-Native consultancy of the Reply Network. We help our clients entangling difficulties of modern IT-Infrastructure, developing, architecting and teaching cloud-native technologies.
Todays Journey WebAssembly (WASM) is at an inflection point: Over the next few years, we expect to see increased adoption of WebAssembly across the tech sphere, from containerization to plugin systems to serverless computing platforms What is WASM and how is it even relevant? 🧐 What is the status quo of the WASM ecosystem? Conclusion and look into the glass bowl 🔮
WebAssembly Intro
src: https://twitter.com/solomonstre/status/1111004913222324225
What is WebAssembly? Think of it as an intermediate layer between various programming languages and many different execution environments. You can take code written in over 30 different languages and compile it into a *.wasm file, and then can execute that file on any WASM Runtime. The name “WebAssembly” is misleading. Initially designed to make code run fast on the web, today it can run anywhere. WebAssembly oversimplified: ⚡ Consistently fast 🔬 Small WebAssembly is: ● ● ● ● stack-based VM executing binary file formats CPU-agnostic -> taking any architecture OS-agnostic Entirely depends on the host runtime (we will talk later about it) 🌍 Universal ♻ Reusable
Benefits of WebAssembly Fast Slightly adjusted; Source: https://b-nova.com/home/content/containerless-mit-webassembly-runtimes*
Where can WebAssembly be applied? *outside the Browser 🪢 🧩 Language Plugin Systems Interoperability 🖼 Embedded Sandboxing 🔗 📦 Blockchains Containerisation 🧮 Serverless Platforms Write that library once in a language of your choice; use in any language. Never trust third parties! Prevent yourself against bugs of third party libraries. Write Smart Contracts in a language of your choice. Universal Runtime, capability based security model. Minimal Startup time, maximal isolation. Figma Lichess.org Google Earth Adobe Photoshop Envoy / Istio Kubewarden MS Flight Simulator Minecraft RedPanda Firefox HTTP Servers CosmWasm eWASM Krustlet Hippo wasmCloud Lunatic WasmEdge Cloudflare Workers AWS Lambda Atmo (Suborbital) Fastly Compute@Edge
A new paradigm ahead? Image Source (adjusted): Liam Randall (@Hectaman) - https://twitter.com/Hectaman/status/1389585069073895434
A new paradigm ahead? Image Source (adjusted): Liam Randall (@Hectaman) - https://twitter.com/Hectaman/status/1389585069073895434
Some WASM implementations (a subjective choice)
instead of containers, we want to start wasm runtimes crun runc gVisor … Linux Container Images A Regular Kubernetes Stack
The default implementation of Krustlet listens for the architecture wasm32-wasi and schedules those workloads to run in a wasmtime-based runtime instead of a container runtime. Krustlet Wasmtime wasi WASM Module A Krustlet Kubernetes Stack
The default implementation of Krustlet listens for the architecture wasm32-wasi and schedules those workloads to run in a wasmtime-based runtime instead of a container runtime.
Krustlet Solution Approach Advantages ➕ add “wasm nodes” to your cluster without changing the entire cluster setup ➕ use the same Pod-Spec as for your normal Pods ➕ CSI support ➕ Plugin-Support Try it in Kind: https://github.com/Liquid-Reply/kind/tree/kind-krustlet Considerations ➖ either Kubelet OR Krustlet ➖ as there is no container runtime, you need toleration configs to avoid scheduling of “normal” cluster-wide daemonset* (e.g. CNI) ➖ your modules are only allowed to do what the runtime permits → no Network for your modules! ➖ wasi + wasmtime under heavy development → so is Krustlet
WasmEdge Integrating with existing tooling, and more … ● ● Aims to solve similar problems as Krustlet, but in a more flexible and leaner way Kubernetes Especially targets the integration in various Kubernetes distributions, CRI runtimes as well as OCI runtimes - therefore a good match to run WASM side by side with classic containers Node Kubernetes API Server Kubelet CRI Runtime Docker CRI-O container-d ● Runs also stand alone for modern web apps, to host serverless functions and being “embedded” in any kind of edge device. … OCI Runtime crun runc Linux Container Images gVisor … WebAssembly app images The Container Eco-System based on: https://wasmedge.org/book/en/kubernetes.html
WasmEdge Solution Approach WasmEdge is different on the image level. Rather than having a container image with a OS, the WASM image is build from scratch. In addition, the container requires an “wasm.image” annotation, to let crun and containerd know that it use WasmEdge. This approach allows to use WASM within the Kubernetes context, and utilize the existing ecosystem. *http server wasm image within a docker file *a wasm container requires the wasm image annotation
WasmEdge Solution Approach Advantages Considerations ➕ WasmEdge can run alongside your standard ➖ Additional tools for image annotation are required (at the moment) containers ➖ For some use cases you need another SDK ➕ Build and deployment spec are nearly the ➖ It can lead to confusion that you can use same as for a normal pod WasmEdge in very different scenarios and each of ➕ Supports different CRI, OCI and K8s distros them has to be developed differently ➕ Can use existing K8s ecosystem ➕ Runs by itself on edge, serverless or browser From all tools we show today, WasmEdge would be the best choice to extend your currently orchestration without deep cutting changes
Only a fraction is actual business logic
WasmCloud The Solution wasmCloud Host Runtime Actor Actor Actor wasmCloud Host Runtime Actor Actor Actor 🤝 Capability Provider … 🤝 Capability Provider Three core concepts: - 🕸 Lattice Self-Forming = Self-Healing Flat Topology Actor Capability Provider Lattice
WasmCloud Reach and Resilience backed by the Lattice 🏢 Data Center Cloud B Lattice ☁ ☁ Cloud A 📱
WasmCloud Reach and Resilience backed by the Lattice 🏢 Data Center 📱 Cloud B Lattice ☁ ☁ Cloud A ⚡
WasmCloud Reach and Resilience backed by the Lattice 🏢 Data Center 📱 Cloud B Lattice ☁ ☁ Cloud A ⚡
WasmCloud Solution Approach Advantages ➕ ➕ ➕ ➕ ➕ ➕ high focus on writing business logic potentially high reusability of WASM modules high isolation high amount of security high resiliency HostRuntimes can run “anywhere” (Bare metal, VM, Container, Kubernetes, Webbrowser…) Considerations ➖ applications need to be written with WasmCloud in mind ➖ currently Rust is the only supported language; though other languages are planned ➖ still very young project - expect rough edges ➖ tooling for debugging and monitoring rudimentary
Summary
WASM Ecosystem ● The WASM ecosystem is under heavy development ● Many tools are new or getting continuously reshaped ● This is reflected in the CNCF WASM landscape
A missing extension? Docker-like container WebAssembly OK Great Resource footprint Poor Great Isolation OK Great Safety OK Great Portability OK Great Security OK Great Language and framework choice Great OK (yet) Ease of use Great OK (yet) Manageability Great Great Performance
Containers for lifting, WASM for re-creating Go with the Container flow Build with WASM for the future Containers will stay and drastically increase in usage over the next years. But for future developments WASM might be in many cases a better choice. We believe that WASM & Container will go along side by side
Conclusion 1 3 5 WebAssembly’s potential is beyond the browser WASM will not substitute containers & K8s, but extend them The developer experience of/for WASM will be the game changer 2 WASM enables use cases that are not possible with container & K8s 4 WASM lacks harmonization and makes it difficult for programming languages to adapt
WASM will be ubiquitous
Sources - https://www.infoworld.com/article/3651503/the-rise-of-webassembly.html https://harshal.sheth.io/2022/01/31/webassembly.html *** https://nickymeuleman.netlify.app/blog/webassembly *** https://docs.krustlet.dev/topics/architecture/ https://docs.krustlet.dev/topics/providers/ https://github.com/Liquid-Reply/kind/tree/kind-krustlet (Krustlet baked into Kind:) https://bytecodealliance.org/articles/announcing-the-bytecode-alliance *** https://thenewstack.io/what-is-webassembly/ https://www.youtube.com/watch?v=vqBtoPJoQOE https://istio.io/latest/docs/concepts/wasm/ https://www.kubewarden.io/ https://docs.flightsimulator.com/html/Programming_Tools/WASM/WebAssembly.htm https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://almanac.httparchive.org/en/2021/webassembly https://harshal.sheth.io/2022/01/31/webassembly.html https://github.com/deislabs/hippo https://github.com/lunatic-solutions/lunatic https://github.com/suborbital/atmo https://blog.cloudflare.com/webassembly-on-cloudflare-workers/ https://www.fastly.com/blog/how-compute-edge-is-tackling-the-most-frustrating-aspects-of-serverless https://cosmwasm.com/ https://github.com/ewasm/design https://wasmcloud.dev/reference/host-runtime/
Thank you!
