Every year, twice a year, we're lucky enough to see the latest and greatest in Cloud Native Wasm in one jam-packed day. This year we had the pleasure of traveling to Amsterdam for the EU circuit of KubeCon. Knowing that not everyone would be able to fly out to catch the event, we sponsored the recordings so that all of this great content would make it onto YouTube after the event. We've been attending WasmDay at CNCF KubeCon since the first one, and we wanted to share our insights with you for each talk, including a high level summary, some space for opinions, and then eventually the embedded recording once available.
If you're looking for a TL;DR of overall trends, here they are:
- The WebAssembly component model offers language support, interop, and tons of promise in terms of the way we can write software. Compared to just a year ago where the component model was a new idea, we're now seeing demos of the component model, and by the next KubeCon we'll be able to see even more.
- Serverless is a major use-case, seeing success across many projects.
- Wasm is excellent for plugins.
Now, enjoy summaries, insights, and some personal opinions from the whole of Cloud Native Wasm Day EU 2023!
Welcome + Opening Remarks - Kelsey Hightower, Google
Kelsey opened with an interesting sentence: "I know little to nothing about Wasm." He asked a question of the audience with the two things he sees Wasm being the most successful, whether they believe WebAssembly is going to create a new universal computer, or if it will become a new modern mainframe. He sees the biggest benefits in Wasm creating a system where a developer can write code in any language, deploy anywhere, and do it all with WebAssembly components. He also fairly calls out the developer desire to "just write code," and the challenge for the WebAssembly ecosystem is going to be education around the technology and preventing the notion that it requires a full rewrite.
Opinion: If there's one thing Kelsey understands, it's the hype cycles of cloud native computing. Though he may not be a daily Wasm developer, but he knows what it takes for software to be successful. I enjoyed his anecdote: "If you do a good job with this, nobody will ever talk about it again."
Sponsored Keynote: Building New Software Foundations With the WebAssembly Component Model - Till Schneidereit, Fermyon
Till, working with his limited 5 minute time slot, opens with a simple slide: "The way we build software doesn't work." He asks a scary question, whether or not we would bet our own money on the security of our software. He calls out how difficult it can be to work in diverse teams, working on diverse sets of software, and keep software secure. He wants to bring developers along and chase a fundamental change in how we build software. He believes the solution to building secure software like we build houses today on standards that will keep the house from falling down, is by changing the way we build software today with the WebAssembly Component Model
Sponsored Keynote: Beyond The Browser: Wasm in Your Cloud Development Workflow - Jake Levirne, Docker
Jake notes that Docker gets a chance to see many exciting projects come across the cloud native ecosystem. Docker started experimenting with Wasm and WASI in 2019, around the time of the famous tweet. Docker wants to bring Wasm to the people who are already writing applications and using containers, so that developers can use the tools they are comfortable with. Docker is working to support as many Wasm runtimes as possible, the current list sits at: spin, slight, Wasmtime, and WasmEdge.
Evolution of Wasm: Past, Present, Future - Bailey Hayes, Cosmonic
Bailey talks through the evolution of WebAssembly starting with a story from when she first
discovered asm.js, a precursor to Wasm. After proving a need for a portable target that allows
apps to run in the web, the WebAssembly design work began in 2015 and reached MVP in 2017.
Even in the original designs for WebAssembly, non-web embedding was a fundamental and use-case for WebAssembly. This design decision has led to Wasm being adopted not just for the web but in many cloud native cases. Bailey walked through how WebAssembly evolved over time to become the next Universal Computer.
Practically, in 2020-2022 we see many more applications in streaming video apps, Zoom, Prime Video, and more. We also see critical work bringing reference types and standards development. She notes about Wasm plugins, "It's probably the best and last plugin model you'll ever need."
In the (near) future, the component model with WASI preview 2 brings WebAssembly modules that can communicate with each other, regardless of the source language. This is what Wasm experts refer to the effort of creating a universal computer. She summarizes with a simple bulleted list, components let us: use the right tool for the job, run anywhere, run within a secure sandbox, but also share no resources between components.
She ends the talk with a callout to get involved through the open standards bodies, the W3C and the
BCA. In the Q&A section afterwards, Bailey outlines the adoption curve for the component model and
her use of wasi-fills in order to fill in current functionality gaps while standards finalize.
The Road to Winch - Saúl Cabrera, Shopify
Saúl, creator of the javy tool, introduced the Winch tool
as a "Baseline, single-pass or one-pass compiler for Wasmtime." The name is actually an acronym:
"WebAssembly Intentionally Non-optimizing Compiler and Host". One of the end goals of the project is
to keep the startup time for Wasm limited to only the amount of time that it takes to actually load
in the bytes of the module. The middle of the talk goes from an informative discussion in the
current way of compiling to the way Winch is structured and how it keeps it simple to efficiently
compile machine code with a way to track it back to the original code. You can use winch in Wasmtime
version 9.0.0 by just enabling the winch feature flag!
# Cargo.toml
wasmtime = { version = "9.0.0", features = ["winch"]}
What comes next is finalizing support for Core WebAssembly, adding in robust fuzzing support for Winch, and adding benchmark suites for comparisons. With rough benchmarks, the baseline compilers are approximately 10-15x faster than SpiderMonkey and V8. If you're interested in joining, here are the meeting instructions in the Bytecode Alliance repository.
Opinion: My favorite class in college was compilers, even though I haven't gotten to get that low-level since then, I have a massive respect for the folks that work at this level of the stack. Hoping to work with Saúl on adding JavaScript support to wasmCloud.
WASI and the Cloud - Jiaxiao Zhou, Microsoft & Dan Gohman, Fastly
Jiaxiao (Joe) starts the talk introducing WASI and throwing it to a recording from Dan, who asks the common question for many people who first look at WASI: "Is WASI just the new POSIX?" He answers the question over the course of a few minutes, backing up to fully approach the problem. One of the key goals of WASI is to have portability in programs between environments, instruction sets, languages, all while being sandboxed and composable. In order for this to work, Wasm needs the WIT IDL, which is how it can handle complex data types, error handling, enums/variants, and handles or resources in order to share capabilities with the outside world. In the future, this will be extended to asynchronous resources as well. Dan also mentions some of the lower-level impacts of this design: source languages are not exposed, no global resource sharing, and garbage collection is left outside of the module's linear memory. All in all, WASI enables a Wasm native API ecosystem.
Joe takes this background and builds on it, bringing the WASI fundamentals to the cloud. Bringing
multiple WIT interfaces together into a collection is done with a
World, and
Joe introduces the wasi-cloud-core world. wasi-cloud focuses on higher level APIs that are
enabled by WASI, including: keyvalue,
blob-store,
SQL,
messaging,
runtime-config, and distributed-lock-instance.
At Deis Labs, they have been experimenting with the wasi-cloud host implementation with slight.
Then, we get to see a demo of wasi-cloud with a simple chat application using the messaging
interface.
Opinion: This is a great talk to catch to learn the fundamentals of terms that get thrown around
often nowadays: WASI, WIT, Worlds, and wasi-cloud. The wasi-cloud contracts follow the exact
same ideology that we embrace with wasmCloud capabilities (hint: they will be the same thing soon!)
and Joe explains the tradeoffs with these interfaces well.
ZeroTrust Microservices with Wasm & WireGuard - Jordan Rash
Jordan comes from a background as a cyber analyst and SOC manager, and after doing it for half a decade he questioned how much you can trust when it comes to software. As a developer that primarily works in Go, motivating coworkers and getting buy-in with a bleeding edge technology that has a lot of Rust can be difficult. From a security perspective, he called out the importance of the sandboxed runtime, access control (AuthN / AuthZ), and TLS to keep an entire stack secure from WireGuard to Wasm.
Jordan then showed an equivalent example with a Go program that's deliberately exploitable, compiling it to a native binary and to WASI, and shows exactly how the Wasm sandbox prevents unauthorized access to resources in the system. Then, he shows a brief introduction to wasmCloud and its additional security aspects: signed WebAssembly modules, contract-driven RPC, policy enforcement, and signed invocations. Putting this all into practice, Jordan wrapped up his talk with a live demo showing a wasmCloud application using Tailscale, Redis, and a static Vue frontend. You can see some of the application components in his open source packages and Tailscale repository.
Opinion: I've been working on wasmCloud since 2019, and I've worked with Jordan adjacently for a few years. Still, his security perspective on wasmCloud is refreshing and exciting, knowing that all of the layers of security that we've built into the stack are getting put to good use.
Lightning Talk: Where the Server Goes, Nobody Knows! - Brooks Townsend, Cosmonic
This talk is actually mine! It's a lighthearted introduction to WebAssembly in the style of a Dr. Seuss poem, and it's hard to encapsulate without you seeing it. For this reason, I'll leave this talk as a mystery and you'll just have to watch the video 😉.
Opinion: I enjoyed writing this talk more than any other talk, and it probably will be my favorite for a long time.
Lightning Talk: WebAssembly and Syscalls: A Story in Tool-Building - Daniel E Phillips, Loophole Labs
At least until this epoch ends in 2038, we'll need to handle POSIX and UNIX based programs in Wasm.
There are a few options to deal with syscalls in Wasm: patch with host functions, ignore functions
meant for a platform, allow scoped access to the underlying host, or provide a Wasm component or
layer that acts like the underlying system. Loophole worked on a project for identifying syscalls
called wasm-toolkit, similar to strace but for
WebAssembly programs. He showed a demo of marcotte-wasm and a scale function, implementing a
serverless Wasm invocation that interacts with the underlying system through a layer. Tying it back
to the overwhelming theme of the day, the component model, they are looking forward to the
parametric linking, resources and handles, and will be integrating with standards to make their
products better.
Lightning Talk: Why You Need a Universal Plug-In System - Benjamin Eckel, Dylibso
Benjamin examines the history of plugin systems, starting with audio plugins with the VST standard. Following this standard extended programs to be an entire market of an industry that still works today (VST plugins work in Apple GarageBand). Bringing it to today, moving from client compute to server compute and back again, many companies created plugins with their own built-in IDLs and SDKs. Calling out Shopify functions as a good example of how Wasm can create a standard plugin, vendors can collaborate on a common standard interface and create a universal plugin system.
Opinion: I've been watching Dylibso since they announced Extism last year, my only regret for this talk was that it was only 5 minutes long! Give me the 16 language plugin demo!
Scratching an Itch: Running Policy in Hard to Reach Places with WASM & OPA - Charlie, Styra
For the first OPA talk of Wasm day, Charlie starts at the high level defining policies and what it means to evaluate policies. He sums up OPA as a declarative language for describing policy rules, a policy server implementation, and the language SDKs which are both for native and Wasm. Rego is OPA's declarative language, and it has a pretty digestible format that showed well on the slides. Next was the demo, which featured WebAssembly modules both running on the client and the server. This shows a classic benefit of WebAssembly's portability, taking server-side logic and pushing it to the client to validate the form. Wasm in OPA has been around since 2018, and now has official and community SDKs for NodeJS, .NET Core, Python, JVM, and Rust. The content in the talk is available on Charlie's website.
Opinion: Charlie does a great job jumping into this talk, going from definition, to practical use, and then to its application to OPA. I'm taking notes here for my next talk.
Future of Component Tooling - Peter Huene & Guy Bedford, Fastly
You may have heard "components" across the day, and Peter begins the talk defining them and some
other terminology used throughout the talk. They are a proposed extension of the WebAssembly
specification, and a way for different modules to communicate between each other. He also talks
about warg, an in-development open source registry for Wasm components. Using a
Svelte app and componentize-js, he takes a
JavaScript source file and a demo WIT interface, finally compiling it to a WebAssembly component.
Using another Bytecode Alliance tool jco, he transpiles
the component back into JavaScript, where he runs his unaltered application using node to test it.
Then, Peter uses cargo-component to link a
component written in Rust to the JavaScript component. He notes a few ways that Wasm will be able to
look a little more idiomatic in Rust, and other languages that support components, with resource
types. Peter both uses the command line to stitch together components, and the clean-looking
wasmbuilder.app that he built to stitch them together with a visual
UI. He uses what Bailey referred to earlier as wasi-fills to adapt to the WASI dependencies using
custom implementations.
Opinion: Despite the work and flurry of BCA tools that it takes to pull off this demo, it's wholly impressive looking at the real usage of Wasm components, especially interacting across language boundaries.
Wasm + Kubernetes: Beyond Containers - Sean Isom, Adobe
Following up their Better together: A Kubernetes and Wasm case study, Sean Isom and Colin Murphy talked about their journey through cloud services at Adobe. From 2014/2015, they faced difficulties with CI/CD, and actually started with running containers with Apache Mesos. At this point, developers had to think about the entire stack, and put lots of complexity on individual teams. Then came Ethos, Adobe's multitenant self-hosted DC/OS solution and then retooled around Kubernetes. Now, Ethos runs an impressive 285+ clusters, with millions of containers, and all-in-all Adobe has been very successful with Kubernetes and containers.
Even if operationally the multitenant Ethos works well, it has a lot of overhead and is excessively
expensive. Most services at Adobe use Spring Boot. They then turned to the success of their frontend
teams running WebAssembly, pushing their native libraries to the web with Lightroom Web, Acrobat,
Photoshop web, and more. "It meets all the same requirements, is secure by default". Ethos
Kubernetes uses wasmCloud to run Wasm inside of Kubernetes, leveraging existing clusters and
resources and simply running the Wasm application runtime as a container while using a multitenant
NATS network. In the beginning, this looked similar to their Kubernetes-only architecture, but as
they improve the infrastructure and make use of Cosmonic services like the
kubernetes-applier.
Sean hands to Colin here, who talks about the specific use cases of signature background removal and their newest service "Content Authenticity Proxy," which is designed to determine if an image is altered either by editing tools or by AI. He dives right into some of the real pain points behind compiling libraries straight to server-side WebAssembly targets, and his journey looking at WebAssembly Text (WAT) files to optimize instructions. All things considered, he was able to get it all in a working state with wasmCloud, and his demo showed taking a generated image, transcoding it, storing its information in the database. Because of WebAssembly, their goal is to take this service and run it on edge compute. Both engineers think that WebAssembly is a tool that helps developers write better software, faster.
Opinion: Sean & Colin do a great job of highlighting their impressive engineering, Kubernetes pain points, and solutions using Wasm. They also talk about their pains with adopting WebAssembly, and point a fair finger at toolchain support for libraries and the challenges that he faced with designing solutions with pure Wasm.
Calling OPA from eBPF, Through WASM, in the Kernel? You've Gone Mad! - Nandor Kracser, Cisco
eBPF and Wasm days usually coincide at the same time slot at KubeCon, so the room naturally buzzed getting to see this talk. One of the first slides brings up the SEO phrase "eBPF vs. Wasm", and Nandor notes eBPF is not a general purpose language, it's built for running programs at the Linux kernel level. It's an efficient in-Kernel VM that allows for low-level tracing and network packet machinery, also with a safe extension mechanism. You can even attach eBPF programs to syscalls or network sockets. We then see OPA based decision making moved down to the Kernel level as a real-world application of Wasm now, which made for an impressive demo.
You can take a look at some of this hard work in the Cisco open source repository:
wasm-kernel-module.
Opinion: It's great to see an immediate comparison between eBPF and Wasm, especially touching on the areas where they do not overlap as some of the high level value props for both can seem competing. Right in the first few minutes I was able to grok the difference as an eBPF novice.
Serverless WebAssembly: Roundtrip Scaling from 0 to 10k in 10 Seconds - Kate Goldenring & Joel Dice, Fermyon
Even in a place where everyone seems to "know" what serverless is, Kate takes good care to introduce and define what she and Fermyon thinks of it as: short-lived, event-driven functions. It enables fast scaling, better utilization of hardware, and both reduces costs and contributes to the goals of the Green Software Foundation. Core to the serverless strategy is multitenancy, and AWS is constantly improving in this aspect with the invention of Firecracker micro-VMs. An ideal serverless unit includes: Isolation, Overhead & Density, Performance, Fast Switching, Soft Allocation, and compatibility. Beyond the innovation of firecracker, WebAssembly takes all of those aspects to the next level when it comes to serverless. Beyond the technical characteristics, she also calls out the need for a serverless unit to be adoptable, portable, and have a good developer experience.
Joel talks about the attributes they paid attention to when building their FaaS cloud, including
process, data, and multitenant isolation. Each level of isolation adds a performance cost, but it
can be minimized for a good balance. For a Wasmtime invocation, Joel puts up numbers for a sample
Rust HTTP handler that a request takes 6500 μs to compile, 7 μs to pre-instantiate, 6 μs to
instantiate, and 7 μs to invoke (overall ~6.6 ms). There were some key optimizations to get there,
including use of wizer for pre-initialization and
various Wasmtime functions to manage the performance of the way they run Wasm. For the end of the
talk, Joel gives the mic back to Kate who shows an impressive load test, invoking spin 10,000 times
at an average latency of 9 ms/request.
Opinion: The deep dives into computer science studies was unexpected but fascinating in this talk. In cloud native technologies today WebAssembly already offers impressive numbers for serverless use cases, and learning more about the efforts to keep this a green technology and reduce instructions for better performance was eye-opening.
How Small Can You Go? Customizing Interpreted Languages for Wasm Environments - Rafael Fernandez Lopez, VMware & Oscar Spencer, Suborbital
Coming from a desire to help users and bring them to WebAssembly, Rafael looked to interpreted
languages to best accomplish his goal. VMware's
webassembly-language-runtimes (WLR)
project looked to reduce dependencies on external libraries and the standard library for an
optimized Wasm experience. The demo showed both the
wasi-vfs virtual file system and creating a PHP CGI
Wasm application, which ends up creating a fairly large binary. Now, Oscar talks about a possible
way to address this issue, which is to include the interpreter and then provide the user's source
code at runtime. With WASI, you can use a preopen to mount a directory with the user source code.
You could also pass files via std file descriptors, or you could create "exceptionally small
binaries" via module linking. Module linking is their preferred strategy, and it ends up resulting
in only a small amount of code to get it working.
Looking forward, the goal will be to use WASI and the component model to begin replacing the functionality in the interpreters with native Wasm support which will even further reduce their size.
Opinion: Interpreted languages have a complicated story, and Rafael and Oscar have designed clever solutions to make Python, Ruby, JavaScript, PHP. Side note: Oscar now joins the elite ranks of individuals who have written WebAssembly manually by hand.
Lightning Talk: Fun with SQLite and WASI-Libc - Jesús González Martí, VMware
SQLite runs anywhere from phones, to laptops, to cars. So, the
natural evolution is to look at running it with WebAssembly to take it everywhere. Jesús talks about
the current effort and status where you can both run SQLite in the browser with
Emscripten and on the server side using wasi-libc. Currently, this
works in WASI by emulating functions like mmap, which was a difficult endeavor. It's important to
remember that WASI is not POSIX, they are gradually diverging from each other in terms of
functionality, and that's okay.
Opinion: SQLite is one of the few well-known applications that have folks working to fully recompile it to WebAssembly, and it was great to hear about that process in person. I think this will be interesting for the contributors to other databases like Redis, or owners of projects that are considering the (possibly difficult) move to compile to WASI.
Lightning Talk: KWasm Operator - The Easy Way for Running WebAssembly on Kubernetes - Max Schmidt, Liquid Reply GmbH
KWasm provides a way for local and managed Kubernetes clusters to run Wasm workloads. The supported Wasm workloads are similar to Docker's support for Wasm runtimes, explicitly noted are: WasmEdge, Wasmtime, and Spin. This requires that there is a node in your Kubernetes cluster that has WebAssembly support, and selects that node based on an annotation.
Lightning Talk: Everything You Wanted to Know to Adopt WASM Now! - Ivan Pedrazas, Docker Inc
With a three-pronged approach, Ivan asks how hard it is for teams to adopt Wasm with the build, ship, and run aspects of software. Building uses familiar toolchains, makefiles, will make this easy. When it comes to shipping applications, this can be made much easier with standard tooling commands and OCI registries. Ivan points to the ability to run Wasm runtimes inside of Docker as a way to make running Wasm applications easy.
Opinion: Adopting open standards and leveraging what people know and love about software development today is a great bridge to the future when it comes to initial adoption of a new technology.
Closing Remarks: Program Committee Member - Liam Randall, Cosmonic
Our very own Liam closes the day out, thanking the sponsors for the event, the CNCF coordinator, program committee, production staff, the bytecode alliance, and all the hard work from the volunteers at the conference. For the next event, Liam looks forward to the continued efforts around the WebAssembly component model and componentizing all kinds of applications.
Thanks for reading this post, and hopefully we see you at the next Wasm day!