 Hello, everyone. Nice to see a pretty decent crowd. My name is Dan Norris, and I'm here with my colleague, Jonas Burgess, and we're here to talk to you today about Get Ups for the Edge, delivering WebAssembly with Argo CD. So a quick overview of what we are going to cover for this session. I'm going to give you a brief overview of what WebAssembly is, a brief intro to the CNCF project, WasmCloud, that we both work with. And then I'm going to go through how we integrated both WasmCloud and Argo CD. We'll talk a little bit about kind of what that looks like and why. We'll also talk about how we actually were able to extend some of those capabilities into Argo CD using a custom Kubernetes operator. And then I will go through a live demo about all this sort of comes together by using Argo to drive a deployment using a WasmCloud application to over 30 plus edge locations. Just kind of demonstrate what all this looks like. All right. Can everybody hear me okay? Just making sure. Cool. How many of you are familiar with WebAssembly? Just getting a quick show of hands. Okay. There's a couple. Couple. Cool. How many of you are using WebAssembly in production? We got one. All right. Two. Yeah, I got a couple of hands. All right. So WebAssembly is a portable binary format for executing applications. It originally was developed for browsers. It was essentially the idea was that in order to build more complicated applications, more performant applications in the browser, you'd use something like WebAssembly to be able to bring in foreign languages that are languages that are not JavaScript, such as, you know, any number of languages. So you could use Rust, Go, see things like that to build very complex applications on the browser side. Now, one of the interesting things about that is because it's coming from a browser environment, you know, it's a, the internet is a hostile place as you can probably, as you've probably figured out. And so browsers, they had a couple of things they had to get up, get right about WebAssembly. First of all, because there's more than one type of browser, they needed to be the format for the format to be portable across browsers. And because of the environment that it's running in, it also needed to be secure. So the sandbox model that WebAssembly had to develop as a result of that is such that instead of taking capabilities away, like we do with containers in order to secure containers, in the case of WebAssembly, you actually have to give it permissions. So the idea was that you write software once, and then you can deploy it in any number of places as long as you can run WebAssembly. And on top of that, because we are in browsers, these applications also, there's a kind of a strong preference that these applications are small, right? Like if you have desktop applications, application or container, those tend to be in the hundreds of megabytes or even gigabytes. Whereas in the browser case, you can't be downloading, let's say, two gigabytes every time you're loading a web page. That wouldn't really work. So in our demo application here, one of the components that actually is powering the demo is just 700 kilobytes. And so you can imagine that's quite a bit smaller than your average container, for example. So before we kind of go further, we do have to talk a little bit about what's really exciting and interesting about WebAssembly. So the idea with WebAssembly is that it is fine-grained sandboxing, and the idea is that you essentially have what's called components. So these components are the container core WebAssembly module, right? This is where your business logic is for your application. But on top of that, these modules also, or these components, sorry, also have the ability to define their imports and exports. And what this allows you to do, essentially there's an interface that you define. And what this allows you to do is it allows you to compose together components or WebAssembly code that's written in different languages. As I mentioned earlier, you can compile any number of different languages down to WebAssembly as a deployment target. And because of that, because of the interface driven nature of WebAssembly components, you can compose those together. So you can imagine, in this case, we have a Rust application that's exposing some set of functionality, so it exports that functionality. And then we have a Go-based application that actually is importing that functionality, so making use of that functionality. So these are, you can imagine you have basically two libraries or a library in Rust and a program in Go. And the Go program is using code from the Rust library. And they don't need to know that they are written into two different languages because they have this shared interface that they're basically using as a way to link together. So that's really cool. So before we dive in further, we should mention Wasm Cloud as well. It's a CSEF project. And it's essentially an application platform that's designed for you to be able to deploy and run WebAssembly components across Cloud, Edge, and so on. We have developed our own orchestrator that helps us do that. And there's also an underlying everything due to the distributed nature of wanting to be able to cross from Cloud to Edge. We also have a seamless compute mesh powered by something called NETS, which is a CSEF project. Really cool technology. I'm not going to go too much into NETS, but you'll see later as Dan goes through the demo what that allows us to do, essentially. So just to kind of recap, what does all this mean? Why should you care? So WebAssembly allows you to target any number of different environments as long as you can have a WebAssembly runtime, which our project CSEF Wasm Cloud actually embeds one of those called WasmTime. You can essentially run your workloads anywhere. It could be running on your Smart Fridge. It could be running on the Edge. It could be running in the Cloud. As long as you can execute WebAssembly, you can target it. And then Wasm Cloud takes that a little bit further by bringing the WebAssembly components aspect, which allows you to compose software written in different languages together without them needing to know that they are different kinds of software. So that's pretty cool. So that's kind of a whole lot of maybe some kind of novel text. So you might be asking yourself, like, that's all great. A lot of little maybe component things you're trying to squish together. How do you deploy any of that? And I bet you'll be shocked to know the answer because it's Argo. So we ended up kind of spiking on this a while back. And we kind of settled on Argo CD as a way to be able to deliver some of these applications, particularly for people who were already running Kubernetes. Because frankly, it's kind of the best-in-class GitOps tool that we've been able to find. There's obviously other good ones, right? Like Flux is solid. But we kind of settled on Argo just because of the functionality. And it really let us integrate our WasmCloud deployment and kind of the capabilities we already had with tools that everybody in the ecosystem is already familiar with. So it kind of seemed like a no-brainer. But how does it actually fit together? Because we mentioned that WasmCloud applications, you know, their WebAssembly, they're kind of their own thing. But the WasmCloud project actually ships with a, effectively, it's a CRD. It's actually just a YAML format. And we'll kind of, I'll show you a little bit what it looks like later. But it's based on this spec called the Open Application Model, OAM. There are other projects in the CNCF ecosystem that use this. So it's kind of like a little bit of an application standard. But basically, that allows us to plug into our own orchestrator that we had kind of written. Because again, these things can run anywhere. They can be on Kubernetes. They can be on Nomad. They can be on bare metal. They can be on little IT devices. Who knows where, right? So we kind of needed something that was a little bit smarter to understand how to place those and how to move things around. We've actually given a whole talk about this. I'm not going to go into it if you're interested. It's on YouTube. I gave it at Wasm Day actually in Chicago this past year. But because of having this YAML manifest, we can teach Argo basically how to use the Kubernetes API to manage and deploy these manifests as if there were any other CRD. It's none the wiser. In order to do that, we had to write our own operator. Effectively, we had to implement the APIs underneath the hood to interact with Wattom so that when you apply this manifest in a cluster, it's actually able to take that and run the correct commands. So a little bit of a graphical illustration of what this might look like from a workflow perspective. So imagine, like anyone else probably in this room, you might be running some sort of project. You've got it all checked into Git. You check in this YAML manifest. Argo receives that event. It knows that, oh, hey, something changed in the manifest. You've already provisioned that application just like you would any other Argo app. But what happens, which is a little bit different potentially depending on what layers of the stack you're familiar with, is Argo then basically syncs that CRD. So it's kind of out of the picture at that point. But this operator that we wrote actually takes over at that point and starts issuing commands to this Wattom observer process basically that could be running kind of anywhere. That's like the lattice interconnection. And that starts relaying commands to all of the various, we call them wasm cloud hosts, kind of like cubelets. But that relays sort of start and stop commands to make sure that its own reconciliation loop is bringing everything to the forefront. All right. So Dan mentioned the operator. That is kind of a key component that we had to develop in order to make this all work. We had originally started down this path of developing an operator as a means to allow our customers to run wasm cloud hosts on top of Kubernetes using just the CRD. They could say, hey, I'd like to deploy a set of hosts and make sure that those are always running. So we developed the CRD for that. And as Dan mentioned, the wasm cloud host just for everyone's identification is our version of cubelet essentially. So it's a program that executes WebAssembly applications or WebAssembly components. But in the process of doing this work, what we realized is that we could also use this as a way to bridge the gap between running or issuing commands to run WebAssembly applications from within Kubernetes because a lot of our customers are already using GitOps tools like Argo. And so they're asking us like, hey, rather than having to force myself into learning a new tool or using different interface, can I just use Kubernetes for this and Argo for this? And the answer is yes, turns out. In our case, because we're operating the WebAssembly ecosystem, we end up bringing a lot of rust because a lot of the platform is written and it's essentially in rust. So we chose to go down the path of implementing this operator action in Rust. And just to kind of give you an idea of what this looks like, this is a little bit small view into it. But you know, we can run kubectl get applications. And in this case, these are not Argo applications. These are WebDAM applications. So they are WebAssembly applications that are being queried from the kubectl as if it was just another construct within the Kubernetes ecosystem. And just to prove that to you, here's a quick, just a snippet of the actual file that defines an application. And as Dan alluded to earlier, it's using the OEM specification and the application kind where we're just saying like, hey, this is an application. And you'll see later on a little bit more about what actually goes into this manifest. But just to prove that it is actually not an Argo application, but it's a WebAssembly application. So Argo and the operator, like as I mentioned earlier, we wrote this in Rust. And so when you're writing software in Rust, one of the things you'll quickly learn is that it's kind of off the beaten path, especially in the Kubernetes ecosystem. There are some benefits to doing this approach. We are using a Kubernetes focused library called kubrs, which essentially allows you to interop with the operator framework, like with the operator constructs, but also very easily defined things like CRDs by using macros instead of having to do the code generation that you end up using in some let go. So there's some benefits to it, but there's also a lot of lessons learned there. So one of the things we, at the time when we're implementing this, one of the things we've ran into actually was Argo was, it was, maybe still is, requires you to present an open API v2 endpoint for the resources that it wants to talk to, as opposed to open API v3, which seems to be where the Kubernetes project is moving. So when you're in the go space, controller runtime actually takes care of this. Controller runtime being one of the popular frameworks for building operators or controllers in, for Kubernetes. And that's really nice, but unfortunately Rust, we don't have such an equivalent thing. And the Rust ecosystem specifically is not super keynote open API v2. So there's, there's a little bit of a here be dragons exercise left for the reader type of thing that we learned. The other thing that you have to be aware of is you are at least in our approach, we had to end up having to create an aggregated API server, because we're talking to a system that's external to Kubernetes. So that was another detail that was a little bit of a learning exercise. So that's all just to say this is not necessarily the, the easy mode, easy path, but going through this exercise was actually really valuable because we learned a lot more about the internals of the system and how Argo interacts with the, with the underlying platform. So there's definitely some benefits to it. It's just that, you know, if you want to go down this path, there's, it's a little bit of like a, you know, choose your own adventure if you will. All right. So we're going to go through, and I'm going to show you a demo actually of all this kind of being fit together. And so what I'm going to show you is using Argo CD to deploy an application, right, with a YAML manifest stored in a Git repo, so your normal Git ops sort of base workflow. The difference is we're going to use, it's a wasm cloud application. So we're going to deploy it to over 30 edge locations running in a cloud platform called fly.io. Just really quick, easy sort of cloud to work with. So to give you a little bit of a sense of what the application is that we're going to be deploying. This is going to be a wasm cloud based application, right? Running on a host. I've already pre-provisioned these just for the, for time's sake. They spent it pretty quick, but you know, demos and whatnot. But what's going to happen is I'm going to navigate my browser to a page that's going to be hosted out of basically some of these wasm components. And so it's a little, the architectures may be a little bit different than what you might be kind of thinking of when you think of just kind of like one binary kind of throw it somewhere, because we're actually running three different components to serve this application. So on the right side, when I navigate my browser, there's a distinct component called the HP server provider, which is providing that capability of being able to receive and relay HTTP responses and requests right to the outside world. The actual business logic of this application is kind of implemented in this like hello actors kind of what I called it. What that does is it receives the request, which is an HTTP request, and it's going to go through and generate a web page kind of on the fly. And what it's actually going to do is it's going to show what region this particular web page is actually being served from. But it knows nothing about that, right? It actually does not have the capability to make an external call on its own or to, you know, read something in the file system. We didn't give that capability. What it does is it effectively makes an RPC call to another capability, what I call the fly.io metadata provider, very clever naming. And that basically gives it the response of like, Hey, this is your region. You know, this is a little bit about sort of where you're running. The actor then basically packages that together in a website and sends that out. So all this happens really quick. Again, these are all really lightweight. That hello actor is 700 kilobytes of code compiled. So it all is like pretty straightforward and nicely packaged, I should say. So with that out of the way, hopefully that's a decent enough overview I'm going to actually go through and we're going to walk through this together. So I went ahead and as I mentioned, this is our cloud platform just because it's like easy to demonstrate. So I went ahead and pre-populated a whole bunch of wasn't cloud hosts in fly.io running. So this particular one here, right, I've labeled them with where they're running just to distinguish them. So this is running CDG. That's the airport code. This is actually somewhere in Paris. Hopefully I actually don't know where it is, but it's definitely in France. So you can see as I zoom out, these are all the various hosts that are kind of wired in all at the same time kind of into this wasm cloud cluster. So we're going to end up connecting to this one just due to the way that fly.io's edge handling logic works because they try and route to the nearest place. So I also have Argo running. This is Argo running basically on my laptop in a little kind cluster. And so what I'm going to do is I am going to let me apply it. We're just going to deploy just an Argo application, right? So this is a repository. It's online. The link is going to be at the end. But it's an application that I already have running out of GitHub, right? Just happen to give it a path to where this enamel file is being served out of. Hopefully that's big enough. If it's not, make some noise and I'll make it bigger. But you know, straightforward application here, right? So that's already shown up, right? You can see it's just been applied into the cluster. So we're going to go ahead and we're going to just click sync, right? No reason not to have done the automated sync. It just was easy for the sake of demo purposes for you to see it all kind of go live. So that was about as quick as it really needed to go to be able to relay that command. Now, what did this deploy? What it actually is managing, whoops, not cargo, because I can type live. It is managing this OAM manifest, right? I'm not going to go into the details of like sort of all the different fields because you can read about that on your own. But if you look at this on the surface, right, this is effectively just a CRD, right? Actually, Kubernetes reads this as if it were a CRD. We registered the type and all that stuff. So it is literally one. You know, it's got, it's a kind of application. It's an OAM spec. You know, it's got a name. And the other thing that to take away from this, right, is it's deploying a series of components. Whoops. That's what happens when you do a live. So it's deploying three different pieces, right? That hello actor here scroll down a little bit further. This HTTP server capability that I mentioned, right? That's being served as just its own asset. And then that metadata component. So these are the three different pieces that compose my app and Argo was able to stream that out, right? So going back to my browser, if I just navigate to, oops. Uh-oh. It's the risk of doing it live. Check the UI. Yeah. Let's see. No, let's see. It's up. It's doing this thing. I think it just hasn't quite fully synced everywhere because when you have 30 locations, it takes a little while to sort of turn through. It's probably, I think it just needs to finish deploying all that. Maybe it works. There we go. Look at that. Just needed a little bit of time. Thank you. Thank you. Appreciate you bearing with me. So this is being served from that actor component, right? It's telling us that it is running out of the CDG region. And to prove to you, this is running in multiple places. What I'm going to go ahead and do is using tail scale fantastic service, by the way, to connect to an exit node I have set up somewhere else. And it's running out of Germany. But if I refresh this page, you see that it's now serving traffic out of Amsterdam. That's a property of fly. I didn't actually do any of that. They kind of have this whole edge routing thing. But again, this is the same application being served out of all these various different data centers, right? And we used Argo to, whoops. Didn't want to do that. We used Argo right to just one click deploy that. So that's as easy as it really can get, really. So if you want to learn more, and I think this was interesting, right? We are, I mean, we're Cosmonic. We have our own booth, K37 on the sponsor showcase. But we have a couple other things going on throughout the conference, right? So the Walsham Cloud project, soon to be incubating, CNCF project, please. That is, we're going to have our own session on Wednesday. What is that, three to eight? Also, we have kind of like an intro to WebAssembly components being put on by our colleague Brooks and someone else, Michael U.N. from the Walsham Edge team. That's another CNCF open source project. So highly encourage you to check that out. If you want to know even more, we've got some, you know, a lot of resources to use online, right? The open source project page is wasmcloud.com. You know, read through the docs and kind of learn a little bit more about what that is, if that's interesting to you. We also have a blog post that also goes through kind of at a high level, some of the things that we talked about today with Argo CD and Walsham Cloud. If WebAssembly itself is interesting to you, definitely check out the Byte Code Alliance. They're the industry group that's sort of pushing the standards forward. There's like, I don't know, 30, 40 different members, like big names you've heard of. It's a good group. And then if you want to see the code for what we deployed today, it's on github, github.com, Protocron, which is my username, Argo CD demo, but you know, you can pull the slides and you should be able to click the links later. With that, I think that's all we had. So we're open to questions. We'll be standing over here and we'll be outside if you have anything else you want to know. Thank you for your time.