@deepu105 @oktaDev Is containerless the future of Kubernetes? Deepu K Sasidharan @deepu105 | deepu.tech

@deepu105 @oktaDev Hi, I’m Deepu K Sasidharan ➔ JHipster co-lead developer ➔ Java Champion ➔ Creator of KDash, JDL Studio ➔ Developer Advocate @ Auth0 by Okta ➔ Polyglot dev, OSS aficionado, author, speaker @deepu105 deepu.tech deepu105 deepu05

@deepu105 @oktaDev Containers on Kubernetes

@deepu105 @oktaDev Containers

@deepu105 @oktaDev Advantages of Containers ● Container images are lightweight ● Uses less system resources than a VM ● Portable ● Consistent and reproducible builds ● Faster to boot and run ● Easier to scale and manage ● More secure ● …

@deepu105 @oktaDev Limitation of Containers ● Images are OS and architecture dependent ○ Linux and Windows only ● Needs a lot of low level OS primitives ● Does not provide a fine grained control of security sandbox

@deepu105 @oktaDev Containerless == WebAssembly (WASM + WASI) WebAssembly.org

@deepu105 @oktaDev

@deepu105 @oktaDev WebAssembly on Kubernetes

@deepu105 @oktaDev WebAssembly on Kubernetes

@deepu105 @oktaDev Existing Ecosystem Compatibility https://wasmedge.org/book/en/kubernetes.html Registry Github Package Registry Azure Container Registry Google Container Registry Docker Hub Amazon ECR Distribution Language JS/TS Python Java PHP C/C++ C# (.NET) Ruby Swift Go Rust Kotlin

@deepu105 @oktaDev Advantages of WASM + WASI ● Startup speed and near native execution speed ○ A Wasm binary will finish execution before a docker image is initialized ○ Near zero cold start times ● Security isolation (memory isolation and sandbox) ○ capability-based security model ○ WASI applications follow the principle of least privilege ● Memory safety and efficiency ● Lightweight and portable(OS/Architecture)

@deepu105 @oktaDev Downsides of WASM + WASI ● You can’t just take existing projects and make a Wasm binary ○ Unlike containerized apps, Wasm applications needs to be built with compatible libraries and language. ● Resource isolation is still not perfected ● Networking is still being designed ● Network isolation is still TBD ● Not mature as still evolving ● Ecosystem is quite small ATM

@deepu105 @oktaDev Wasm + Cloud Ecosystem

@deepu105 @oktaDev Krustlet ● Kubelet written in Rust ● Can run WASM OCI workloads in Kubernetes ● Schedules WASM pods based on tolerations ● CNCF sandbox project ● Can be installed on most Kubernetes distributions including GKE, EKS, and AKS ● Networking requires additional experimental plugins on source https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rust

@deepu105 @oktaDev Krustlet

@deepu105 @oktaDev Wasmtime ● An open-source JIT-style standalone runtime written in Rust ● Makes it possible to run Wasm outside of a browser ● WASM and WASI standard compliant ● Fast and secure ● Does not support networking ATM ● Available as CLI and embeddable library for Rust, C/C++, Python, Go and .NET ● Used by projects like Krustlet and Spin

@deepu105 @oktaDev Wasmer ● An open-source runtime Wasm written in Rust ● Focus on executing WebAssembly on the Server ● Can run Wasm modules standalone or embedded in other languages ● Fast and secure ● Language integrations available for Rust, JS, C/C++, Go, Python, PHP, C# and Ruby ● Used by Open Policy Agent, CleverCloud, Hyperledger, Scailable and so on.

@deepu105 @oktaDev WasmEdge ● Wasm runtime focused on edge computing written in C++ ● Powers serverless apps, embedded functions, microservices and IoT ● Lightweight, high performance and extensible ● CNCF Sandbox project ● Compatible with Dapr and Kubernetes ● Has C, Rust and Go SDKs ● Can be used as an OCI compliant runtime on Kubernetes for Wasm workloads ● Supports networking for wasm workloads ● Baked into the crun container runtime https://wasmedge.org/book/en/kubernetes/quickstart.html

@deepu105 @oktaDev WasmCloud ● Wasm runtime focusing on distributed actors written in Rust ● Secure and fast ● Has SDKs for Go and Rust ● Can run on Kubernetes ● Can bridge with apps running in Kubernetes ● Uses OCI registries for artifacts

@deepu105 @oktaDev Fermyon ● WebAssembly platform and tools for the cloud trying to reinvent cloud computing ● Fermyon platform provides clustering, orchestration, service discovery, package management, HTTP proxy, and web UI ● Spin is a OSS framework for building and deploying cloud microservices with WebAssembly ○ Fast, secure, and composable ○ Written in Rust ● Bartholomew is a MicroCMS written in Rust for Wasm ● Makes Kubernetes redundant in this setup

