 Welcome, everyone, to this session. This is called Disrupting the Downtime Continuum. We'll go ahead and give ourselves a quick introduction here, so you know who we are. Yeah, so I'm Brooks Townsend, Lead Software Engineer at Cosmonic, and the open source project, Wasm Cloud. I'm a maintainer. I'm a serial open source contributor to all things, and I like to say my little trifecta of weird technologies is Elixir, Rust, and WebAssembly. And I'm Taylor Thomas. I'm the Director of Customer Engineering at Cosmonic. I'm a restation. So I've done a lot of rust for a long time now. And I'm also the co-creator of Cresslet and Bindle. If you've looked into the WebAssembly space at all, you've probably seen one of these two projects. I'm an open source maintainer in general. I'm an emeritus maintainer of Helm. I was one of the core maintainers there for a long time. And since we're at KubeCon, most of you at least probably know what Helm is. So there is some, at least, here's our background. We know a little bit about what we're talking about as we do this today. So let's go over what's the agenda going to look like? What are we going to talk about here? So first off, we're going to talk about what is WebAssembly? And I wanted to know, this is my favorite thing about being back in person. By raise of hand, how many people know what WebAssembly is? Okay, good. So that's a good chunk. That was more than I was expecting, which is great. So we're going to cover a little bit about what WebAssembly is. And then also explain what's this whole Wasm Cloud and Cosmonic? Like why are we wearing these Cosmonic shirts? Then we're going to do a bunch of demos. This is a very demo heavy session. And it's going to be live as long as we haven't angered the demo gods. We've done the proper sacrifices, cut our hand with a stick of RAM, dripped it on the altar of the computers. All that stuff. So it should all work. And then we'll also answer the question, what can we do right now and how do you get involved? So let's go straight into it. Well, what's WebAssembly? We like to say it's neither Web nor Assembly. Which is kind of funny given its name. Now it was primarily used first on the web. And if you look at it, these are the characteristics that make it very good for the web. It is an open W3C standard. It's very safe and secure. It's a completely default, like nothing's allowed. It's in a sandbox because you're in a browser, right? And the browser is the Wild West. So everything needs to be sandboxed. It has capability driven permissions. Capability driven permissions is like what you have on your phone when you go like, oh, would you allow this app to access your microphone and your notifications and all those things? It's very efficient and fast, which is important because the small sizes you are able to download it quickly over an internet connection and use it. It's also polyglot. So you're able to use multiple languages to compile to WebAssembly. It's just a compilation target. And it's very portable. It runs in all major browsers. Imagine if someone said, oh, sorry, this only runs on Linux. That wouldn't go over very well in a browser world. Now those things right there are actually the exact same kind of things we wanna see in the cloud. We like having open standards. Most of the world is transitioned to using open standards for these things. We want something that is completely secure and locked down. That's why we started using things in containers. It's very efficient and fast. That's also important. We wanna be able to pack these things tighter and have good utilization. Any language that can compile to WebAssembly, same thing, that's a benefit. And once again, portable. It truly runs everywhere, not just on Linux. So let's cover a little bit about the gaps here. There are some gaps to just be aware of. One of the things that language support for WebAssembly outside of the browser is still limited. It's quickly growing, but it's still limited. And so you have to know that that is one of the things that's happening right now in the industry. Networking is generally rudimentary. You're non-existent. They're just starting to add socket support. It's really great that it's there, but networking support is very limited. So you have to find ways around that. And you still have to compile a lot of your dependencies into a final binary, the final WebAssembly module. And ultimately everything is still numbers in, numbers out. You get a vector of bytes and you have to return a vector of bytes. There's no types. There's work being done on that, but right now you're pretty much just raw bytes when you work with it. So that's where we are with WebAssembly. Now let's talk about where we've been and where we're going with this. And now I promise, all this is important to understand why what we're gonna show you is important. So first off we started with what we jokingly called the PC time, right? Like everyone had their own towers or you had blades or one, two, three units that you had in a rack. And you owned that entire thing. You owned the operating system you installed on it, the libraries for that operating system, and then the libraries for your applications and an application that you'd run on top. Then we moved on to clouds. We're like, hey, can we like VM this? So we can put in a VM, everything's running. And we abstracted away the hardware, but we still were installing full stacks of libraries and applications on top. Then we came into containers and Kubernetes. And containers gave us this real nice way to keep everything all together and secure and reusable, but you're still talking about everything being coupled together. So we're talking like all these non-functional requirements that happen. The example I'm gonna point out here because it's the most recent and fresh is the log4j vulnerability that happened. We have all written vulnerabilities. I have written security vulnerabilities. We've all written bugs that turn into bad, like SEV1 incidents and other things that happen. So it's not a criticism of that, but like those happen in software. And when that happened, everyone we've talked to, there are people who had to rebuild and redeploy tens of thousands of containers because you're bringing along 95% of your code being just non-functional requirements, things you don't care about. And anytime an upgrade happens, that has to happen. So that's what happened with containers. Everything's still coupled. And even WebAssembly, to an extent, is still you have to couple in a library when you run your final artifact, even with some of the new proposals that are coming out around the components model. So all of those things, it's still better because now it's completely separate. It can run on different hosts, but you still have this non-functional requirements that are very important and still bound to that thing that you compile. The last one over here is WasmCloud. Where we've taken it, we've turned it into a platform and we've abstracted away the libraries that you need and are called capabilities. You now code against a contract and we'll talk a little bit more about that as we go into what WasmCloud is. Right, so you've started by hearing about WebAssembly about some of the huge advantages that it gives and then some of the limitations of where the ecosystem is now. And this is where at the WebAssembly host runtime layer of WasmCloud, we're taking advantage of all the portability, the security, how it can run anywhere and how adding additional language support is something that we can kind of build into the framework over time. We're not just locked into one single thing. But where the disadvantages is, where we're not fully there yet is where the WasmCloud application runtime comes in. This is where you get your removed boilerplate code, the access to capabilities outside of the WebAssembly sandbox and the WasmCloud runtime facilitates the passing of bytes back and forth. So when you're writing your app with WasmCloud, you get to write it against the contract. You say, hey, I wanna use the key value capability and from there you can write your full business application. And these capabilities, we keep talking about them. We keep talking about non-functional requirements. This is the part that you need to make your app run but that you don't write. Either you copy and paste it from a previous project so you're setting up the HTTP server in the right way or you're bringing in open source libraries which is great but you're not reading all of the code from your open source libraries. You're not making sure that everything is fine and this makes up up to 95% of the application code that you end up deploying. With this capabilities model, you choose it at runtime, you can hot upgrade to a new version, you can patch vulnerabilities and you write your app in terms of a common contract. You don't deal with it when you design your application. Now the actors, what we call Wasm Cloud Actors, these are the actual WebAssembly modules. This is what you write your business logic in, what we like to say, write the right code. You're writing just the code that you want in order to make your business logic work. You're not copying and pasting a bunch of code or re-implementing open source libraries, especially not compiling it into your application logic. These are stateless reactive modules and because they're WebAssembly, you get all the advantages as a developer of being able to deploy anywhere after you've built a WebAssembly binary. And the last step, what really makes Wasm Cloud work is a distributed application runtime, is the lattice network. This is running with NATs under the hood. They have a project booth over at the project pavilion, go see them, they're great. But what this does is it represents the resources in a Wasm Cloud application at a flattened layer. Everything, no matter where it's running in the cloud, on the edge, on my laptop here in the conference, it's all treated the exact same. And that really makes it a lot simpler once it comes to actually moving your app from Dev to Prod or deploying it in a different cloud than you currently support. Now this brings us to the question, well, how does Cosmonic fit into this? So the whole idea of what we're doing with Cosmonic is we're trying to make it a painless experience to develop these server-side WebAssembly applications and eventually, this is where I get to the point, if I'm being 100% blunt here, someone has to manage it eventually, right? Like, no matter what you're running, Kubernetes, Wasm Cloud, someone has to run it, we run it. And part of that is making it easy for cross-platform cloud device development. And honestly, this last point's the most important. We're not here to pitch the product, we're here to point out that this is all actually running on Wasm Cloud. So everything we've built for the product is actually running in WebAssembly as these actors on the system to make everything work. And you'll see parts of it today, we'll use it because it has a beautiful way of representing the application, but we're just showing it to be able to see the pretty side of it. But we're actually building a real application with this. This isn't just some experimental thing, you can build a real thing with it. So we're gonna start going into that now with our first demo. All right, enough with the slides for now, we can actually get started with the fun stuff. Let me get out of this. Okay, so I wanna paint the stage for you, right? You come into work on a Monday and your boss or your PM comes to you and they say we have this really important business application to code up. We need a web app that can display a random comic from XKCD. Do you think you can get that done by the end of the week? And you say, yeah, I think I can do that. This is everyone's Monday, right? This is what you guys are doing. So when we sit down, we start writing this application when we're thinking about how we're gonna design it, right? We need a web app. So it needs to be a web server respond with an HTTP response and then show something in the browser, right? We may need to generate a random number to get a random comic. And then we need to fetch our comic, whether we use like a library or whether we just curl it or whatever. So I'm gonna start with the finished product because that's the most fun part. You got this little app and if you refresh, you know, you get just random XKCD comics. It's completely random, so you can get really anything. And this is it, right? You did it. Thankfully, you wrote this with Wasm Cloud, so they asked if you could finish it by the end of the week and you finished in the first 15 minutes on a Monday so you had a pretty chill week. So this is the finished app. This is our business logic. Kind of introduce the stage. Let's look at what the code looks like. So we can actually zoom in a little bit more here. This is gonna be our XKCD actor. This is an actor and a capability pair. The actor is where you're writing, again, your business logic. And even if you haven't seen Rust before, you'll be able to grok this pretty well. We found out that one of the newer XKCD comics was the like number 2600, so that's the max we're gonna generate. And in order to make this app, it's very simple. We have a trait called HTTP server and the contract that comes with this trait is a single function, handle request. Receives an HTTP request, returns an HTTP response. Very common level abstraction of an HTTP server. Now the business logic, how we actually implement this. First thing, generate a random number. We use the number generator capability since WebAssembly actually can't use random like crypto stuff because it's on the system. So we generate a random number. And then we actually found this great open source capability provider that implements a function that you can get a comic by a number. So great, we'll call out get comic function and then return it as an HTTP response. That's it. Three lines of code, minus little nice formatting in order to do that business app. You get right down to writing the logic right there. Now that's all fine and good. It works great. You're running this in production. Your management team is really happy. Now let's take a look at the provider, the open source library or the capability provider that actually implements that get comic function. You'll see a lot of similar things here. Get comic handler. We take in a number. We request that URL. We make sure that it was successful. And then return that as a little byte vector of an HTML page. That's how we're actually implementing this on the provider side. So someday, you get a little notification that your provider or the open source library has updated. You're like, great, I'll pull in the new version. It's going to be even more secure. And you go to deploy the next version of this provider. So this is actually the WasmCloud dashboard. We haven't hit it yet. So I'll just explain it really quick. We have up in the top left, our XKCD actor is running on the right. We have our HTTP server provider. That's what's actually getting the HTTP requests and forwarding it off to the actor. And then in just a moment, we'll have our newly deployed, updated version of our XKCD provider. Now, all of the things that make your business logic and these requirements talk is configured at runtime. So even though I just killed the provider and I brought a new one back, we can go back to the XKCD comic and see a SEB1. We can see our new updated version, while it still works, has a very critical vulnerability in it. So this is pretty unfortunate. I didn't mean for this to happen during the talk. So we can actually look. You can go back as the deployer of this. You can go back and see that this SEB1 is recognized everywhere. The maintainers caught on to it or released a patch version. That's great. But instead of having to go and recompile our entire app, the part where we wrote the business logic, recompile, run it through our testing platform, make sure that nothing broke. Maybe this was a minor version bump, because they already included something else. We can just go straight back to the URL and load up another XKCD comic. This one's nice and wholesome. I'm not going to tempt fate anymore, because I've looked at a lot of XKCD comics. There's some that you don't want to show up. But that covers the first part of our talk. We want to talk about downtime-free migration, patching, and what was the last one? Failover, fan failover. So that was the first part of our demos. So hopefully, that speaks to how easy it is when you can separate the non-functional requirements into a separate unit that you can deploy. You don't have to spend a ton of time redeploying your app. And for a log4j type of vulnerability, that's the one place that it updates in an enterprise. It's not every single app that depends on that common library needs to update. So the next demo that we want to go into, you just want to show a little bit of a diagram to show what's going on. So one of the common things that you will see as a microservice example, especially if you work at Big Corporation, is this classic Spring Boot Pet Clinic example. You have an API that goes out, an API gateway that forwards requests to specific services that respond to that. There's a visit service, a vet service, a customer service. And all of these things are in there. But you'll also notice that this diagram, it's very enterprise-y looking. I did not make it to look enterprise-y looking. This is literally from the Spring Boot examples. And look at all the stuff that goes on around it. You have to have the Spring Cloud config server, the service discovery elements, the login things, all these different requirements. And then the HTTP stuff and to talk between the different services, all of that extra baggage. And you have to have that in your actual code. So what this actually looks like if we do it in Wasm Cloud, is something a lot cleaner. So you'll see that you have the user that's on top that's connecting to an HTTP server. It can literally be any type of HTTP server because it's just a contract. And that has the clinic API. It returns UI assets through there. And it also forwards requests on, which then talk to a SQL database contract. It doesn't even know what SQL database it's talking to. In this case, we're talking to Postgres. And all of these things are just done and configured at runtime. And it's a lot more simple. There's no other logging servers that are set up. There's no service discovery. You're just able to connect between these different things. And so we're going to actually show you what this looks like and what you can do with it. Yep. So demo time around 2. So we walked through the architecture of the pet clinic. Let's take a look at the pet clinic. So we've got this. I've got this running on my local little dummy user. I'm running in dev. So I just have some test data in here. We could add in a pet if we wanted to. But really, we can look at what kind of vets we have, what kind of pet types they could specialize in. Really, from the business logic perspective, a simple application. Something that you could probably drum up in about a day or two when you think about just the relationship between owners and vets and all of that. Now to show you what this looks like in terms of Wasm Cloud components, I'm going to show you that through the Cosmonic dashboard. And like Taylor mentioned earlier, everything that you're going to see today through Cosmonic, you can do with open source Wasm Cloud. And we encourage you to try it out. Just a little bit easier to visualize here. So there's two main views we're going to take a look at in Cosmonic. The first one is the infrastructure view. This is where you can see all of your different infrastructure, your virtual hosts, no matter where they are on a flattened canvas. So taking a look here, we actually have our first host is the Cosmonic application, running all the actors and capability providers that power what we're going to do in the demo today. We have a Wasm Cloud host running in Azure. That's an x86 processor. It's on Linux, and it's in South Central US. I think that's Texas. We have our Pecmonic application. This one is running all on my local machine. It's got the API, visits, vets, and customers, our HTTP server, all of that. And what we want to do, especially with these other hosts, this Azure host, and on the right, this AWS host that's an ARM processor running in California, we want to take this application that's just running on our local, and let's deploy it to prod. Let's push it up to the cloud, take these WebAssembly modules there. Now the second view, which is where we're going to be doing some more interaction, is the logic view. This is where you can see, again, flatten topology view of all of your application components. So you can see our API is right up here. And then if we come down past some of the Cosmonic components, we can also see visits, vets, and customers, all linked together to our Postgres capability provider, and then HTTP server for the API. So again, everything running on my local, not super fun for a distributed application framework. So we'll just go ahead, terminate all of the actors from the lattice here from the WasmCloud network. And we'll take them, instead of running my laptop, let's put them in the cloud. So our clinic API, the API gateway, we can find a WasmCloud host that's running in AWS to host that actor. And any host can respond to this, but all that we really care about from this perspective is that it runs in AWS. That's our requirement. Let's run it in the cloud. Also, it did just start that fast. That wasn't magic. Yep, it is actually running in AWS. And the second thing, our customers actor, we can find a host there. Go ahead and start up our customers actor in Azure. Let's see what's next. Our vets actor, say, instead of cloud specifically, we'll have a region requirement. So we can run this in the US West 1 region, which we know is our California host that's running in AWS. And then also, last but not least, we can run our visit service in the region South Central US. So great. We've taken all of our application components, the same WebAssembly modules, and we're running them from an M1, an ARM MacBook Pro, put them up in a cloud provider on an x86 Linux, ARM Linux, all the exact same WebAssembly module from an OCI registry. If we check our infrastructure view, we can see visits and customers are on Azure. API and vets are on AWS. And if we hit our little refresh here, look at that. We still get the same data. And that's because all of the configuration that we set up at runtime is automatically reestablished when we push our business logic up to the cloud. So it has no bearing on the actual location. We just immediately redirect the request over to the cloud host. So that's the first part of our second part of migration. So we moved our resources to the cloud. But we're still using my dummy test database. So next, what we may want to do is migrate to using our prod database. And we don't want that to just be a local Docker image or implementation of Postgres. We might want that to be RDS or an Azure Cosmos database. So we can come to the logic view again. We can take a look at this link between customers in Postgres, and then we can throw it away. We can redraw this and then tell the runtime whenever this customer's actor makes a request to a SQL database, we're instead going to access this one. And once we draw that link again, we hit refresh on the WasmCloud pet clinic. And look at that, some real data, some Cosmonic employees. If we click in here to Taylor, we can see his beautiful dog checks, which I've seen a ton of pictures of this weekend. And my dog Archie, all coming from our Azure Cosmos database. So when you're in production, you wouldn't live swap from databases without a perfect strategy. But this is a show that you can move from dev to production in a completely seamless way that's configured at runtime. Our actors, our pet clinic actors, didn't have to change or do anything to make this happen. Yeah, it's kind of, we like to call this the knob. You can turn the knob from monolith to distributed. We didn't have to do anything else except move it around. And we're adding more utilities to the actual open source WasmCloud tooling that will allow you to just automatically do this and automatically redistribute based on certain characteristics. Right. So last part of our talk is, before a little bit more slides, is failover. So we have these actors running in different clouds, but they're kind of spread out across clouds. It's not really a resilient application. There's no replication. There's no different. There's no scaling in different clouds. So let's go ahead and set up a little bit more of a resilient architecture. So we have visits and customers running in Azure right now. Let's go ahead and take some instances of both of those and run it in AWS. So we'll start an instance of visits and an instance of customers in AWS. Great. So we come down. We take a look at our application components. You can see we have two replicas of visits, two replicas of customers. From this view, it doesn't matter where they're actually running, we just know that we have two of them, because it's all going to route there the same. And we can actually come back to our host. We can look at our Azure host, and we can just terminate it entirely. Get rid of it. Those actors are gone. We come back to our pet clinic. We hit refresh. We navigate around. Immediate live failover to the other cloud that we have set up. So using WasmCloud with this interconnected Lattice network, wherever the available compute is, is immediately where your request is going to be routed. And through some NATs and GS things, that also has a preference on location, choosing a closer location. But just to note, this is still hitting our Cosmos database. So if you trace this request that's happening right now, it's going from my laptop to AWS in California, previously to Azure or the other actor in Texas, but now all in California. And then over to New York, wherever the Azure East region is for our database, and then coming back. That's the request that you're watching our pet clinic resources coming back with. All right, so just to kind of nail this demo home or wrap up kind of what we did, this is the application diagram. What we started with when we decided, oh, let's write a pet clinic app. We'll sketch this out. And this is the architecture diagram that we ended up with, like what we were actually running in production. So we took all of our actors, we threw them off onto the AWS and to Azure, accessing a Cosmos database. And I know that as I'm pointing this out and trying to point it all out, like this is what I look like as I'm describing it, but it's just all to say that designing the application, the way that we wanted our business logic to be, didn't have to be concerned with, no matter how crazy the end architecture diagram looks like. So that leads us to this question. Well, how are you gonna use it, right? So let's talk about what can you do right now if you wanna try this out? The first thing is you can write a very basic service. These are generating data processing, image processing, those kind of things. They're standalone services in most cases or part of a pipeline. And you can try rewriting one of those. We've seen quite a bit of success of people trying that out and being able to at least give little examples. If you watched, if any of you were at the WASM video, you may have seen Colin's talk where he showed some of the things that Adobe liked this or just little tiny services that they could do. And then another one is just a small part of a service that you were planning on rewriting anyway. So we have this concept that we like to call the bridge to the future. We consider WASM to be the future, but we also know everybody is running things on Kubernetes and on other platforms right now. But we have open sourced as Cosmonic, something called a Kubernetes supplier that allows you to automatically hook in anything that's running in Kubernetes to be able to connect to services running in WASM cloud, automatically. And it's actually all built using actors and receiving events from that and then publishing things into Kubernetes. It's actually really cool and interesting if you like some of the more advanced Kubernetes stuff. But that's just one small part of a service you can rewrite, try it out, see how it works and still connect it back to everything you have. And the last thing is a full stateful application. This is where you could use all the different providers we have or write your own to connect to the different data sources you need. This is for Greenfield application, obviously. But like I said, we're doing that. All that stuff you saw running with the Cosmonic dashboard, that's all running on top of WebAssembly. So that's just what you can do now. So with that, we have some references of things you can go check out if you wanna get involved and that's it for now and we're welcome to have any questions. Yeah, you can see the link to the... I think there are mics up here and somewhere back there if anyone wants to ask any questions and please do come to the mic so that anyone on the live stream can hear you as well. Or if not, then we explained it perfectly or put you to sleep. Just so you know, the little QR code up there that leads to our community Slack, you scan it, join right in, feel free to ask any questions. Of course, Taylor and I are there and would be happy to engage as you try this out on your own as well. We have one question coming. Yeah. Okay. Yeah, yeah. So how does this fit in with GitHub's flow? You know, with... Like coding something on to GitHub and then pushing it out, so good, yes. Brooks actually is about to release a blog post on that so I'll let him answer this question. Yeah, so what we found with GitHub, I personally am a huge fan of GitHub actions. I think it made CI CD a ton simpler, there's a ton of open examples for that and when you get to, you know, part of our demo, we started actors in different locations from an OCI URL and in generally, some registries don't end up implementing the OCI spec but GitHub CR actually does and so part of the thing that we're really trying to do with GitHub is create a nice seamless flow where with our tooling, you generate a little actor project, you get started, you write your hello world, you push it up to GitHub and then what comes with that is a build pipeline and a release pipeline. So, you know, as you're working, automatically get, you know, tests and making sure you're following best practices. As soon as you push a tag or push to main, that actor is automatically pushed to GitHub container registry, GitHub packages. It actually implements like a more general OCI spec so it doesn't have to be just Docker, which is great and then from there, you can pull it from anywhere, you know, started in Azure, started in GCP, all the things. Did I answer your question? Any other questions? I think we're good, oh wait, there's one right here. Come up to the mic, can we have one? We have a little time. We have time still. So, how do I run this in my IDE? How do I run tests and get the providers and so on? Yeah, good question. So, right now, like we mentioned in the beginning, there's still limited language support in general for some of these WebAssembly things. The main language we have the best support for is Rust. We have other ones coming down the line and the nice thing about WebAssembly, why I mentioned it being polyglot is you can just use the tool chain you already have no matter what the language. So, for example, all the Rust, we still use cargo test, we still use cargo build, all of those things are still the same. When you do it in another language like go, which is one of the ones we're looking at, hopefully doing soon, you'll just do go build. There's nothing different and so you get to use all the same IDE tools. You don't have to worry about custom Docker things or having this Docker image and then having to deploy the Docker image and connect to the Docker image. That's not something you have to do anymore with it. Well, I think last call before I... Okay, well, thank you everyone for coming. We really enjoyed seeing all in person and have a great rest of the conference.