The Rise of WASM
"If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing."
This was the quote by Solomon Hykes, the co-founder of Docker said. This is a big statement for the creator of containers. Okay, ya, technically he didn’t invent containers. If we want to be real, containers were first came around in Unix V7 in 1979 with the introduction of chroot. But Docker created the runtime that currently rules cloud computing. In other words, Docker created the modern iteration of containers.
What is WASM?
I love containers, that’s no secret. But I have been reading a lot about WebAssembly (aka WASM) and it seems very promising. Many companies are starting to implement it and it very well may have a place in serverless.
Before we dive deeper, let’s level-set on what WASM is. In short, WASM is a way to turn compiled code into a binary that can be executed in the browser. Imagine turning C++ code into a binary that can be run in Chrome or Firefox.
Up to this point, we have largely use implementations of ECMAScript (Javascript, Typescript, etc.) to execute code in browser. I think this is amazing as I believe the age of operating systems is coming to an end.
Wait what? I can’t be serious right? OSes have been the standard of computing since GM-NAA I/O in 1956! Well what I mean is that eventually, the OS will become irrelevant and the web browser will be the OS from the use perspective. ChromeOS is a pretty successful implementation of this idea.
Think of it like “serverless for operating systems”. The user has all the inner workings of the OS “obscured” and the browser is largely how they will interact with the machine. The OS will largely exist to support the browser.
But I digress, let’s talk about WASM and Serverless.
Fermyon Taking on Kubernetes!?
Fermyon is a startup that was founded in 2021 (per CrunchBase). In short, they are trying to change the direction of cloud native to focus on WASM over Containers. They still work with Kubernetes but it seems like their long-term goal is to evolve past that.
I recently read an article on TheNewStack about a recent panel with representatives for Microsoft where they showed how WASM “can beat Kubernetes, VMs, micro-VMs and even containers in startup times, and Rust can get the code size down to a few kilobytes in some cases.”
At first, I was skeptical. Full disclosure, I have very limited knowledge with regards to Rust and they were talking largely about Rust in this article. With this limited knowledge I can’t comment much about best practices around this workflow. I still want to report on this story though as it does seem interesting.
Ryan Levick, principal engineer at Fermyon, pointed out one of the real shortcomings of serverless, cold starts. For a serverless container to scale down to 0, it is essentially like shutting down a server. When it is time to do something, you essentially have to “boot it up”. While this usually only takes a second or two, in the world of enterprise applications, this could make a big deal. Some providers have architected ways around this with “warm starts” in various ways.
Since WASM binaries tend to be very small and execute fast, that “boot time” of the service would be in the low milliseconds and not noticeable in most use-cases.
CloudFlare Workers to Support WASM
In this InfoQ article they talk about how Cloudflare showcased their ability to run Fortran on Cloudflare Workers with WASM. For those not familiar, Fortran is an old language that really doesn’t come up in conversation much, especially in relation to cloud computing. This feat is an intriguing one.
While I wouldn’t describe this as Cloudflare “killer app” it is pretty near. This led me down a wormhole to learn that Cloudflare workers have supported WASM for a while.
Seeing Cloudflare, one of the quintessential serverless companies, adopt WASM is promising for this technology and I am curious to see what they do next. Stay tuned.
Final Thoughts
WASM is incredibly interesting to me. That being said, there are some shortcomings. One of the big cons is that we aren’t in the “web browser OS” phase yet. While many applications are indeed browser based, a lion share are not. There are attempts to find ways to execute WASM dinaries in a manner that allows developers to run WASM applications server-side. I have seen cool use cases such as running Postgres on WASM but it’s still early.
We may also see a similar container problem to what we say in the early 2010s. Running 3 or 4 containers was easy, running 100 was difficult. We needed a way to orchestrate them which resulted in Kubernetes. WASM binaries are experiencing a similar issue today but this may lead to a WASM orchestrator in time.
Then there is of course the issue with AI/ML. Can WASM binaries be used to train models? Consume them for sure, but do training? Currently we are seeing a lot of people starting to adopt KubeRay, Kubeflow and other technologies to do AI/ML workloads using containers on Kubernetes. I am not sure if WASM is there yet or if it ever will be.
I currently disagree with the notion that WASM will replace containers. I think we are still too early to see this as it’s best used in browser environments. I think that it is incredibly useful for web applications but I don’t forsee it becoming the standard for compute anytime in the near future.
Personally, I think that there is room for both containers and WASM in the world. It’s not and “either-or” situation. You wouldn’t use a screwdriver on a nail would you? It’s about using the right tool for the right use case. For now, I will sit back and watch where this goes.
Photo by Pixabay: https://www.pexels.com/@pixabay/