 Hello, and thank you for coming to KubeCon EU 2021 Wasm Day, where we've been spending time at the intersection of WebAssembly and everything cloud-native. A tremendous thank you to Chris A., Eleanor Vogel, the CNCF staff, and my fellow Wasm Day program committee members for putting on an incredible event. I'm Liam Randall, and for the last couple of years, I've been working on a distributed application framework for microservices that leverages WebAssembly called WasmCloud. And today I'm going to share our perspective on WebAssembly as the future of distributed computing. Let's jump right in. WebAssembly brings some powerful value propositions to any domain, distributed or not. People are excited about WebAssembly, sometimes referred to as Wasm, for a lot of reasons. And while the future of WebAssembly is simply dazzling, today it already brings a lot to the table. First, it's efficient and fast. It runs at near native speed. Second, it's safe and secure, not just sandbox, but it operates in a denied by default mode where we need to explicitly grant capabilities. Third, it's open and debuggable. Fourth, Wasm's polyglot, choose your own language and you can bring well-tested libraries to a new domain. Finally, it's portable. WebAssembly is a compilation target and it runs on lots of different things, servers, browsers, embedded devices. Heck, you can even put Wasm inside of other applications if you wanted to. Next, let's introduce the modern distributed computing environment. The Linux Foundation Edge has helped to put together this continuum, a view of the world we can use as a starting point. This view of the world helps us to frame the complexity of the modern distributed computing environment. There are many different device types with a variety of system architectures and capabilities, but these categories actually undersell the complexity a little bit. Because if we annotate this view just ever so slightly to include some additional context with some of the platforms that are both incumbent and common in the ecosystem, we get a more complete and complicated world view that we need to account for. For example, on the service provider and public cloud edge, we of course find Kubernetes in both regular and microsizes and we find applications that are hosted on top of Kubernetes. We should include developer environments in our ecosystem as well. And certainly, if we're including mobile devices, we should have phones and lots of browsers and smart TVs and all the rest of the IoT. Even the really small things with teeny tiny capabilities. So let's pair up this new environment with our current evolution of technology. Now, over the last 30 years, technology has continued to evolve over two primary dimensions, the formats in which we deliver applications and the orchestration of those formats into a specific environment. Now, this picture, all the green is provided by the developer building the apps and the blue is the platform layer. And while 15 years ago, the launch of the public cloud ushered in its own revolution, the launch of Docker in 2013 and Kubernetes in 2014 accelerated the pace. And now today we find ourselves on the cusp of yet another revolution with WebAssembly. As we can see over time, these formats have gotten simpler and more decoupled from the underlying environments. We're moving from a tightly coupled world on the left to a more declarative world on the right. And the developer responsibilities continue to be reduced further by decreasing the number of things that they're responsible for maintaining. Let's put up some comparisons and see what really stands out. If we start to line these technologies up side by side, we start to uncover the patterns that emerge in the ecosystem. Each progressive wave has further to covered applications from their underlying architectures. That is to say with each format, we've carried fewer and fewer assumptions forward into the landscape. And we see this reflected at both the where our formats can run and in the security boundary. With security in WebAssembly, we've moved to an entirely sandboxed approach and we'll review the deny by default explicit granting of capabilities shortly. And the where is part of the reason why we believe that WebAssembly will come to dominate distributed computing. In fact, let's take these two world views and put them together. By observing what we are already seeing across today's ecosystem, we have compelling evidence that Wasm today is on the path to becoming the critical technology leveraged to deploy software across the distributed continuum. As examples, starting on the far right, we see native execution of microservices on servers with frameworks like Wasm Cloud. In research, we are already seeing WebAssembly as a native orchestration technology for Kubernetes with Microsoft's Crosslet, the Kubernetes Rust Kubelet. We see Wasm inside embedded inside critical technologies. For example, both OPA and Envoy are leveraging Wasm to execute untrusted third-party plugins where previously they might have chosen Lua or JavaScript. On the edges, we see organizations like Fastly and Shopify using Wasm as a deployment platform to run third-party untrusted code. If that pattern feels familiar, get used to it. I think a lot more organizations are starting to recognize that all code should be treated as untrusted code. We see thousands of examples of applications running in browsers on mobile phones, on tablets, and in web browsers everywhere. Google Earth uses Wasm. So does Microsoft Flight Simulator. Microsoft even makes a toolkit that leverages WebAssembly in the browser called Blazor. The anecdotes are one thing. What are the real challenges of this distributed environment and how well is Wasm actually stacking up? Now, this is not an exhaustive list. However, today I will highlight five critical challenges to be solved in distributed computing. First, the diversity of system architecture, which is that as cloud-native community, we are no longer targeting just the x86 monolith. CPU, memory, functionality, capability, and OS are all invariable now. The second great challenge will be the diversity of application architectures. How will these things be connected in the near future? What design patterns will they use? How will they speak to each other? The third will be our approach to distributed security. Fourth will be offline use. This incredibly diverse ecosystem will be running loads of complex software. And finally, bringing machine learning to the end devices to make them intelligent. Okay, let's just make them less dumb first. Both the number and incredible diversity of devices connected to the internet continues to simply skyrocket as we head towards an estimated 50 billion connected devices in 2030, the enterprise, the enterprise integration tasks are compounded by a dozen popular and incompatible CPU architectures, each of which has its own relatively unique operational lifecycle from dozens of major manufacturers. WebAssembly is already well positioned to operate well in this complex environment. Wasm runtimes can even be optimized to adapt an application for specific circumstances. For example, the bytecode alliance is wasm time for servers and their wasm micro runtime or whammer for short has been optimized for smaller embedded devices. Surely these vast collections of distributed and connected ecosystem systems will be interconnected in tremendously different ways and tier applications, model view controller, pub sub, microservices and more. Today we already see WebAssembly running on embedded into and running around our software stacks. Wasm excels here as well, its near native performance makes it ideal for standalone embedded or other types of integrations. As a component, we already have many large scale examples of WebAssembly running in complex stacks. Now the security of IoT is a broad topic. However, the native security design of WebAssembly is a welcome addition to distributed projects running anywhere in the continuum. WebAssembly itself functions as a sandbox, helpful when you want to adapt or bring code to a huge variety of complex systems. And WebAssembly brings to the ecosystem a powerful approach to capability based security. If you think back not that long ago when you started a child application, it usually inherited the rights of the parents. So if I could write or read to disk, then so could my child process. In more recent years, however, nearly every industry has started to migrate to a capabilities based approach where an application must be explicitly granted access to a capability in order to use it. With WebAssembly, the combination of a sandbox and deny by default approach means that is more difficult to abuse and compromise your applications. Now it is easy to think that when we're connecting billions of devices to the internet that we can simply offload all of the functionality to remote API services and that these could be dumb endpoints on the end user side connected back to an ultra smart core or that the edge moves the capabilities closer to the users and minimizes any performance impacts. While these are two valid and common architectures there are many compelling reasons to believe that most devices will be both connected and still offer some level of functionality when offline or during intermittent connections. Real complex logic will need to live on the device because for a few reasons. First, latency and determinism. For example, driverless cars need to react instantly. Second, large data must first be processed where the data resides at the devices. Perhaps an ML model extracting metadata to be shipped back back to the public cloud. Third, privacy and security will keep logic at the edges. Some data shouldn't just shouldn't be shipped. Fourth, limited or deliberate autonomy. Some devices will need to be able to operate under all conditions without connectivity. Ships far out at sea. Rovers, drones, even refrigerators. Finally, regulatory. GDPR and CCPA are the start of things to come. Big tech is going to be further regulated in the future and this will impact the where and how in the design of our distributed software systems. What this means is that these 50 billion connected devices by 2030 will amplify our workloads. These devices may be small, they may be cheap, but they will be increasingly intelligent and complex. For the aforementioned reasons, web assemblies right once, run everywhere, security model and portability are sure to come into play. Finally, one overarching theme of IoT will be making all the dumb things in our life smart. Tuning and optimizing models is difficult enough without having to worry about the differences between hundreds of potential different deployment chip sets. Even today, incredibly compelling work is coming out of the Google TensorFlow.js team where they are compiling ML models for use in the web browser, running and leveraging the speed and performance of web assembly in the browser. And Andrew and Son over on the Intel team have already ported their Wazi NN machine learning framework to Wasenton as an experiment. I can imagine a near future where these models are run throughout the distributed continuum. I hope you have found today's talk about distributed systems interesting and informative. If you care about these topics as much as we do, I hope you'll follow along as we build an enterprise solution to help developers navigate these complex opportunities. Join us working on WasmCloud, our open source distributed application runtime for the enterprise. Or for more information on future enterprise offerings, sign up for our early adopters program at Cosmonic.com. Thank you very much and have a wonderful KubeCon.