KubeCon EU 2021 Keynote - Cloud Native and WebAssembly: Better Together

This blog post summarizes our KubeCon EU 2021 Keynote - Cloud Native & WebAssembly: Better Together.

In this blog post and the accompanying video, we will share the story of the rise of WebAssembly. We will give you a high-level overview of what WebAssembly is all about, why you should care, and how Cloud Native and WebAssembly are better together.

Whether you realize it or not, your organization is likely already adopting WebAssembly in your environment today - the security, portability, and embeddability have inspired developers throughout the Cloud Native ecosystem. Enterprises are adopting WebAssembly for both its power and potential. We will take you there, but first let us set the stage -

Epochs of Technology

Over the last 30+ years, each wave of innovation has built upon, and further scaled the previous generation’s wave of technology. We can observe, that each new epoch of technology has been dominated by two dimensions: \

1. The first dimension is its format; the format is how we store our applications, what we deliver, what we run, and “the what” we move around.

2. The second critical dimension is the technology we use to orchestrate those formats - to create, delete, scale, and connect these formats.

With the Format and the Dimension in mind, let me explain - the elements of the illustration in PURPLE are the responsibility of the Application builder. The elements of the illustration that are in BLUE are the responsibility of the Orchestration layer

On the furthermost left, The standalone PC started with an image and was manually orchestrated by the data center. In the early days of technology, we begin with applications that were tightly coupled to their underlying technology stack, operating system, and hardware.

This first epoch of technology gave way to the virtual machine, and the virtual machine was orchestrated by the public cloud. We have further segmented our formats with the rise of the container and portable, pluggable, multi-cloud orchestration with Kubernetes.

Observe (the trendline)

Now I would observe a few general patterns and trends.

First, Each epoch has solved the emerging challenges of the waves that came before it.

Second, In each progressive wave, we increased the decoupling of applications from their specific underlying environments. The FORMAT embeds fewer assumptions than the format before it. Think back to data center computers - specific applications were tuned for the particular hardware on which they resided.

Third, a further theme emerges - the underlying layers become increasingly portable through pluggability and extendibility. The Virtual Machine frees us from a specific size and type of computer. And Kubernetes frees us from a particular vendor, size, and type of cloud.

Fourth, each wave continues to free us further from the assumptions built into the previous generation. The veritable container lets developers ship reproducible environments quickly.

Fifth, things today are hardly perfect, and there are abundant assumptions baked into the way we design, develop, deploy and ship software - EVEN WITH CONTAINERS. For example, we are living through the painful upheaval in CPU architectures with x86 and ARM inside modern public cloud environments like AWS. While AWS may be offering ARM-based EC2 instances at a substantial benefit to cost ratio for some workloads, many organizations can not take advantage of these innovations because their entire SDLC assumes that they will be deploying into x86 based environments.

So as we consider, what may be next, let us then project these trends forward unto the next wave - the fourth great epoch of technology will continue the trends of:

1. (Decoupling) Further decoupling of the format from the underlying layers
2. (Pluggability) Increased portability and extension through pluggability and abstraction
3. (Freedom) Freedom from some of yesterday’s assumptions to address the challenges of tomorrow

What is next - Distributed Topologies

The jobs to be done of the previous epoch shaped the next epoch’s design - the need for horizontally & scalable compute led to the rise of the public cloud. The need for shippable environments led to the creation of the container.

So “In the design of everyday things,” we would recognize that we can use the clues in our environment to identify what we need next. And that a well-designed product, something that has a natural fit for the problem space, would have these intentions - these cues that make it obvious how to use it.

And I believe that the solution to today’s broad challenges will be less of a wow experience and feel more like a boring “of course” evolution when considered in retrospect.

Emerging Infrastructure

So here we are - 15 years into the launch of the public cloud. Eight years since the dawn of Docker. And seven years since the public launch of Kubernetes and we are faced with new challenges that are not as cleanly met by today's technology stacks. Central to these challenges is the rise of diverse CPU architectures and distributed applications. The Linux Foundation Edge has helpfully provided us with this wonderful Continuum ¹ to help us understand what the modern ecosystem looks like:

And first glance, it feels pretty straightforward. The next epoch of technology may account for the world from big to small from centralized to distributed. Now, this broad summary can hardly show everything - themes of infrastructure are bundled. On the far right, we have not a cloud, we have multi-cloud. And in the middle, we have not just an edge, but multi-edge. And at User, we have not just browsers, but multi-browsers. And it is clear that the world of tomorrow accelerates an existing challenge - the incredible diversity in CPU Architectures.

I believe only thing missing from this graphic that should be called out is a specific spot on the continuum for the web browser. The browser itself is by any measure the most popular execution environment for code in today's world. With billions of endpoints leveraged directly by consumers, it is a notable execution environment.

