 All right. Hi, everyone. My name is Kate Goldenring. I'm a senior software engineer at Fermion, where we build Spin, the open source developer tool for WebAssembly applications, and Fermion Cloud, a platform for hosting those applications. And in particular, we're both really excited to be up here together today. We were both at the first KubeCon wasm day three years ago, and it is really impressive to see how much this community has grown. This room is at least twice the size already. And that just speaks to how this word, WebAssembly, which was originally really attached to that web part, has really evolved to be a very pervasive technology spanning to all different areas of tech. So to kick off, I want to kind of zoom out in that technical space and talk about what does it mean to build good software. And I think when you talk about that, your first response could be build something that does what it's supposed to do. That's a good thing to do when you're building software. But if you want to go above and beyond that, if you're building good software, it should be isolated. Your software shouldn't be able to affect other applications on the same system. It should be mitigatable. So if something does go wrong, ideally you can mitigate it and fix it as fast as possible. And finally, it should be efficient. It should only use the resources it needs and be able to use whatever resources it's using very efficiently. So all this comes together in that good software is software that you can wrap up and pass off to someone else and walk away and feel like you're really giving a gift to someone. And all that comes together to this one word where the gift of good software is that it's maintainable. I think good software can start with wasm. So I want you to pull out your wasm bingo cards because you're going to hear a lot of these terms probably throughout the day. And the first one is that wasm is polyglot. It's a compilation target that many high-level languages can target. It's very small and has a tiny binary footprint that makes it really great for downloading it in a lot of different places. It even supports streaming compilation. It's portable, so it can run across different operating systems and architectures. Basically, if there's a WebAssembly runtime on it, you can run wasm there. It's also isolated. It's designed to be sandboxable. And it has an incredibly fast start-up time, making platforms like the ones that we work on a really ideal place so that we can start wasm super fast. So it's really great for serverless workloads. And perhaps my favorite because I'm also the wasm co-chair is that it's an open standard. It's been developed within the W3C's community group. And through those open standards, we're able to build something that is cross-vendor and can really do a lot of amazing things. But there's some other terms that we don't often talk about in terms of wasm and WebAssembly components. And that it's mitigatable. It's maintainable. And also, if you care, the combination of all these make it for a really great target for green computing. So a wasm module is really, as I said before, a compilation target. So I can compile code using Rust or Go or C++ or JavaScript and many, many, many more to compile to this portable target. It has all the properties that I mentioned before. But there's this new up-and-coming evolution called WebAssembly components. And so with a WebAssembly component, it wraps a wasm module or multiple wasm modules and makes it so that I can actually compose now multiple components together. And the way that I do that is through interfaces. And these interfaces are with exports on one side, so saying the things that I expose on my component and through imports on the other side, saying the things that I need to be able to run. And so I can compose component A and component B together, but it's even cooler than that because it also is language interoperable. So if I compile a component with Rust and another one with Go, I can have these two communicate with each other over my exports and imports. But additionally, once I've done this composition, something else is really interesting about this technology in that it enables fine-grained sandboxing. This composition is through a shared-nothing linking so that my linear memory of each one of my core wasm modules and also the globals and maybe even the functions that are not exposed over my exports or imports are now isolated. And that allows us to really build software in a new way that we haven't really been able to do before. And so I think that when you think about where we are right now, we're building this. It's getting pretty close, and we're going to show some live demos of it actually working. But going back a step of where's our current state of software today, there was a recent report from Sysdig in 2023 this year from the Cloud Native Security and Usage Report. And they said that 87% of container images running in production have a critical or high severe vulnerability. And that number is like really high and kind of crazy. But if you keep reading in the report, it says that only 15% of those high and critical vulnerabilities are actually in use at runtime. So if you think about that, it means that basically our artifacts are including a lot of code that we're not actually even using at runtime. And that kind of speaks to the way that we have to build our apps today. Most of our app logic that is inside our app code is not our own. It's open source software usually. But what that means is that effectively we're pulling in a lot of stuff and it's really complicated. And so when you work in an environment that is perhaps regulated, there are also all kinds of new legislation that's coming down the pipe. There's a ton that already exists that have real teeth to make sure that we're writing good, secure software. But the landscape is complex and it varies across regions. And so when you look at a diagram like this, I realize it's overwhelming. This is what my CEO Liam shows every once in a while when he's talking about the flow through regulatory software lifecycle development. And to me, it kind of looks like a toilet bowl. And so my instinct is like, I want to flush it away. I don't want this to be the problem that we all have to deal with. And if you think about it, when you have an environment like this, you have a target, you have all these regulations, then the only security policy that's sort of sane is to say, okay, well, we can't have any high or critical CVEs. It doesn't matter if they aren't actually impacting us, or that we're not, you know, executing that vulnerable code, we just have to get rid of it. And so what we end up doing is rebuilding and recompiling all of our code every month, and every developer in this room knows what that's like, we all have to pin to bot or other techniques to be able to solve this. But I want to propose that there's a different way that we can do this. And I believe it's with a componentized ecosystem. And so I think that also can be summarized as can I just focus on my business logic and put all of those dependencies that could have vulnerabilities in their own components, and then have an application that's composable so that I can snap in all those different dependencies, and when something goes wrong. And so an example application that we want to walk through throughout this talk, to kind of talk about components is say you have some application that has some middleware, you want to do authentication. Well, normally, your authentication part of your application would be built into the same application. But instead, what if your authentication middleware could be its own isolated components so that the secrets it needs is isolated in its component, and that you truly never enter your business logic unless you're authenticated. So this diagram kind of displays that we have two components, like I mentioned that middleware component, and then your business logic component. And here's where we talk about those interfaces again, those imports and exports that the component model brings about. And in particular, we're talking about the incoming handler import here. So our authentication middleware component is going to say that it imports an income or it exports an incoming handler. So saying you can pass me an incoming handler from the WebAssembly host, and then you'll see that it also imports one. So then it can pass that same HTTP request to your business logic if authentication succeeds. And so another thing to notice about this diagram is you'll see wazzy CLI environment. So the second part of that is what I was saying, and where ideally you could expose only your secrets from the host, only a few environment variables, and then that middleware component can import those, but the business logic component will not be able to see those. So we have multiple levels of isolation here. And so we're going to go ahead and demo this using wasm time, which is one of the most popular run times in the space and is maintained by the bytecode alliance. And before we kind of talk through and this demo that we're going to be showing is available here on GitHub. And I want to make a huge shout out to Michelle Danani and Brian Harduck, who work with me at Fermion, who put this together. And the demo consists of those two components that were in our diagram. You have your authentication middleware, which is a GitHub OAuth application, so it runs through the normal GitHub OAuth protocol there. And then you have your business logic, which we're just calling your example application. And all this business logic is, is it simply returns an HTTP response with a body that says, my business logic executed. So the idea here is that we only see that line if we pass an authenticated properly our application. So we have this cloned here locally. And first I'm just going to run it and then we'll talk through what commands we used using some open source tooling. Okay, so you can see here wasm time is now serving up our component. We'll talk through how we put that together in a little bit and that it's served up on localhost 3000. So let me, before we go, let's just make sure our cookies are cleared here. Okay, we shouldn't have any cookies. Okay, so we're going to log in, log in to GitHub. And now we're going to have Bailey here now. Okay, we're authenticating with our GitHub OAuth. One more. This is really layered. We're layered. And our business logic executed. So well, thank you. So what just happened there? If we look through the series of commands there, first we built our first component using cargo component. So cargo component is an upstream tool, also maintained by the bytecode alliance that helps you build components in Rust. And what we did here, which we don't recommend, is we compiled in those environment variables. So while that diagram showed importing them and having them exposed via the runtime, we aren't doing that in this demo just because that's not universally supported yet, but it's coming very soon. And we also specified the callback URL to our application once we've authenticated, which has also been configured in our GitHub OAuth app. So now after that first cargo component build, we have outputted our GitHub OAuth.wasm file. That was our first component. Then we do a second cargo component build, and that's of our business logic. So that was our example app. And after that, we have an example.wasm. And so finally, we compose them using wasm tools, another upstream open source tool for WebAssembly component manipulation. And we basically are saying take that GitHub OAuth application and line up its exports with the imports and exports of the example application, and then output that resolved finalized component, which is service.wasm. And then our final step there was what you see in the terminal down here. Let's serve it. And what wasm time serve, which is a new sub command in the latest release of 14.0 of wasm time, basically says, I'll forward HDB requests to this component. So let's go back. That all worked. But we also want to talk about that other part of good software, which is mitigatable software is great. So first, how can we find an equation for what mitigation looks like? So mitigation can be also interpreted as the mean time to resolve a vulnerability. So it's the time to detect, plus the time to fix, and the time to release. So time to detect that varies, depends on like the reporting of your space. But the time to fix and the time to release, we think that WebAssembly drastically reduces. So let's walk through some scenarios and see a couple things go wrong. First one, say you have a vulnerability in that authentication middleware component. Well, one thing to notice about this component is that it is ubiquitous. I could plug this authentication middleware component into any application. It's not specific to my business logic. Rather, you could imagine any componentized application using this. So under that definition, it can kind of be seen as a library that would be maintained upstream. And actually, there is a registry within the component space that's under development called WARC, where you could imagine this would be an upstream component that would live there. So let's say there's a vulnerability in the authentication middleware. Well, the upstream maintainer would likely patch it. And all you need to do is pull down that .wasm file and relink it. So I didn't have to do any rebuilds. I just had to do a relink. And I actually didn't even need to modify my dependency chain to fit this new library, or new patched library. So let's take another scenario. Let's say it's my fault. Something in my business logic went wrong. So, yeah, I do need to actually fix that. So I'm going to rebuild that component. But the authentication middleware, or if you expand this to a bigger scenario, all the other libraries that are componentized that you're bringing in, you don't need to rebuild or re-resolve how they interact with each other because of these tightly typed interfaces. And you can imagine your business logic actually might be broken up into several components too. Maybe one team and your company manages some components, others, and others, and they're all composed together. So your section of the business logic, having a vulnerability, isn't going to result in anyone else having to do more work. So we rebuild that, we relink it, and re-release it. And that is a shorter loop for some problem that I caused. And let's talk about a third scenario. So both of us have platform and cloud providers for running WebAssembly and hosting your WebAssembly applications. So the third scenario is that you don't have to do anything, your platform provider fixes the problem. And the only reason that's enabled within the WebAssembly and component model ecosystem is because there's a concept of guest components and host components. So host component can be thought of as something that exists alongside with the runtime, and oftentimes these have clients in them. So it's maybe it's a key value store client, so maybe a Redis client. And you can imagine that our business logic, maybe it uses a cache, so it writes some keys and values to that key value store. Well that's actually going to be, the client for that is actually going to live with the WebAssembly runtime. So imagine if there was a vulnerability there, your platform provider could patch that and fix that for you, and you didn't need to worry about rebuilding that client into your code, rather the host component handles it. And that once again is an ubiquitous host component. So there's also a world where that could be maintained upstream, and your cloud provider actually only needs to pull down the patched version of that too. So we saw multiple scenarios of where, first of all, we built a componentized application, and we saw how we were able to mitigate that any security vulnerabilities that would happen with it, and we did it in a way that increased developer productivity. But we also did it in a way that increased environmental efficiency of the way we're building our applications. Yeah, so consider this in the in the in the scenarios that Kate just walked through. We never really ended up rebuilding an entire application, we were just rebuilding that one piece of the problem that changed. But conventionally, in the way that we build software today, we have really matrices of matrices. We've got like say multiple go versions, maybe multiple operating systems, and maybe even different platform architectures, right? And so I pulled these two. One was from a GoLang library that I used to use, and then another one was just straight out of the Docker documentation. So this is like a, you know, I would say fairly common pattern that you see across most of our builds is that we are building against operating system architecture, language versions, maybe even different versions of frameworks, and then we're also doing that exact same loop for testing. And then when we package, we're usually packaging for that different target operating system and architecture. And so you can imagine every single change that comes down the pipe, say every single time we're churning our dependencies, we're rebuilding the entire world. And so that is pretty costly. But in a componentized ecosystem, when we look at this, we can say that we would only build once because we're building one portable target architecture. When we test, we only need to test on our runtime that we're running on once. And when we package, well actually we're already packaged. That's what's kind of cool is that components are packages. So I don't need to like run a bunch of numbers for you to say, this could really change the way that we write software in a really amazing way that I think developers genuinely want and need. So we've got more. So let's bring it back to that demo. So Bailey just mentioned how Web Assembly applications are incredibly portable and we're using that definition of cross architecture and cross operating system. But we want to bring a new definition there. One that means there's no vendor lock in. This Web Assembly component can run across clouds. And the reason why that's possible is because we have all these interfaces like the HTTP interface we've been talking about that are community defined. And if as long as your cloud supports that interface and another cloud supports that interface, your Web Assembly module or Web Assembly component can run from one and also on the other. So we demoed earlier using local upstream tooling to run this right here on this laptop. But now we're going to demo running it on Fermion Cloud, the cloud that I developed, and then we're going to run it on Cosmonic where Bailey develops that cloud to show that this same service.wasm is entirely portable. Okay, so while this is deploying you'll notice that in our Makefile this looks just like the commands we did earlier. The only reason we're rebuilding this is to embed different client secrets in a different callback URL. But in the future when we have that environment variable injection support we wouldn't need to do a rebuild at all. So now we've deployed our app to Fermion Cloud. So we can go ahead and try and see that lovely business logic string again. I'll take a moment for it to make sure it's fully deployed. And so what we used to build this application was spin. So that's a developer tool I mentioned earlier, which helps you get started quickly developing Web Assembly applications with a spin new. And then we could have run this locally with a spin up. And our last command of that cycle is a spin deploy to the cloud. And when you do a spin deploy you get your custom URL or you can use the custom domain as we did here. And then we're going to log in. So do our same loop. And we already had cached those credentials from Bailey's GitHub. So we're in. Okay, one more, one more. So right, we're just going to show that we can run it portably in multiple places. And as Kate said, we're rebuilding here because we haven't gotten the ubiquitous tooling. But if you're into that, please talk to me after I have lots of ideas, both in the by code alliance space and within wazzy, the working group. And so I'm rebuilding and launching here. Same thing. One difference is that I'm using the wasm cloud, which is a CNCF project. And I'm using the CLI for that to sign it. So now I've got a signed component. And then I ran a similar command to what Kate ran, but something that launches into my cloud. And so I've successfully launched it. And let's go over here. Oh, I remember. We want to make sure it shows up in an incognito window. So it's like, you know, look, no cash. And it should still have the GitHub token and we're in. This is logic. So I guess to recap what just happened there. We took the same service at wasm and run it locally and then across clouds. We filled out our whole wasm bingo card. We talked about how wasm is inherently isolated with its own linear memory. We talked about how it's mitigatable, walkthrough a few scenarios, how it's green, build once, and truly portable with multiple definitions of that word. And a lot of what you saw here, actually the majority of it is open source tooling that you can get involved in. So we hope this kind of ties a bow on the beginning of the day. And you see the gift that is WebAssembly. Yeah. And if you're excited about this future that we just painted here, please get involved. We both are contributors in the Bicut Alliance Foundation. There's also, if you're interested in the standard side of the house, the W3C wasm working group. Then also inside the CNCF, there's a wasm working group as well. So if you're focused more on like say, you know, hey, what would be my artifact definition of a component inside OCI, that would be your place. And then both of our projects are open source. SPIN is what Kate showed off and then wasm cloud is a CNCF project here. So I think there are several more talks too later. So please talk to us. We're going to be walking around and I think that it'll be really fun building the next future of applications. Thank you, everyone. I think everybody can see why this talk ended up voted right to the top of the day. Any questions for Kate or for Bailey? Great demos. Thanks very much. That was awesome. I've used wasm tools composed to take two different wasms and combine them together through that interface. What work is being done on kind of dynamic negotiation between components? That's a great question. So lots of different areas of work. Is Peter Hean here? Okay. Well, I'm going to give Peter Hean a shout out. He's been working on a linking language. And so instead of having that YAML file or the CLI interface, being able to define a linking language to be able to pose those components together, if we have that, it would be really easy for runtimes, say, on the fly to do this. Now, this linking is always going to be static. And that's really a great benefit also for a security posture in that. I'm able to statically analyze and say, what are you trying to do here? Are you trying to open up some sockets? Did I actually check that I set up firewall rules correctly, right? So giving the opportunity for the runtime to create a sandbox environment. So I would say linking language, extra work on shared everything linking is coming. I also want to shout out like Joel Dice would be another person to talk to here if you want to know more. So I think basically that dynamic at runtime linking is going to be something that you get out of the platform. So Kate's scenario three, what I really expect to see going forward is a lot of different WASM platform providers will just kind of automatically mitigate all of this stuff for you as a developer. We might, you might get an alert and be like, hey, we just fixed your stuff for you. Celebrate. But it would never be something that the developer would necessarily have to take an action. And that's how you get software that is just truly maintainable. I've got a question. Bill and Kate, when we think about all the big epics of tech we've had before, whether it was virtual machines, public cloud, Kubernetes or containers, there was always one artifact that everybody could collaborate around and build an ecosystem around. So my question for either of you is, is this WebAssembly's Docker moment? That was such a well-prompted question. I would say yes. I think we have a huge potential to have this new unit, which is components or WebAssembly that can pave the way for a new way of developing applications. So as Liam mentioned, we have VMs, which was kind of, you were able to isolate your application from another application, but they were still fairly monolithic. And then you had containers which created this microservice approach. And now we're at the WebAssembly era where we can really create these small, tiny, ideally maybe functions that can kick off in microseconds sometimes. So that creates this new paradigm of computing where you can have really reactive serverless applications and that's powered by a new form of compute, namely WebAssembly. And just like the previous epics, you have a new way that you have to build your applications in order to take advantage of this. Liam, I saw questions on this side of the house. Yeah. Who had a question over here? Coming down. So I've been working on building a culture of WebAssembly within our company. And in the, getting to that goal, I've built a few reference implementations, both in CLIs and different backends. And one of the things I've noticed is that in the WASM runtime, the applications default to UTC. It seems as if they don't have the certain integrations with the operating system as a native binary does. I was wondering if that was an issue y'all have come across and maybe work past or if it's a contribution opportunity? I would say all contributions, super welcome, as a default maintainer answer here. I think that WASM time itself definitely lends itself usually to being embedded in other pieces of software. So that might help explain why, you know, that's not a major area that's like filled out. But as we've recently changed our CLI, we've learned that there are actually a ton of WASM time CLI consumers. And so I think that type of change would be really, you know, welcome. I can point you to some of the WASM time maintainers while we're here and I'd be happy to connect to you. Thank you. I look forward to that. Other questions? Bruce, you look nervous. Sorry, I wasn't going to ask. Yeah, I was wondering what you talked about that aspect of sharing components where you can apply security or fixing run times vulnerabilities which need to be fixed with that component model which looked interesting. And what I was wondering, though, is in one aspect of that, if I understood it correctly, is that it's not going to break the application when you do that. And what my question, though, was EVVF, is there, can that be applied? I mean, what I see with that is that you can, it has these interesting hooks and you're able to apply certain tools and I was wondering if that would be applicable to WASM modules. Might if I take this one. Okay, so something we didn't show is that these interfaces are also versioned. So usually when you're worried about breaking an application it's because the API changed and it broke, right? And so when you tried to recompile it gives you some compiler error. And these interfaces are strongly typed. So you would know immediately whether or not they don't work. And the other thing is that it gives you this ultimate level of flexibility because that's your API surface layer. So say you're logic on the inside changes then whatever you expose over that interface doesn't necessarily have to be the internal API. That's your public-facing API. So the first thing I would say is if you're building something that's not going to be changing very often, that API layer, the client pieces that connect to it will frequently change and the protocols too. But that's not exposed to the user. So this is like a really nice way of consuming libraries. And the other side of your question was about EBPF. Yes. There is so much cool stuff happening in that space right now. Last WASM day I think we saw two different talks on it. At least one where folks have had to run WASM modules as part of EBPF because WASM is the last plugin model you'll ever need. And so with EBPF it's kind of hard to write code that it's in the kernel space. And so with WASM you're able to now enable programs to use it or write programs for the user space. So that's one key part of that. And then I would say that both of us like I can at least speak for Cosmonic. We use Silium as part of our work for the networking layer. And if you're into that the guys who wrote NetReap for that side of it are here as well, Dan in the back. So please talk to him if you like talking EBPF and Silium with their for your networking policies. So yeah, good questions. Yeah, that was Nandor at Cisco that did the talk at the last WASM that's on YouTube if you want to check that out. I was just going to follow up. I think one part of your question was is this going to break as we're rolling out the fix cloud ops to roll that out in a way that you would still be serving previously with your previous version of your runtime while you roll out your new updated runtime with the host component patched. We have time for one more question. All right everybody, please join me in thanking Kate and Bailey.