 Okay, so we've got a lot of ground to cover and I'm not gonna waste anybody's time. At least I hope not. So this is me. I am a long time security entrepreneur and engineer. I was the founder of the Bro-Z company if you're familiar with that. That's one of the open source communities I built about 15 years ago. I was the first check into OSquery and convinced Mike and Zach to leave and start the OSquery movement that has manifested in a couple of companies. I created one of the first Kubernetes companies that was called Critical Stack. It was a security-oriented distro, actually. We used this amazing little project called Cilium, which now, of course, has its own life. And I'm also an investor in Cloud Custodian, which I open sourced and put into the CNC while I was at Capital One. I helped to co-create WasmCloud, which we're gonna talk about today. And I'm the CEO of Cosmonic. Father of three, I make wine, beer, and cheese. I'm happy to talk about any of those things later. So we've got a busy agenda today and I've kind of broken this out into a couple of little stories to bring everybody along together. We're gonna start at the beginning with where we are with the abstraction of containers and we're gonna talk about some of the leaky abstractions, some of the easy opportunities that we have to make the current landscape better. So let's get started with containers and their assumptions. Over the last 20 years of tech, we've all seen these increasing abstractions, these bottoms up platforms that started maybe in the late 90s with the rise of VMware and the virtualization products that quickly transitioned into AWS and into the cloud. And it's been a pattern. We've gone along and we've said, hey, we have this common infrastructure like the CPU. Why don't we share it and make it a platform so we can continue to build higher to pull things out of the lives of developers. And the blue on the bottom are the things we continue to pull out of the lives of each and every developer. Or at least that's the idea. I don't think that we always do a great job, but we've done the same thing with operating systems, containers, cloud APIs and Kubernetes. But the question is, is where do we go from here? Now, the thing to observe about each one of these abstractions is that they bring a certain number of assumptions with them. So no abstraction is sort of opinion-free and containers bring two key assumptions. One that you're compiled for a specific CPU. The second that you're gonna be running on Linux and you're gonna have some sort of Linux-oriented security model. And we'll see that the modern landscape doesn't really hold up. And today and all day yesterday, you've seen an example after example of these leaky abstractions like log4j when you think about above the stack bleeding into the bottom of the stack here. So let's talk about the attack surface. You've seen a couple examples of this today, so I'll just rush through this one quickly. But I quickly pulled together a web shell that I wrote in Go to simulate some sort of a vulnerable library. And I've done this example and I can give you a script if you'd like to do this in your environment where you can pivot through your cloud infrastructure and all of those sorts of things. It's up on my GitHub. But there's three layers that we're gonna work with here today. We're gonna work with the container layer, which we're gonna look at, of course, the obvious idea of shrinking the attack surface through using smaller and smaller containers, but we'll talk about the lower bound there and what's left. Then we're gonna talk about this vulnerable library, which is a web shell in Go. There's a forward slash exec parameter and it simply will take whatever you pass to that and then execute it. And then there's our business logic, which we unfortunately can't take out of the application because that's the whole point of the application. So let's take a look at this web shell real fast. So it's running here, there it is in my GitHub if anyone would like to pull the code as well as the other examples. But I've got it essentially running in a few different containers. There's a Fedora container here, there is an Ubuntu, an Alpine, and a from scratch. And the general concept is still the same, right? With any of these containers, you can hit forward slash exec and you can simply pass commands in. So I could pass in LS, I could pass in whatever we wanted to do. We could start pivoting through the infrastructure, downloading binaries. And of course the story that everyone in here I think knows is that by the time we get to the Alpine container, there's nothing left running in that Alpine container. So I'm sorry, when we get to the from scratch container. The from scratch container doesn't have any operating system components with it. It's embracing this principle of having the smallest surface area possible to attack. And if we try to pass even a simple command here, like LS, it just craps out. And it says, hey, there is no LS because the only thing in this container is this binary. And that's great and all from a perspective of that particular application. But as a class of problems, we're stuck with these vulnerable libraries because of the way that we build our applications. Think about all the things that you need to do once you get to the operating system to get an effective application running, web servers, database connections, logging, security, compliance, risk management. Aren't those things common as well? Just as common in enterprises as the operating systems? So if we start to think about what goes above that stack there in the yellow, we sort of have this obvious problem that maybe we're not done with abstractions. And we're doing this with things like Istio when you think about doing a layer three abstraction. We'll look at that in a second. And below that stack, because containers aren't really a full abstraction away from the underlying platform, you bring with it the assumptions that you're running on Linux. You bring with it the assumptions that you have a security model that is tied to Linux. You actually have two additional problems there. And does this really fit the modern landscape? So let's talk about today's world. If the last 10 years of security was dominated by this great lift and shift into the cloud, the next 10 years of security will be dominated by this great movement and build out to where the data is, to where the users are. And there's a large number of reasons for that that we'll talk about momentarily, but even if we were to build the same application for, say, Samsung televisions, a website or an edge provider, we have a number of things above Kubernetes and above containers that become domain specific. Each one of those will have, you know, Cloudflare and Fastly will have their own SQL implementation on the edge or their key value store. In AWS, you might use Redis, who knows what you're gonna use down on that edge device there. But regardless of what industry you're here from today, every application you build embraces even more assumptions than that. All of your customers, because of their experience with the Fangs, want applications that are mobile-first, that are real-time, that are available 24-7, that are personalized and proactive and increasingly enriched by AI and ML. And what that means is that if you own those platforms and security for those platforms, your developers have a common set of requirements above you. And that is an opportunity for you. If we play these forward, even the idea of being available means you'll be running in at least two regions, if not multiple clouds. And the problem or opportunity, if you will, even gets more than that, when you think about all of the other reasons that the compute is going to the edge where the data is, it's not just latency and determinism or performance, it's also regulatory. There was an excellent observation earlier today around the consequences of data locality, of requirements like you have in China now that the data no longer leaves for processing or for storage. So if your developers are serving those markets or increasingly even European markets, you need to deliver your execution, your applications to clouds that may not be your preference. If you're an AWS shop, you may be required to build on Tencent or an Alibaba. I played this forward. This was the second performing article on the new stack last year. If you follow that QR code, you can read a six or eight pager about it that kind of walked through those challenges in a little bit more detail. But the big idea is that Kubernetes gives you portable execution. Containers give you portable operating systems to a point. But applications are not portable. And it really highlights that there's actually three big problems that you're dealing with. The line above where your platforms now are applications and a ton of garbage. And that garbage continues to be found vulnerable over and over and over again. And it's common garbage. And below that line, because you're using containers, you are embracing these two assumptions in the platform about portability and the portability of your security. There are times when you want to bring your applications to places where you don't have a CPU or below the lower bound of Kubernetes. Think about iOS or inside of web browsers, possibly the two most popular deployment platforms on the planet period. And neither of those uses containers. So let's introduce WebAssembly. Now just by a show of hand, who has heard of WebAssembly? This is gonna be like a linear function that falls off super fast. Who's using WebAssembly? One person, two. Alan, Alan spoke at WebAssembly day yesterday. Not very many people. Well, let me shock you and let you know that you're already using WebAssembly. Who's using Envoy? You're using WebAssembly. Who's using Kubewarden? Anybody? You would be using WebAssembly if you were. We'll get to more deployments. Fintan Ryan, the Gartner analyst who's covering WebAssembly wrote, "'WebAssembly is the one technology "'you don't need a strategy to adopt "'because you're already using it.'" So let me shock you with this big idea behind WebAssembly and stop me if you've ever heard this one before, right once run anywhere, right? Java, Silverlight, Flash. We've tried that. Those were all initiatives that were begun by single companies that were plugin-based, that you had to bring those capabilities to your deployment environment. And the problem there, there was many problems, but one, competitors weren't going to embrace each other. Containers were marvelous because they got baked into the Linux internal, C-groups and namespaces. So we had this common platform of deployment to build on. And the vision behind WebAssembly that you already have today as an opportunity is that WebAssembly is already running and supported on all of your devices. It runs on all of your mobile browsers, all of the major ones anyway, on both mobile and your desktop versions. So you've seen early adopters rush to embrace WebAssembly like Adobe, like Google. Folks that understand the impact and are launching product suites on that sort of seamlessly blend this idea between front-ends and back-ends because there's really a common runtime that now transcends the deployment environment. Now WebAssembly is pretty cool. Unlike Java, it doesn't come with a language. It's a compilation target. So theoretically all languages, and today many languages, can be ported directly into WebAssembly. It's incredibly fast, safe and secure. Think of it like a portable CPU that you can put inside of things, including other applications. One of the big use cases. It's polyglot and because it's so small that it doesn't include all the overhead of starting a container, going from zero to one or the cold start problem is minimized with WebAssembly. This article linked here talks about the sort of cold start time between even optimized containers versus WebAssembly. But let's talk about the two problems below the line, below the platform here. When we talked about that landscape that transcended edge computing and data centers and clouds that went all the way down to the endpoints, I wanna point out that that is a problem, a portability problem that you have even if you're in a single cloud provider today. Think about if you're in AWS and you'd like to start using this new Gravitron CPUs. Because containers have an assumption that you're compiled and built for a specific CPU, you're setting up another whole pipeline to build an ARM version to run on those CPUs. And Alibaba has an ARM CPU, an X86 and a RISC-5. The increasing number and diversity of CPUs that we see is going to continue to accelerate. Both Amazon and Google have custom GPUs and TPUs now. So this is a problem or opportunity for you to embrace from the portability perspective. Well, let's talk about the security model that comes with WebAssembly. WebAssembly is denied by default for everything. And this is a concept that you're already familiar with, this capability-driven security model. The idea that to get access to anything, you need explicit permission from a user. And you're already embracing this idea when you install web apps, or when you browse to a web version of a, I'm sorry, when you install native iOS apps here, or when you browse to a native version of a web version of an app and it says this app wants to use your microphone, this app wants to use your capabilities here. And if you want a peek of what the future looks like, simply glance at your Chrome settings here for each page and you can start to see that modern web browsers are presenting an abstracted set of capabilities that are common to the applications above them. And that explicit level of permission, the future of computing looks more like this than it does the cloud APIs that you're building on now. So for those first two problems that we talked about that are below the stack, WebAssembly gives you increasing options. And this is not a Docker or container versus WebAssembly talk or even opportunity because you can go turtles all the way down if you want. You can take WebAssembly or our framework WasmCloud, you can put it in a container, you can run it on Kubernetes, you can run that in the cloud on real hardware or manage virtual hardware all the way down. And you still get most of the benefits that are here. And when we talked about the places where you're already using WebAssembly or Wasm for short, you're already embracing it everywhere. Who's using AWS on Prime to watch videos, right? You have a Samsung TV, a Sony TV, they did this incredible blog post about how they're using WebAssembly to deploy capabilities down to over 8,000 unique CPU OS combinations that are out in the field. That's a good example of a cutting edge company that is embracing this mentality in delivering solutions to their customers. A Crosslit is a project that a developer on our team, Taylor Thomas, works on with a variety of other developers. It enables direct orchestration of WebAssembly in Kubernetes. And things like Envoy or Kubewarden and many other CNCF projects are taking WebAssembly and embedding it inside of their own applications. Why? Because of all the reasons that we just talked about. If you want to customize your application, if you're building some sort of a message queue, expect all of these message queue type things like Infineon or whatever they are to put WebAssembly inside of them so that you could customize streams on the fly. If you're a platform builder, what would you want? You would want a technology that is maybe polyglot, is fast, safe, and secure. So WebAssembly fits a lot of the build there. So let's talk about the problems above the stack which I will colloquially call boilerplate farming and I would just observe that the problem with applications is that they're full of code. And by that I simply mean that they're full of the wrong types of code. Because WebAssembly gives us some opportunities for the portability and a security model that's portability, but what about the disaster that is this top layer here now? This idea that we take these applications and we tightly couple them with a specific set of dependencies. You bake log4jn, not a generic logger. You bake callouts to bash in, not some execution callout. You bake specific database drivers in. These problems that we leave in the hands of developers and the nightmares they make for us, the security teams, the platform builders are many because it's not just the common technical requirements that end up in that layer. As security teams, we bring requirements such as logging, such as business objectives, performance monitoring, all of these other things become a new common platform that we're building on top of. And I've had the pleasure of getting to check out all the code at a number of large organizations. I think organizations that have 20 to 30,000 unique applications in this specific organization. And the shocking thing that I found out when I was doing this research was that for most enterprises, the vast majority of your code base is not only open source, but it's common open source. And that makes sense. You're not terrible people. You wanna give your developers, you might be terrible people, but you wanna give your developers a good starting point, a place where they can pick up as a template and build their applications. But what we're doing is is we're then taking those vulnerabilities like log4j, and instead of managing them at a platform layer, we're managing them on an application by application basis. And above the stack, this is quite possibly the biggest opportunity in your organization because your developers are overwhelmed with managing this common code. These non-functional requirements that we have constitute the bulk of the code and the bulk of the work around them. Think about all the demos today. How many of those demonstrations of, and even yesterday and the days before, talked about functional requirements for an application, like compute the interest rate or get the firmware from the tractor, something along those lines. They weren't business requirement, they weren't. They keep, people keep demonstrating and talking about these systematic requirements that are non-functional in nature. And if we can move those to the platform layer, then we have an opportunity to update them once in the platforms versus doing the same work over and over and over and over again on an application by application basis. So when we think about this platform gap, the idea is to continue to converge and make the platforms healthier. And this honestly is not that crazy or new of an idea. Istio, for example, takes this concept and says, look, at layer three, we have many common requirements. So let's stop putting those in each and every application. And Dapper, which is a toolkit from Microsoft, does that in a very tightly coupled way for Kubernetes. My question to you is if layer three is good, why don't we turn it all the way up to layer seven? And that's the idea that we have with WasmCloud, is to provide a framework that leverages WebAssembly that gives developers all of the functional, non-functional requirements included in the stack. So we launched WebAssembly, I'm sorry, we launched WasmCloud out of Capital One in 2019 and the community has absolutely exploded in the last few years. Now, WasmCloud is a framework for WebAssembly and you can do the same thing that you're doing in WebAssembly today that you're doing in your current apps. You could take all of your libraries and compile them all down into WebAssembly. And what's gonna happen when those libraries are vulnerable? You're gonna have to rebuild and redeploy those applications. So our vision and our view for the future is an area where we let developers write their functional requirements and we leave everything else to the platform. Our idea is that then your binaries are not only universally portable, but they're more secure. There's significantly less expensive domain on a per application by application basis. They can easily move across clouds, edges and boundaries. And ultimately it increases the development velocity of your organizations. These are real numbers from actual POCs that we'll talk about here at the end. There's a whole bunch of videos yesterday. We had a whole WebAssembly day here at KubeCon and there were a large number of WasmCloud, things that were demoed yesterday. But the world that you live in now today, the dirty secret is that every application starts with 20,000 lines of someone else's code. That you then saddle a team to develop and maintain. There are some solutions and efforts like automated vulnerability patching or templating or building custom CI CD platforms that automate these things, but you're ultimately embedding 20,000 lines of executable code in each and every application. With WasmCloud, the only thing that the developers need to write is their business logic. Everything else comes in like a set of Lego blocks. If you want SQL, you just import the SQL contract. On the other side of that contract absolutely gets connected to a specific database, but our SQL provider, for example, can easily be moved from RDS type databases, Postgres MySQL into databases you're running yourself, Azure, DynamoDB, Single Store, and other databases, for example. And our other capability providers are very similar to that. So this increasing abstraction, let's talk a little bit about what this looks like. So WasmCloud is to WebAssembly what React is to HTML. It's a template, a framework you can use to get started to build your applications. So we'll go through all of the various components here. So I like to help people understand WebAssembly by saying, think of it like a virtual CPU. And it's not even that complicated or in advance of a CPU yet. It's a very risk-oriented type architecture, but there are SIMD and MIMD proposals that will eventually, I think, be included in this specification here. It's very fast, it's very small, but it's also very simple. It doesn't deal with complex data types. It doesn't include an operating system. Now there is a draft standard that's on the way that's called WASI, which is the WebAssembly system interface. And you can think of this kind of like a virtual POSIX environment. Think of it as giving you those common abstractions like open file, open network socket that you can use to build higher applications. But I don't think that's the right abstraction for you, and it's certainly not the right abstraction for your developers. What your developers really want are much larger building blocks like SQL, like message queue, like a logger. And those are the things that we've baked into WasmCloud. So WasmCloud is this framework that underneath uses a variety of other projects, including NATs and Elixir. But to the developers, they don't need to know anything about that. We just deliver a model that lets them start with their language and then write a simple business logic. The capabilities are hot-swappable. They can hold state here, but above this we actually enforce a stateless paradigm. So when you think about holding state, if you wanted to recurse through, say, records returned from a database or something like that, you can absolutely do those things here. Most powerfully, WasmCloud goes where you want to take it. There are lots of models out here that are very similar to WasmCloud. When you look at Fastly has an edge product that lives in their walled garden, and Cloudflare has an edge product that lives in a walled garden, and they are wonderful products. But you can't take those products into your devices or into your clouds or into your Kubernetes. And I think one of the reasons driving the explosive growth of WasmCloud is the simple fact that we believe in better together. We ship HelmCharts, right? You can start in your Kubernetes or manage Kubernetes. We ship plugins for Nomad, lots of other types of integrations like that to bring the compute to where you are today. Like many good open source projects, this is a completely pluggable. So we ship the most common Lego blocks that you need based on our statistical analysis of microservices at the large organizations that we're working with now. But we've had many companies, for example, BMW presented on Saturday at Cloud Native Rejects about bringing machine learning capabilities to WasmCloud. They implemented this awesome project called Wasiann in conjunction with Intel, and that gave you both TensorFlow as well as Microsoft Onyx models that are now portable across these edges. Alan here in the audience, he did a presentation yesterday at Wasm Day where he talked about building a capability provider for Bevy, the online gaming engine. So it's extendable to any type of coupling that you would want, whether it's tight or not. Now, above this, when we get to the business logic, we suddenly now enforce this stateless and reactive approach, and that's powerful and important because it means when you think about those non-functional requirements about availability and scalability, when you want more X, you can simply scale it vertically within your process or horizontally across multiple processes. And WasmCloud includes a network between those capability providers based on NAT and your logic so that WasmCloud hosts can easily live across clouds, edges, or devices. Makes it very fast, very easy, and very portable. So I'll talk about a couple of quick case studies and then I think we'll have just a couple of minutes for questions at the end here. Our community's blown up. Please follow any of the QR codes or go to github.com.com or WasmCloud.com and you can join in. At the last KubeCon, a bank came and did this awesome failover between AWS and GCP. It's a 20 minute talk. If you're interested in seeing this work, watch them tell the WasmCloud story. They're on fire with it. Just yesterday, Adobe spoke at Cloud Native WebAssembly Day and they did this awesome demo for background removal where they are able to take microservices they were running in a cloud provider and run them in a customer's browser. And why that's powerful is it's not only good, it's the same algorithm, it's not only faster, you don't need to upload the picture to a cloud in back, it's 40 milliseconds versus 400, but it's also cheaper because they're no longer paying for the compute because it crossed that threshold. This is a new paradigm, but remember that moment when you had to wrap your brain around containers? You're ready to wrap your brain around WebAssembly because it's already here and you're already using it today whether you want to or not. And then I already mentioned the BMW one. So I'll go and pause here and if we have a moment for a couple of questions, Mike in the front. Hello. Yeah, thanks, Liam. This was really informative. I mean, at least for me, I knew about Wasm Cloud in parts, but this actually gave the bigger picture. So let's thank speaker. Thank you. One last note, if you'd like to get some hands-on experience with either WebAssembly or Wasm Cloud, we've launched a new playground at labs.cosmonic.com where you can do real-time interactive tutorials. I'll be hanging out all day. I'd love to take any questions you have up there. Thank you so much for your time.