WebAssembly Breaks Away from the Browser
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.
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.
Why did the WASM module cross the road?
To get to the server side.
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.
Meet the guest
Principal Software Engineer Red Hat
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
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.
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.
Check out our podcasts
Want to hear more tales from the tech world? Red Hat’s award-winning podcasts feature remarkable stories from makers, coders, and leaders across the industry.
Presented by Red Hat
For 25 years, Red Hat has been bringing open source technologies to the enterprise. From the operating system to containers, we believe in building better technology together–and celebrating the unsung heroes who are remaking our world from the command line up.
Red Hat legal and privacy links
- About Red Hat
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit