WebAssembly Breaks Away from the Browser

Technically Speaking with Chris Wright
00:01 — Chris Wright

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?

00:50 — Chris Wright

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?

02:21 — Ivan Font

Hey, Chris, I got a joke for you.

02:23 — Chris Wright

All right.

02:24 — Ivan Font

Why did the WASM module cross the road?

02:28 — Ivan Font

To get to the server side.

02:32 — Chris Wright


02:32 — Ivan Font

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.

03:22 — Chris Wright

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?

03:43 — Ivan Font

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.

04:37 — Chris Wright

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?

05:21 — Ivan Font

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.

06:29 — Chris Wright

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.

07:19 — Ivan Font

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

07:22 — Chris Wright

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.

  • Keywords:
  • Edge,
  • Security

Meet the guest

Ivan Font

Ivan Font

Principal Software Engineer
Red Hat

Keep exploring

Red Hat and WebAssembly

On the server side, WASM/WASI has the potential to become an industry standard for portable binaries, solving the compile-once, run-anywhere problem.

Read the blog

Start developing for WebAssembly with our new guide

Developing for WebAssembly can go in many different directions, depending on what you already know and what you're trying to build. Our new guide can help.

Read about the guide

More like this

Technically Speaking with Chris Wright

Compute Confidential: In Hardware We Trust

Can you trust computer hardware, even when it's not yours? Trusted Execution Environments (TEEs) bring a new layer of security to edge computing.

Command Line Heroes

Season 9

Malware haunts us all. Viruses, worms, trojan horses, and the harm they do often corrupts the promise of the internet. Season 9 features the people in security who fight back.


How Can Memes Improve Security?

This episode, a couple of Red Hatters tackle an unusual security challenge. And while intentions were good, the memes they planted could have easily been something much more nefarious.

Share our shows

We are working hard to bring you new stories, ideas, and insights. Reach out to us on social media, use our show hashtags, and follow us for updates and announcements.

Presented by Red Hat

Sharing knowledge has defined Red Hat from the beginning–ever since co-founder Marc Ewing became known as “the helpful guy in the red hat.” Head over to the Red Hat Blog for expert insights and epic stories from the world of enterprise tech.