From Cloud Native to the Edge

Now let us take this worldview and envision the next great epoch of technology. If we consider the cloud-native landscape as we understand it today, we have so many great fits. Kubernetes on the cloud and increasingly on the edges. Containers riding along with them into parts of the consumer edge. We have service meshes like Envoy², policy engines like OPA³, and dozens of other related projects.

While Kubernetes will extend deep into the edge infrastructure, there will be a lower bound where we choose not to run Kubernetes, Linux, or both. Perhaps we are just considering environments like the web browser, non-Linux devices like iOS, or lower complexity embedded devices.

So, wherein this view do we see our three tenants emerging? Where is the progressive decoupling? Where is the pluggability? Where is the freedom from broad assumptions that we embrace in today’s model?

Decoupling Everywhere

As we have accumulated design criteria, where might this happen? In the cloud? At the Edge? It is, in fact not just one place - WebAssembly builds upon the entire ecosystem. And not just on the ecosystem, WebAssembly is inside the ecosystem, and in some places, it is the ecosystem.

It is both compatible with and free from the assumptions of the previous generation. It transcends our landscape - and WebAssembly is poised to fit everywhere.

WebAssembly (Wasm) 101

If you have not heard of WebAssembly, let me start with what may seem to be an all too familiar promise, WebAssembly was begun as a portable polyglot compilation target for the web. An idea like Java, Silverlight, or Flash the promise of “write once run everywhere” execution.

Wasm differs - both open source and free, a community-driven W3C standard, created in close collaboration with browser engine vendors and shipping in all major browsers since 2017. WebAssembly is not controlled by one single organization, nor does it require plugins to operate. WebAssembly is a compilation target and not a programming language. This is a technology that enables developers and organizations to choose their languages, libraries, and deliver them with a consistent set of tenets.

And like many other great technologies designed for the web before it, such as Java or JavaScript - WebAssembly too has found a home outside of the browser. On the server, on the applications, on the devices, and even embedded within other platforms themselves.

Wasm Value Propositions

And while the future of WebAssembly is dazzling, today it already brings much to the table.

1. Efficient & Fast - it runs at near-native speed
2. Safe & Secure - Not just sandboxed, but it operates in a deny by default mode.
3. Open & Debuggable
4. Polyglot - choose your own language
5. Portable - from Servers to browsers to embedded

WebAssembly & Cloud Native Today

So today we already find WebAssembly runs in, on, and around cloud-native.

1. As applications executing on our big servers
2. As pluggable engines embedded within our applications
3. As Platforms in their own right on the edge
4. Inside our browsers
5. Within the IoT.

WebAssembly for Applications

WebAssembly is already showing up running in and around the cloud-native ecosystem - certainly most of us use WebAssembly on a regular basis whether we realize it or not. Its speed and efficiency are part of the magic behind both Google Earth and Microsoft Flight Simulator.

And the next crop of open source projects are already building upon WebAssembly:

1. wasmCloud, a Distributed Application Runtime for the enterprise helps you build microservices quickly with WebAssembly.
2. Kubewarden, a flexible and powerful admission controller for Kubernetes leverage Wasm.

Are two of hundreds of cloud-native applications building on WebAssembly today.

WebAssembly, as an Embedded Engine

WebAssembly is being incorporated inside of existing CNCF projects. As an embedded engine WebAssembly's key value propositions around speed, efficient size, and security make it an attractive choice as an embedded engine where we might execute code from third parties. Where you once may have turned to Lua or JavaScript to execute untrusted code, we are now starting to find WebAssembly:

For example, both OPA and Envoy both rely on Wasm at their pluggable cores.

WebAssembly as a Native Platform (Krustlet)

And WebAssembly is not only one of the core technologies leveraged by companies like Shopify and Fastly. But it is also showing up with the Kubernetes Rust Kubelet, or Krustlet - as a native Kubernetes payload. Krustlet, which was recently admitted to the CNCF as a member project, enables the native orchestration of WebAssembly in place of using containers. Krustlet can leverage projects such as wasmCloud to allow developers to begin deploying native Wasm projects.

WebAssembly Everywhere

And so it is that as an application, as embedded engine, as a platform, in the browser, or on the edge - a new Epoch of technology has emerged that decouples us further from the limitations of our previous world view.

WebAssembly's Security, Portability, and Decoupling of concerns transcend are a part of our cloud-native landscape - and cloud-native and WebAssembly are Better Together.

Notes

Footnotes

1. Linux Foundation Edge, Breaking down the LF Edge Continuum ↩

2. https://www.solo.io/blog/the-state-of-webassembly-in-envoy-proxy/ ↩

3. https://www.openpolicyagent.org/docs/latest/wasm/ ↩