Why WASM: Quickstart

After KubeCon NA 2024, plenty of people are becoming curious, and for good reasons. There’s a ton of great benefit from an engineering perspective when it comes to performance, cross-platform capabilities, and overall security.

In this quickstart, you’ll learn a few key reasons why you’d want to use WASM and how it can benefit you.

What’s WASM?

WASM stands for Web Assembly, which has been around since 2017. In the beginning, the idea of Web Assembly was to give engineers the ability to create web-based applications with a programming language other than JavaScript. This makes sense for a variety of reasons, but the two primary ones are:

1. You get the benefits of other languages (for example, Go is more performant than JavaScript in many cases).
2. Anyone can use the language that they’re most comfortable with to build the same app because it goes through the WASM compiler.

Speed, performance, and extendibility are great, but number 2 really stands out. Let’s say you have three developers; one writes in Python, the second writes in Go, and the third writes in Rust. They can continue to use the language of their choosing because, in the end, it all goes through the WASM compiler.

In the next five sections, you’ll see a few key differentiators when it comes to WASM.

Compatibility

It can run anywhere and be compiled anywhere. For example, you can combine on an x64 machine and run it on an ARM machine. This is a big deal in a world where binaries are being built locally and some machines are running Intel or AMD CPUs while other machines are running ARM-based CPUs.

This could be referred to as a Instruction Set Architecture (ISA).

Because of the way the WASM compiler works with languages (which you’ll learn about later) and architecture, the goal is that it shouldn’t matter where the code is built. This allows engineers and developers to virtually build it anywhere and regardless of the location, the application stack will run as expected.

Speed

Looking at some stats from a speed perspective:

• From a cold start, Running WASM workloads can be upward to 160% faster than containers.
• WASM can be 10-50% faster than a containerized application.
• WASM containers are a lot smaller (upwards of 80% as they’re automatically deployed with scratch-like images), so startup times are much faster.
• Training ML models appear to be coming in at 2x faster while using 10x less memory.

However, there’s a catch. As WASM stands right now, it doesn’t have multi-threading, so concurrency is an issue. Because of that, not only are concurrent apps an issue (maybe this is resolved with Goroutines), but latency could be an issue as well.

Security

By default, WASM doesn’t interact with any of the underlying OS components like a container or a Pod does.

When it’s built, it uses a scratch-like container image by default, so the form factor is very low. With a smaller form factor and a watered down image like Scratch, security is definitely increased. The reason why is because with an Image like scratch, it’s using such a small amount of Operating System components that it’s incredibly difficult to have vulnerabilities.

From a purely WASM perspective, it’s memory-safe and sandboxed by default. It’s designed to execute in that fashion, so it can’t interact with the Operating System that it’s running on. For example, if you execute a WASM/WASI app on an Ubuntu box, it can’t interact with the Ubuntu Kernel unless you specify it via the Runtime.

Cross-Platform

You can write in as many different languages as you want and WASM will compile it the same way.

For example - you can write your portion of the application stack in Python and I can write my portion of the application stack in Go.

It works this way for both server-side and web.

This is a very beautiful thing because it allows engineers to work more closely together in a way that they’re comfortable.

When I first saw this, it reminded me of when you build a binary in Go. If you have Go code, regardless of what architecture it’s currently on, you’ll be able to build it. If you have Go code on a Windows box, it’ll build a .exe binary. If you have Go code on a Mac, it’ll build a .pkg binary when you run the go build command.

Cross-Source

You can use WASM for browser apps or server-side apps. WASM was created in 2017 and started with browser-based, but in 2019, WASI was created to be used as a server-side runtime outside of the web. This is why you can run WASM apps on a VM or even Kubernetes.

WASM is completely independent of the underlying hardware and it’s up to WASI to figure out how and where it should run. This is how you can compile a WASM-based app on, for example, x64 and run it on ARM.

Ironically enough, the founder of Kubernetes said that if WASM and WASI existed in 2008, containers wouldn’t have existed.