No matter how many development frameworks, CPUs, or operating systems we create, we seem to be on a perpetual search for more portable software. Now, in the past, we've made strides with Java and containers, streamlining the process of building and deploying software. But as technology evolves, so does our definition of what's considered performant and portable. And now with our increasing reliance on edge and remote workloads, there's a greater need for lightweight, secure, and architecture-neutral runtime environments. But, could the saying, "Everything old is new again," offer a clue to the solution we've been searching for all along?

WebAssembly, or WASM, is a low-level assembly-like language originally designed to execute code portably in a browser, any code, even your old C++ apps. So, how do we go from a high-level language like C++ to something portable and interpretable by any machine? We compile it to bytecode. Bytecode is effectively a low-level translation of code generated by higher-level programming languages like Java, Python, or C++. The benefit of bytecode is that it can operate on any machine that has the right interpreter, which means that the same code can run on different types of devices and operating systems.

One of the main goals of WebAssembly is to provide a common target platform for code written in various programming languages, such as Rust and JavaScript. This lets developers write code in the language best suited for their problem and to have it run on the web with the performance and compatibility of native code. WASM also provides added security isolation, which helps to ensure that the code that runs in a WASM environment is protected from malicious attacks, which is great if my code is running in a browser on a client, but nowadays, our code has to run on a variety of platforms, servers, and edge devices.

So, how can we extend WASM to the server side? To get some insights into this, we have Ivan Font, a Red Hat principal software engineer working on emerging technologies.

Hey, Ivan, how are you doing?

Hey, Chris, I got a joke for you.

All right.

Why did the WASM module cross the road?

To get to the server side.

Boom.

No, on a serious note, the reason for all this excitement is that WASM in general is well suited to run untrusted code. It offers a lightweight, secure, and a powerful approach to run your code across many different platforms because it's actually both CPU and OS agnostic, and it doesn't sacrifice performance. And WASM code runs in this sandbox environment, and so you get that security posture that's really attractive. With those benefits on the server side, it also has huge potential for the edge. But I'm not someone that subscribes to the theory that it's going to replace containers, just like containers didn't replace VMs. I see it as just another tool in the developer's toolbox to help them build their applications.

I hear you there. These technologies seem to persist, maybe indefinitely. But when we hear things like, "It's lightweight," "It's secure," "There's applications on the edge," what potential do you see for WASM in these environments?

Right now, we have a way to allow developers to run their WebAssembly modules as containers by leveraging the existing containers' infrastructure. So you can actually build your WASM module a once in a lightweight OCI image and execute it on any of your devices using tools like Podman and OpenShift. So, when you combine that with the security you get with WASM, this technology is quite compelling for the edge.

But, of course, WASM is limited by itself. The future of it as a server-side technology really depends on where this technology WASI goes. And WASI stands for the WebAssembly System Interface. And WASI extends WASM with a set of common POSIX-style APIs that provide typical operating system-like features, such as things like file systems, sockets, clocks, and random numbers.

So we're taking containers, container portability kind of to a whole new level. I see some similarity. I mean, we've had tools like this in the past. Java certainly was about portability. But then with Java and JNI, the Java Native Interface, you kind of poked a hole through the JVM abstraction layer and became anchored directly to the OS. And I see some similarities with the potential for WASI to lose portability. Where do you see pitfalls or what do we need to be aware of as we're developing and extending WASI?

Yeah, that's a great point. And we do have to be careful not to follow the same fate as Java. But WASM is already part of the web platform. So it's already avoided that same fate because Java applets, for example, didn't end up succeeding. So WASI has to maintain its security-focused approach. And if it stays true to its mission, it will restrict a lot of the APIs that you can call without having the runtime involved to delegate permissions that the WASM module will need.

And since it's also possible to run WASM modules natively outside containers, that might be where Kubernetes has to pivot and adjust, just kind of like it did with serverless. Serverless was going to be this huge paradigm shift and disrupt Kubernetes, but Kubernetes was smart and ended up saying, "Bring your serverless workloads onto Kubernetes and you can run them here." And I kind of see the same thing playing out with WebAssembly. If WebAssembly running inside a container doesn't make sense for whatever the case may be, Kubernetes can still pivot and provide a generic workload abstraction for any type of workload.

I like that. That's an interesting point. I mean, I see a world where Kubernetes is beyond containers. We already have VMs bringing in WASM workloads. This being still the control plane at the center of all this. Really, you can see how this could evolve. I mean, it's impossible to predict the whole tide of technology, but we've had sort of evolutionary movements like this before. And we can see certain practices and technologies coming from these movements. I mean, OpenStack to VMs, isolating workloads, and containers with Kubernetes bringing out this software architecture and microservices approach, and then WASM kind of adding more of a serverless paradigm. This is definitely exciting stuff. So, thank you so much, Ivan. This has been great.

Yeah, thanks, Chris. My pleasure. Thanks for having me.

It's still too early to say for certain how disruptive WASM will be in the long run. However, it has the potential to make a real impact in certain industries and markets, particularly in areas where web-based applications and services require high performance, low latency and portability, like edge. There's palpable excitement around how this will evolve as it integrates with ecosystems like containers and Kubernetes. And it's definitely something to keep an eye on.