 All right, everyone. Hello. Welcome to wildly distributed programming wasm in the future of distributed computing. My name is Brooks Townsend. I'm a lead software engineer at Cosmonic. And I've also been a maintainer for the open source project wasm cloud for the past two ish years now. Love programming and elixir rust and web assembly, which puts me in a really interesting than diagram of programmers and serial open source contributor. And of course a demo enthusiast always going to do a live demo when I when I talk at a conference. So lightning talk, I'll try to be quick. We're going to start with why wasm cloud and kind of a what is wasm cloud. If you haven't heard of it before, we're going to do my young, wild and free demo and then talk about distributed computing. So when we look at the modern computing environment, we're talking about this trend of compute getting smaller and smaller and smaller. And you may have seen the PC cloud container evolution. We're abstracting more and more away from the individual developer for the benefit of the developers mental health and for the management of their applications. Right. So with Docker, we're abstracting away the kernel. We see web assembly is going a step above this abstracting with a host creating a truly portable piece of compute. Now this is great. And with wasm cloud, as we're looking at what we can do is we're taking advantage of web assembly. There's still an opportunity to abstract away the non functional requirements or the capabilities from applications. So to give you a concrete idea of this functional versus non functional, if you think about like a to do application, your functional requirement, you're going to create read update delete to do's right. That's the thing that use a developer you get down and you want to write that code. The non functional requirements are things like I need to receive HTTP requests on this port on this API and I need to route that into my receiver. And then I need to be able to store those to do is in some kind of persistent database. Like these are the things that you just copy and paste from project to project. You did it once, you know, you keep doing that enterprises, you know, big companies do this across thousands of different applications. And that makes it difficult both for maintenance and when vulnerabilities arise to do these kinds of patching. So this is where we see, you know, ourselves on the computing environment landscape. Now I'm going to go through quickly to describe wasm cloud and why it's perfect for this distributed use case and why it uses web assembly in five, excuse me, five different layers at the base level. We're using web assembly running web assembly. This is the code that you as a developer would write so we get all the benefits of portability denied by default security and scalability that the web assembly provides. The wasm cloud app runtime sits on top of that removes the boilerplate code and lets you securely access those non functional requirements that I'm taught that I was talking about in the last kind of section. Now the capabilities. These are both an abstraction that makes writing your application easier and something that you get to pick at runtime. So you're working on your local development environment. You write a web assembly application. You can interact with a key value store. That's just a hash map in memory. When you actually deploy that, of course, you're going to pick a real vendor. You're going to pick like AWS Dynamo DB or cloud mem store, but we don't want anything to change from your local development environment to production and the portability of web assembly where we're trying to like extend that to the app development process. Now these composable actors just again a fancy way of saying web assembly modules for wasm cloud implement that business logic. This is where you're writing your code. They're coded in terms of contracts and because they're so tiny. It's really easy to scale these out to different clouds, different edges. And what really comes to be a challenge with that is web assembly can really run in a ton of different places. But it doesn't really matter very much for composable applications when you're running them on the edge. If you can't connect to it, if you can't have your compute communicate with each other. And that's exactly what the lattice network does for wasm cloud. It's a mesh network enabled by NATs under the hood essentially lets your applications seamlessly talk to each other no matter where they're physically running. No concept of discovering nodes or running in a specific location. And you know I work for a company called Cosmonic Cosmonic. The platform is essentially a managed platform for web assembly applications went into developer preview about a month ago and you know obviously accepting everybody here to come sign up during cube con. But it's the painless experience to develop those server side web assembly apps easy to go cross platform across cloud. You'll get to see that today here in about a second. And the really cool thing is everything the Cosmonic platform is built on wasm cloud. So we're running the Cosmonic platform using wasm cloud and web assembly in production now. So when you go play around at the platform, it's all web assembly. And so that you know I would love to talk about more but actually Taylor Thomas my coworker and I were doing a full talk about it at the main conference on Wednesday. So you know if you're sticking around hope to see you there love to talk more about it. Now that's enough. I have about 10 minutes and I used about four of them to just talk and I really like to show you a demo. And what this demo is going to be is an application built with web assembly that is cross cloud cross region immediate fail over auto forming auto healing network with distributed persistence on different cloud providers. And so if you'd like to see it. There you go. Really? No, nothing. Oh maybe it's because I was in light mode. Hold on. So this is a real real to do list real distributed application. But of course it's really simple when you look at it. So what is the actual architecture of this application look like? I have no idea if this is going to be legible at all. That's not bad. So I'm running an HTTP server or a web assembly module that's accepting HTTP requests on Cosmonic and what this WebAssembly module is it's a it's like an API gateway for to do so it's receiving my API requests. I'm sending a message out on a message broker specifically using Nats but like you can swap that out for Kafka or for Red Panda which is kind of just Kafka anyways or whatever. And then I have another WebAssembly module that's storing those things in a key value store. Now I'm running this app actually on AWS, GCP, Azure and Oracle cloud. All of those things are seamlessly connected into one network. So to show you what this looks like I can go over to Cosmonic. I have five Wasm cloud hosts that are running. You can see like this is the Oracle one. This is the Azure one. They're on a variety of different architectures, operating systems and regions and clouds which is awesome because I wrote this whole app on my local Macbook. And obviously I'm not compiling and deploying to Mac but I never had to worry about any of that when I was writing my application. I deploy it on my local and it works all the same when I deploy to the cloud. And when you look at what this actual application looks like I've got my HTTP server that's getting those requests and forwarding them to the to-do WebAssembly module that's sending out a message to the distributed key value WebAssembly module. And that's storing that in a Redis backed data store but each individual one on each different cloud is configured to talk to on AWS, it's ElastiCache, on Azure, it's cloud mem store, whatever, on GCP, it's cloud memory store. So I'm not just like distributed storing this in one cloud like across a few different regions. I'm actually storing it in four different clouds in four different databases. And is this the architecture that you want for your production app? No, no, you probably don't want this, right? It is a ridiculous demo on purpose. But when you hear the tagline, like that's something that someone would talk about for a cloud native application today, you know, the cross cloud, distributed persistence, like immediate failover. I can actually come in to the Cosmonic dashboard and I can pick something like, sorry, I'll pick on you Oracle cloud. I can get rid of that entire piece of infrastructure and everything will still work all the same because it's persisted across all those different clouds. Now, why would I do this? Why would I over engineer the heck out of something that can just be a to-do application? And it's for two reasons. One, to show that the future of applications is distributed both because it's motivated by the edge and it's creating the edge. But people have figured out like running a container on a cloud host pretty well. Like if you just need to do that, you're pretty golden. But the edge capabilities and what we're seeing with people making applications today, people are trying to get the fastest response times running it as close to the user as possible. People are trying to get the lowest cost. So not running this massive cluster, running things as close to the data as possible to to save on network costs. And the reason why this is a perfect use case for WebAssembly is because WebAssembly brings that portability and security wherever you go. You write your application when you develop on your laptop, great. But your enterprise, you know, when you're when you're creating this app for your company, you may think, oh, I'm just going to run this on one cloud and it's going to be great. And then you come up with a new requirement like, oh, I need to actually deploy to three different regions. Like, do you have to go back and re engineer your whole app to add load balancing and add failover? You probably do. And that's a huge pain that some of a framework like wasm cloud that's built for distributed application brings to you. Additionally, the management of this application is greatly reduced with the capabilities being abstracted away. As soon as there's a vulnerability in, you know, ultimately, I'm not writing the Redis client library to reach out to a Redis compatible database. Sorry, there's nothing over there. You know, someone else is writing and I'm bringing it in from open source. And if there's something that I need to patch there with wasm cloud, I'm not recompiling and redeploying my entire app. I simply update to the new version of the Redis key value provider and then deploy that instead nothing actually changes within my application, which is huge for just me, maybe about the same amount of work for, you know, even Cosmonica small company where we have nine different developers and we're scaling across like we have a couple different applications. It removes the management from all of those things. And so really at the end of the day, WebAssembly is perfect for this type of distributed computing because it brings that portability and security and connecting it all to the edge is the challenge that we're trying to tackle. Now I have a couple, couple references. Please feel free to join our Slack. Everything that you saw today, even if it was through the lens of the Cosmonic product is empowered by the open source, all open core company. All of this code is open source the under my GitHub org. They are wildly distributed wasm. Probably need to push up a couple of scripts that I like hacked up, but it's all it's all there. And if you're interested in some more things that we're doing around this conference for for Cosmonic and wasm cloud. Dang it. What happened to my thing? All right, whatever. That's it. Thank you, Brooks. We've got a couple minutes before the next session. Any questions for Brooks? Hey, how's it going? So when you're able to ship code across clouds like that, are you able to make use of like component model like reusable components at all? Yeah, this is a great question. So the kind of capabilities model that we are chasing with wasm cloud. This is actually something we've been working with since 2019. So something that's been around for like pretty long before the component model. However, looking at what components and what world files are bringing, this is actually a perfect place for this is exactly where wasm cloud is going. And though it doesn't have support for the component model today, this is exactly our plan, right? The transition from using capabilities and using wasm instead of that is exactly where we're planning on. Any other questions? All right. Thank you, Brooks.