- 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 you doing?
- Hey, Chris, I've got a joke for you.
- All right.
- Why did the Wasm module cross the road?
To get to the server side.
- Ba dum tss
- No, on a serious note,
the reason for all this excitement, you know,
is that Wasm in general is well-suited
to run untrusted code.
You know, 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.
And so 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?
- Yeah, so right now we have a way
to allow developers to run their WebAssembly modules,
you know, as containers
by leveraging the existing container's infrastructure.
So you can actually build your Wasm module once
in a lightweight OCI image and execute it
on any of your devices using tools
like Podman and OpenShift.
And 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.
You know, 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, you know, lose portability.
Where do you see pitfalls,
or what do we need to be aware of
as we're kind of developing and extending WASI?
- Yeah, so that's a great point.
And, you know, 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.
And 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.
You know, serverless was going
to be this huge paradigm shift and disrupt Kubernetes,
but Kubernetes was smart and ended up saying,
"You know, bring your serverless workloads onto Kubernetes,
and you can run them here."
And I kind of see the same thing playing out
with WebAssembly.
You know, if WebAssembly running
inside a container doesn't make sense
for whatever the case may be, you know,
Kubernetes can still pivot
and provide kind of 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,
it's 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.