@deepu105 @oktaDev Future?

@deepu105 @oktaDev WebAssembly ● WebAssembly on Kubernetes and cloud is still evolving ○ More platforms and projects are upcoming ● Rust has one of the best tooling and ecosystem for WASM making it an ideal language to build WASI workloads for Kubernetes and cloud ○ We will start seeing more and more Rust projects in the space ● Non-networking workloads are ideal use cases for now ○ until networking spec is stable in WASI ○ Workaround and plugins are available ● Containerless is definitely on the horizon ○ Wasm workloads ideally will coexist with Docker containers ○ Docker containers will still be used for existing apps ○ New applications might decide to be Wasm compatible ○ Cloud providers have already started using Wasm for serverless applications

@deepu105 @oktaDev Thank You Deepu K Sasidharan @deepu105 | deepu.tech https://deepu.tech/tags#rust https://developer.auth0.com

@deepu105 @oktaDev Why Rust?

@deepu105 @oktaDev Rust = High level general purpose language ● Multi-paradigm, ideal for functional, imperative and even OOP ● Modern tooling ● Ideal for systems programming, embedded, web servers and more ● Memory safe ● Concurrent ● No garbage collection ● Performance focused ● Most loved language in Stack Overflow survey for 6 years in a row

@deepu105 @oktaDev Safe programming Programming Safety = Memory safety + Type safety + Thread safety

@deepu105 @oktaDev ● About 70% of all CVEs at Microsoft are memory safety issues ● Two-thirds of Linux kernel vulnerabilities come from memory safety issues ● An Apple study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities ● Google estimated that 90% of Android vulnerabilities are memory safety issues ● 70% of all Chrome security bugs are memory safety issues ● An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues ● Some of the most popular security issues of all time are memory safety issues ○ Slammer worm, WannaCry, Trident exploit, HeartBleed, Stagefright, Ghost CVE galore from memory safety issues

@deepu105 @oktaDev Security issues from thread safety ● Information loss caused by a thread overwriting information from another ○ Pointer corruption that allows privilege escalation or remote execution ● Integrity loss due to information from multiple threads being interlaced ○ The best-known attack of this type is called a TOCTOU (time of check to time of use) attack caused by race conditions

@deepu105 @oktaDev Security issues from type safety ● Low level exploits are possible in languages that are not type safe. ● Type safety is important for memory safety as type safety issues can lead to memory safety issues "For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place." – Microsoft team

@deepu105 @oktaDev Zero cost abstractions “What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.” – Bjarne Stroustrup ● Your programming style or paradigm does not affect performance ● Number of abstractions does not affect performance as the compiler always translates your code to the best possible machine code ● You could not get more performance from hand written optimizations ● In-built abstractions are often more performant than hand written code ● Compiler produces identical assembly code for almost all variations

@deepu105 @oktaDev Zero cost abstractions

@deepu105 @oktaDev Tooling and community ● Hands down, one of the best compilers out there and great backward compatibility ● One of the best tooling you can find in terms of features and developer experience. Cargo is one stop shop for Rust tooling, build, compilation, formatting, linting, and so on ● One of the best documentation, which is shipped with the tooling ● A very diverse and vibrant community ○ Community formed from other languages hence bringing in best of many ○ Very welcoming and helpful ○ Rapidly maturing ecosystem with growing number of libraries and use cases ○ Has a forum which is used more than stack overflow for Rust ● Big names like Google, Apple, Microsoft, Amazon and Facebook are already behind rust and investing it. ● It’s on path to become the second supported language in Linux development. ● Use case has already extended to embedded, web assembly, kubernetes, web development, game development and even client side ● It’s only a matter of time until you can do any use case in Rust

@deepu105 @oktaDev Rust can be the ideal general purpose language

@deepu105 @oktaDev High level vs Low level language High level language ● Human oriented ● Easier to read ● Portable ● Need to be compiled to machine code ● Not as efficient as a low level language ● Provides features like memory management, abstractions and so on Low level language ● Machine oriented ● Harder to read ● Hardware specific ● Can be understood by machines ● Fast and efficient ● No fancy features

@deepu105 @oktaDev High level language compromise ● Safety ● Speed ● Abstractions Pick two

@deepu105 @oktaDev High level language compromise ● Safety ● Speed ● Abstractions With Rust we can get all three. Hence Rust is a high level language with performance and memory efficiency closest to a low level language. The only tradeoff you will make with Rust is the learning curve.

@deepu105 @oktaDev Performance, Memory and power From the research paper “Energy Efficiency across Programming Languages”

@deepu105 @oktaDev “Rust, not Firefox, is Mozilla’s greatest industry contribution” – TechRepublic