The Future of WebAssembly Through the Eyes of a Veteran Kubernetes Engineer

At the Pasadena leg of Kubernetes Community Days (co-located with SCaLE 20x), I had the chance to talk to 100 or so Kubernetes enthusiasts, to give my perspective on WebAssembly, through the lens of a Kubernetes veteran.

I should qualify this by saying I have skin in this particular game. I've been in Kubernetes since the beginning - starting early with Docker (0.6-ish) and working with Kubernetes since 1.2 - building Kubernetes platforms before they were a thing. I was a core maintainer of Helm for 4 years, and co-creator of Bindle and Krustlet - an early effort to make WebAssembly play nice with Kubernetes. A lengthy way of saying I totally get it, I understand the strengths and the pain points of containers and Kubernetes.

I also come from the WebAssembly space, deeply involved for the last 3 years or so. With feet in both camps, here's my view on what these two open initiatives are good for, and what the intersection could - and should - look like.

Kubernetes and Docker were game-changers because they allowed platform engineers and developers to break up the monolith into microservices and applications, manageable in isolation from the rest of the infrastructure. WebAssembly goes a level deeper, allowing us to split apart individual applications into composable components that can be hot-swapped, managed, and configured separately to their surroundings. Wasm is, essentially, everything we want in server-side code: secure-by-default, portable, polyglot (particularly in the browser), fast, efficient, and highly scalable.

So, how do Kubernetes and Wasm intersect? First, let's address the social media rumor mill and bust some myths.

Myth #1: Wasm will kill containers.

Nope. Definitely not. Nobody's going to rewrite Redis to work in the browser when it works just fine in containers. There are so many instances where Kubernetes is the right solution. There are a number of large enterprise apps (Drupal, Redis, nginx) that have been around a long time that won't move to Wasm any time soon.

Myth #2: I should go ahead and run Wasm in my containers, right?

We're not saying you shouldn't, but it might not be the right starting point and you may just add extra layers of complexity. You have the overhead of starting up the Docker container (which isn't cross-platform), added to the overhead of starting up the WebAssembly. It probably isn't worth the performance overhead, especially with all of the available tools I'll mention later]

Myth #3: Wasm is not compatible with Kubernetes.

Yes, it is! This is a "Better Together" story. Everything is evolutionary with computers. Just because we came up with VMs doesn't mean we don't have the need for physical hardware. And just because Wasm came along, doesn't mean we don't need containers. To see this in action, read how our friends at Adobe are transforming their Kubernetes architecture with Wasm.

Like the early days of Kubernetes, we're in that phase where things are breaking and evolving very quickly. Networking is still difficult on the server side at the raw Wasm level. We will soon get socket support and things are moving fast. Language toolchains and low-level performant code are also crucial but not there yet. It's an exciting moment, though. WASI (non-browser Wasm) standards have come a long way, even in the last couple of weeks - more on that later.

Why Wasm?​

The truth is, Kubernetes has its limits, particularly at the edge. Although lots of progress has been made (huge shoutout to projects like K3s), there is only so far things can go. Kubernetes is meant to be run in clusters that are most often part of the same geographical region. When something is running in a cell tower, power station, or brick-and-mortar store, Kubernetes doesn't scale very well. We've seen this as we've talked to our community members. Wasm is truly cross-platform architecture and runs very small, making it a better candidate for the edge.

Cost and utilization are also major factors. We've talked to several Fortune 100 companies and their Kubernetes server utilization sits around 25-35% of total capacity, with a few up towards 50-60%. Many have spun down their internal Kubernetes teams because it's so expensive. Wasm allows us to pack a lot more into a smaller space and get better utilization out of it.

Security, too, is a major benefit of Wasm. Containers are fairly secure but there are lots of nuances that create complexity, particularly for developers. By default, a WebAssembly module can do nothing unless you grant it the privilege to do so.

What can we do with Kubernetes and Wasm right now?​

With all of that said though, what is it actually possible to do with Wasm and Kubernetes right now? Let's review three of the biggest scenarios where you can leverage Wasm straight away.

runwasi in CNCF containerd​

One really cool way to use Wasm is to check out the wonderful runwasi project that is part of the CNCF's containerd ecosystem. Essentially, runwasi allows you to run a WebAssembly runtime via containerd shim inside of Kubernetes. This is a much better option than trying to run Wasm inside a container as it runs WebAssembly directly, just like it would if you were to spin up a container in a pod.

Service meshes, anyone?​

Envoy and other meshes already have the ability to write plugins using WebAssembly. With these, you can write custom filtering and other plugin models using any language that compiles to WebAssembly.

wasmCloud​

We know companies are already seeing value in bringing Kubernetes together with Wasm in a host of different use cases. But wasmCloud takes it to the next level due to its ability to connect disparate computing in a flat network topology. My second demo showed how easy it is to move the same code across three different nodes each in a different location. In this case, my Mac in Pasadena, a Digital Ocean K8s cluster in New York, and wasmCloud. No refactoring, same code, any location. Next, the Cosmonic platform (built on wasmCloud) will bring the kind of full-serviced approach to Wasm that companies will need as they move to production.

Want to try wasmCloud on a managed platform?

Get started with Cosmonic for free today. Launch Now!

Component Model​

Finally, and most excitingly, things are moving fast in this space. Check out Bailey Hayes and Dan Chiarlone’s WASM I/O talk which showed just how far we've come in defining WASI standards and the Component Model - it was the first view of what we really want the future to look like. You can follow progress here and join the Bytecode Alliance to hear the latest as it happens.

- By Taylor Thomas, Engineering Lead at Cosmonic

If you’re interested in learning more, have questions, or would like to chat, connect with us on Discord or Slack.