 Libby, you did a great job. Thank you so much. It's impossible to sort of guess how you pronounce my name because I was born and raised in Seattle, Washington, and spent most of my life in San Francisco. Can everybody hear me? Because I see that Jay is asking if it's just him. Can other people hear me? I can hear you. Jay might need to hop out and read some more. Okay, Dan and Nigel say yes. Or play your settings. Jay, do the sound driver dance. While we do that though, I'm just another human on this planet. I was born and raised in Seattle, spent most of my life in Seattle or San Francisco. But my grandfather was born in Calabria in Southern Italy. And so my last name is actually Italian, Calabrese as they say. But that was in 1910. And my whole family's been in the United States since then. So I was raised with it being squillis. Because most Americans would look at it and go, okay, squill ace, you know, kind of thing. But in fact, somewhere along the line, my father decided he wanted to be more Italian. So he called it squillacci. And so I spent my whole life pronouncing it squillacci until I met my wife from Southern Italy. And my wife promptly informed me that I do not pronounce my name correctly at all. What's more like squillace. So nobody pronounces my name correctly, including me. So there you go. I'm gonna go ahead and talk about this. But for sedgissette potreppe, as they say. So listen, I'm gonna go ahead and launch the PowerPoint because I'm a Microsoft person, so PowerPoint's free and this is what I've been doing for my whole life. But what that means is I can't see in the PowerPoint display, I can't see the comments. What's really important here is this is a good, we've got a good group of people, but it's not huge. And that means we should be informal. So I've got a presentation here to talk about and walk through, but I can be driven by questions or interests at any time. And so you should feel free to comment in here or ask in the Q and A section. And like Libby said, I've asked her if she could just interrupt me. And she immediately realized that it's a tremendous joy to interrupt me. So let's play with this. So feel free to interrupt me. I'm gonna go ahead and start the presentation. And the first part of it won't take that long, but I wanna sort of establish a groundwork of why we are in this space that we're in. And we'll go from there, okay? So let's see here. If I share a screen and you get inception, you try this before and there we go. And then I go ahead and you've got inception. And then I hide it and then I go ahead and do this. So in theory, Libby confirmed audibly that you can see the screen. Because otherwise I can't see. All right, great. Okay, so this is what we're gonna do. It's gonna be quite informal. I am Ross Gulash, I'm a principal program manager on Azure Core Upstream. And that is, my team is the Deus Labs team, the larger Azure Core Upstream team handles pretty much everything that funnels into any container or OCI oriented service and upstream projects. So on the Kubernetes side, that will be things like gatekeeper and service mesh work. And I used to be the helm PM for years and years and various other things. The VS Code Kubernetes extension, which is in the CNCS, interestingly enough. But we also do things like the open source work that goes into Azure Kubernetes service and so forth. And so if that team finds a bug, they think it's a Kubernetes related bug, they will help them do a repro and then we'll take the fix and push it upstream so that everybody can benefit. That way the AKS team can concentrate on the actual service and still get a fix right away. And so that's sort of where I sit. Now Deus Labs is an interesting part of that. We actually only do open source stuff to help fill niches in development that we think are critical for moving forward or doing new work that we couldn't do before. So it's not strictly speaking container work, although as I say, it used to be the helm PM. So a lot of it was, still is, I'm the Porter PM if you're familiar with Porter and the cloud native application bundle. But if you're not, mostly what I do now is WebAssembly and Kubernetes. And it turns out that's gonna involve container dshins. So let's talk a little bit about the agenda, which is WebAssembly, what the heck? Because we've got to sort of square the circle, understand why we even care. Kubernetes is the JavaScript of containers and by the way, I claim the trademark on that and I will come and collect royalties. If anybody uses it, so please use it because I need more royalties. Container D turns out to be at least for me, the magic sauce and I'll try and provoke just after later on because he does Kubernetes integration in a different way. And this is very early days. So it's worth talking about or thinking about all the ways you might do it. And then we can let the yelling begin, we can open it up. But as I said, that's sort of a normal agenda and this agenda should be interruptible. All right, just to set the stage here. In the beginning, we used to do native code all over and then when the cloud sort of started, they were like, let's take a VM because we had things like VMware kind of early on in native when you're in Rackspace or something like that. There was some hypervisor that was used actually after bare metal. And eventually we got to cloud things and the VMs were the thing that were operable there which meant that the developers were really always delivering native code which could have, the state of which could have changed any time between when the developer last touched a button and when it was running in a VM. And in addition, it would acquire state while it was running. Things would change in the environment, the running environment. Things like that were troublesome, shall we say but we worked around them because basically if you pay humans money, they'll do all kinds of crazy things. Now when containers came around, it was pretty clear that they were the greatest things since sliced bread, mainly because you could sort of fix an environment and deliver it. We use words like immutability and so forth but it was also the shareability of it. They were smaller, much, much, much smaller and they were much, much, much faster which meant it wasn't just the shareability, it was the pure speed of something you didn't know about. So I always demo when we were doing conferences in person and I hope to do this again. I always demo a container that does the matrix, right? Like the matrix screen, I have no idea how to do the matrix screen but containers are fantastic because all I need to know is, excuse me, where is a container that does the matrix? And I can call it in and boom, it's on my screen and it's just fantastic. And you can do that with run times, production workloads and so forth. So containers still are the greatest things since sliced bread and that's not really why we're having this conversation. The sort of the reason we're having the conversation is because all was well but over the last 10 years, the practitioners, I noticed I misspelled practitioners because that kind of stuff drives me crazy. Please insert mentally an I in there. They discovered issues, right? They love POSIX but it turns out there are other operating systems in the entire world software environment. Yeah, sure, you can talk about Windows but really it's not just that. There are things like, oh, real-time losses and there are BSDs and there are UNIXs and there are all kinds of things. There are new operating systems being built all the time because the environment we work in, it's always changing. So POSIX is great but turns out it's not everything. In addition to things like Windows which is obvious since I happened to work for Microsoft. We also noticed that like architectures ruled everything but that was not as nice as it seems. So it's really great when you're looking at an AMD64. Then if you've got an ARM, it's okay but then you realize is it ARCH64, is it ARM64, is it ARCH64? Is it V7 or V8? And we're pretty sure that RISC5 is coming and is that really going to be the only architecture that we're interested in? We don't really know. And so when we think about like hyperscale like the world we're in right now and I work for Azure, so think about something like Azure or Amazon or Google or DigitalOcean or Alibaba or OVH. It doesn't matter what cloud you're talking about. That approach tries to standardize the architecture and standardize the operating system so that containers work really well in all of these places. And it turns out if you do that it really does which is fantastic. But in the rest of the world it doesn't work that way. And so what you end up having is this weird desire to run Kubernetes all over in little environments all over the place. And to do that you actually have to rebuild all your containers and you have to, if it's an operating system it's different, you have to figure out whether containers even exist and then you have to port Kubernetes to that. And so all of a sudden it gets to be a little bit more difficult. So architectures are an issue. And one of the things that's great about Kubernetes or excuse me, containers is that it's really an entire OS or at least it seems that way to the application. So you can sort of X copy or just RM the whole directory of the application into a container image and you can dork around with it for a while and almost all the time except for the most complex environment you can sort of get it working. Now that's an amazing bit of flexibility, right? It's absolutely fantastic. But if you notice it, it's an improvement in the ability to take the same code and run it in a slightly better way. But it's still the same code. And so in many ways you're actually bringing all the old vulnerabilities that you may or may not know about yet with it. And those may include vulnerabilities in other parts of the environment in the image that have nothing to do with the application at all. So those scenarios, it's fantastic to be able to dump the code in. But on the other hand, if we start running really critical workloads, how do I know that this image really is okay to run? You might be well aware that there's lots of stuff going on in the world about supply chain and security and signatures and so forth. But that problem is so large that even when we get things like the big one we hear about now is S-bombs and signatures, it turns out neither of those things really solves your vulnerability problem. It's merely one step forward in the vulnerability problem, right? Moving from HTTP to HTTPS was a step in the right direction, but it doesn't prevent you from going to the wrong URL. You still may have that problem. And it may also be that the URL is by definition malicious. You think you're going to the right URL and it may even be the right URL. And you'll know one thing about that URL is that it is the one that is serving SSL to you. But that doesn't mean you're not going to get hacked or extorted or phished or whatever it might be. So all the work we're doing right now has to do with all that complex code. It's possible. And I believe it's true that the way forward for a good chunk of our code, not all by any means, is to actually deliver less of it, far less of it. And finally, the last thing was that darn kernel, right? The great thing about container ecosystem is that you were given C-groups and namespaces, but you can hit the kernel, the shared kernel. And that meant that you could just needed the kernel to be the same. And that's pretty easy with POSIX and Linux, which is great. So that was a tremendous benefit. But being able to hit the kernel meant that we spent the last six years in distributions, both physical distributions and also things like, you know, EKS and GKE and AKS and anybody else's cloud distribution. All of those distributions spend millions of dollars and years of people work to try and figure out how to prevent you from hitting the darn kernel any way you want at any time you want, because they're either you made a mistake or somebody else deliberately made a mistake. And either way, you don't really want to own the kernel if you've got other things running on it. So these are problems that we live with today, but they don't tell us that somehow containers are bad. That's not what they tell us. But they tell us that there are some things we wanna be able to do, right? That we can't do as easily if at all with containers. So those people, geez, another typo they yearned for. I need an N here. It was an I forgot and an N, okay? I gotta get them down. They yearned for things like super fast cold start times. So the one thing that native had is you had the ability to start up pretty darn fast, whereas the whole container system was built for sort of like long running processes in a data center. That's what containers, containers are much faster than VHDs. And in that sense, they seem like they're instant. And for developers, that experience was fantastic. But in production, when you talk about like really hosting fast functions, for example, it turns out that they're really not that fast and especially compared to native. And so what you really want is how can we get stuff to move faster than containers generally do? And if you put the Kubernetes ecosystem around the containers, then the gearing is a two to three second delay no matter what it is. That's just the way Kubernetes worked. And it's a good thing for its design, but not for other scenarios or is it? That's what we're gonna get to. And the other thing we wanted was just pure size. Early on, we thought for sure that the developer ecosystem, and this is very true, the people who were in the Docker ecosystem, including me, we really thought that developers would find a Docker file easy. And so what they would do is they would actually develop their Docker files. That's not actually what happened. What happened was people would code natively, X copy into a Docker file. If they found a Docker file on the internet, they would Google for a Docker file for their particular language or project type or whatever was, and then X copy in whatever they were working on and then dork with it until it worked. And then they would check that in with the intention that they would go back and optimize the image. And it turns out that the real world, most people are just working too fast. It's not their fault at all. It's not that they can't go back and optimize the image. It's that they just don't have the time to do it. They've gotta go and build another image tomorrow or there's a tire fire in their service and boy, whatever their background task was today, it's gone now. And it could be gone for an entire week while the service is stabilized. So that results in big containers. So that's the second button there. The size, the containers for smaller or constrained environments where you can't scale out turn out to be too big. Even optimized containers are too big. It's just too hard to spend the time to make them smaller. People do and you can, right? And you can speed up their start times and so forth. But it's just really hard. And now as a developer, instead of working on your application or your business feature, right? You're now working on some little teeny optimization from your point of view that has nothing to do with your service has to do with getting smaller or doing fast starting. And so it just didn't happen. WebAssembly is an interesting solution here. But before we get there, I just want to point out that size became a problem. For those, I probably, I don't know if I'm supposed to say this, but quite frequently people complain about the size of a Java or a .NET container. No, I'm not even gonna say the one I'm supposed to say. You can't drag it out of me. But .NET and Java containers are routinely 500 megabytes to a gig. And that's just because there's a lot of stuff there. I mean, it's just the way it is. If you wanna dump a complex Python in there, you're gonna bring in so many Python scripts, it's not even funny. And so even Python, which there shouldn't be or node or whatever, these are big chunks of code. And really all they're doing is delivering strings in files. So it's fascinating. And by default, we want no kernel access. So we learned this because we spent a whole bunch of time doing mitigations in Kubernetes. I and any number of professionals have spent a good chunk of time doing mitigations, seccomp and app armor and all these other things. And essentially, all of those things do is tell and then of course, trying to get user images and not root images. All of this is really designed to prevent you from using the kernel or to control which kernel aspects you use. But even if you use a kernel aspect and you're being controlled, if you know a zero day in that sys call, you still own the kernel, even if that is the only thing you've been given permission to. So it's a complex problem when by default, you get access to the kernel. Well, we don't want that. We want to have a whole layer between the kernel and the thing. And so you start thinking about things like virtual machines and VHDs and hyperbites and stuff like that. But those are too big. And so then finally, and the thing about containers which we mentioned before, which relates to the kind of the issues that have to do there is we really wanted operating system, architecture, language and location portability. And by location portability, we mean things like, can you bring the code to the data? But at the same time, we really wanted all the usual container benefits. We want immutability, we want signability, we want to be able to attach a bunch of metadata that says where it came from and all that S-bomb stuff because it will provide value as we go forward. And we want to be able to do the things that we do with containers. We want to be able to store it in some sort of registry and pull it down with the stuff we already have. So that's kind of interesting. So while we were doing this, all of that Kubernetes and container land, there was hostile browser land. And JavaScript becomes slower during that period clearly the way to program the browser. But then in those environments, they're very rapidly understand that they want actually faster stuff because JavaScript is an interpreted language. So the first thing that the browser has to do is have a JavaScript engine that grinds the actual text down to an abstract tree and then spits that out in some sort of intermediate code that can be run in the VM, ground down into machine language and run in the VM eventually. And boy, that's fine for popping up a color or a little pop-up and stuff. But if you want to do something really complex, that's pretty slow, right? Okay, so that's one thing they know they want, faster stuff. And they want all the operating systems because why not? They're browsers, they wanna have a browser on everything. They also want all the architectures because why not? They're a browser, I wanna be on everything. And they absolutely have to have by default no access to the operating system. So the whole syscall thing is right out. And that's because obviously they're being attacked. So if somebody can get into the process in some way through the front door, that is through the browser usually, right? They can't be permitted to go ahead and download a script that then goes and hoses the operating system. That's very bad. And then finally, of course, because the more JavaScript you have, the more text you have and pretty soon your web request slows down and users get frustrated they have to wait three seconds to make a million dollars. And that's very disappointing because you wanna do it in like three milliseconds, right? So it has to be very, very small. And there are other reasons, other things that have come up in that period but I'm sort of trying to bucket the process in hostile browser land. And what came out of that is WebAssembly. And so if you think about WebAssembly in you're thinking it's from the browser and it's a browser thing, you're sort of right, right? That was where it was developed. But before we go somewhere I wanna really kind of talk about WebAssembly outside the browser, right? First of all is the key elements of WebAssembly that I think are critical. And I'd love to have an argument about this, right? First of all, and this deck we'll make sure we share and everything like that but this is a link to the VM specification. It's a stack-based abstract VM. So when we were thinking earlier we didn't want access to the kernel and we thought that sounded like a hypervisor or a VM of some sort of emulation and whatever. This is exactly what that is and you can think of it like the .NET framework you can think of it like Java VM and whatever it might be it is not strictly speaking emulation it's its own operating system statement in a way is a way to think about it which is why assembly sort of fits even though it's not really assembler either. But it's been in all major browsers since 2018 for things like Google Earth and Adobe Lightroom and things like this. In fact, I'm almost certain that this underlying platform that we're showing right now that's streaming my video to you almost certainly is built with WebAssembly from browser to browser, right? I don't actually know but I would lay money on it. So some of the critical things are is that the host in WebAssembly and in the browser that's a JavaScript engine but outside of the browser anything could run and including a JavaScript engine like you can code V8 or SpiderMonkey or any other JavaScript engine to host WebAssembly modules and execute them. All code in that environment is deemed untrusted and the sandbox for WebAssembly is unbroken. There have been, there are security areas where it's problematic and you have to pay very close attention but the sandbox itself works. It's not a sandbox problem and that's really, really great. There are problems that doesn't have, there's no threading, okay? So you can't think of like you can do thread pooling and there's no GC or memory management and there's a bunch of other things that are not there and it's only 32 bits so your addressable memory is like, you know, four gigs but and I do wanna be quoted as being the first to say really nobody should ever need more than four gigabytes of memory. So I'll, you know, claim that one. Most of these things have proposals that are on the way but they won't be here for a few years and so the real question is like, okay so what can you do with it? What did you probably shouldn't do? And that's the way to think about it because we're thinking about engineers. The other two interesting areas that I think are critical for what we're doing especially in Kubernetes and for the, the kind of definition of the problems that most of the ecosystems run up against are the Wasm System Interface or WASI which is really sort of an abstract syscall spec. So you can think of it as like an operating systems, a set of kernel calls, right? But they're virtual, they don't, they're not specific to any particular thing so they're not positive or anything like that. And the component model which is a way to create tightly constrained interfaces that define capabilities that the module can perform or requires the host to perform on its behalf and so there's two sides of a component interface and the way it works is basically that the WASI syscall set, right? That specification will sit on top of the component model. There'll be component model interfaces or at least that's the way it's being looked at and discussed right now. Both of these things are in an experimental stage but progress is healthy and rich. However, it's not moving as fast as like, hey, you're gonna get something tomorrow or next Tuesday because these are very complex systems and they have to be optimized for speed and for security. So what do those elements provide? Well, strangely enough, they provide a lot of the problem features areas that we identified as being an issue with the container ecosystem. And so we love containers but then if we need these particular things we might have to mix containers with something else. And so when we do that, we look at these categories. Because the host owns the mod of module, the host can't permit or deny anything it wishes. A module cannot request any feature or any behavior from those unless the host permits it, right? And the interface model constrains any ability of the module to make calls. So if you have a component and it implements one interface, for example, if you're talking about an HTTP request, that interface might say, I must consume, you know, I implement something that receive a function, one function that receives a request and I return that function returns a response and that's it. And if a host implements the opposite side of that contract, right? Then that module can be coded to that contract and you can code in any language and you can see that's part of the portability. That means though that both the host and the module, right, can only perform that function, which is fantastic. So interfaces constrain the abilities of a module to do whatever it wants. So even if a module has malicious code, even if it might find a way to invoke a call, it can only invoke the call through the interface. And not only is the shape known by the host, but the host could dynamically inspect those interfaces as well and make decisions on, you know, what kind of content the actual return value had and do something good or bad, depending on what the host decided. Modules have implementations, but they own nothing and that is a great stance. So the other one is the speed size combo because they're binaries, right? And because they're not containers and are optimized for speed, the speed and size combo is amazing. So you can treat it all, it really depends on your workload, but we're talking about somewhere between, hey, a 10x reduction in size to a 50 and 60, 70 where the x reduction in size, that's really amazing. And native cold starts are approachable. So optimized, you can actually start a web assembly module and enter a function in low nanoseconds. It's entirely possible, but most importantly, it's really important to realize microseconds, low microseconds is like out of the box. And so the throughput there with the size, that is the module gets delivered very, very fast. You can have density and you can cold start per request a new module. So your multi-tenant location of focus becomes the module and not the whole host process, which is very, very advantageous. So now you can start to see why things like Cloudflare and Fastly and Netlify and Bercel and even Akamai does this now. And I'm sure all of the major clouds will do this soon. Use this for their CDN functions. That's how they do. Okay, Ralph, we have a question. Yep. Okay, so Nigel asks, so when things like GC threading fully implemented, Waze, networking, et cetera, is there a risk it will bloat and lose some of its superpowers, side speed, security, et cetera? Absolutely, and that is the risk. So here's the deal. The reason I love web assembly, the reason I'm betting our company's investment on it and supporting the upstream. So for example, my company's is a sponsor of the Byte Code Alliance Foundation, which is doing most of the W3C work for the specifications involved here, things like that. My team contributes to those. But we also support, for example, the Python compilations. We support the infrastructure for building and testing the Python builds to Waze, for example. So we support all that, but the reason all these investments are happening is because the sweet spot for web assembly is not to replace the model that containers excel in. So think about it as a sliding scale. If you have no threading, that is, you have one thread, then by definition, you're, and you have fast cold starts, which is what you get. Then by definition, what you really wanna lean into with web assembly is the thing that containers can't really do, which is give you multi-tenant per request super fast response times, right? With super small functions. Now, the container model can't compete. You can't create a new container that fast. You can technically, but in reality, you can't do it at a democratic scale. So what is the value of the container? What is the sweet spot for the containers? You notice that pods actually are up and running all the time. And that's because they can. And they can do their own scheduling. If you put a web server in a pod in a container, then create pods and host them in Kubernetes, right? Those web servers, they have their own threading pools. They have their own connection pools, all that kind of stuff that was built for architectures like three tier models 25 years ago. And if you think about it, the container model enables us to continue building applications that way. But web assembly does not, but the benefit it gives you for not building that way is that you can do all kinds of things you can't do with the container. So that's the sort of the dividing line, the super fast, super small, single threaded, do your work and get back to business and create another module for the next work item. If that sounds sort of functioning or serverlessy or microservicey, it should. That leans into that kind of approach technologically. But what happens when you wanna actually run a big long running process as a web assembly? Well, remember, you only got four gigs, so you can't do it now. But if you get 64 bits, now you've got the memory space. If you get threading, if you get async, all the things that enable concurrency in a large process like an OS style process, what you're gonna end up doing is everybody who knows how to build three tier models and three tier software that is still being built that way will just port the same stuff to web assembly. Now, will it be good? Yes, will it be better? Yes, it will, just in the same way that containers were better than native. But it is not actually going to be so much better. It is going to be the same code with the same environment. For example, you're gonna see, and you already have seen experiments with full web VMs. In fact, there's one called webVMI.io, which I think is Chirps attempt at a full container or VM in web assembly. And the thing about that is, it's fantastic for what it is. And maybe that's the feature you want. So I'll use you, Nigel, as an example. So maybe Nigel, that's the feature that you want. I don't want it, I don't want it. If I'm gonna run a long running server process that wants all that stuff, right? I'll probably do it native or I'll do a container. Maybe I'll do a web assembly, but only if I need that web assembly to run on any architecture and I don't care about speed. I don't care about any of that other stuff. I basically just want to get the kind of default security and the portability that I get out of web assembly. And those may be enough, right? But you're not gonna get that for a while. And frankly, if you do that, you're going to still run into the same problem we have with VMs and containers now, which is we have no idea how to secure that entire operating system. And so unless you're gonna write code that leans into web assembly and be a binary instead of a collection of processes with an environment, you're gonna bring things with you that you're gonna end up having to mitigate anyway, even though you're inside a web assembly. And remember that those big processes, now you're gonna have to open up all the kernel features to the module that essentially start to, at some part of the gradient start to negate the constraints that the security model of the component interfaces starts to bring. So that's not a yes or a no, I guess. It's really an argument for where you should start thinking about the difference. And in two or three years, maybe you wanna think about the difference differently, like on that sliding scale. Maybe I will think about it differently. I don't believe so. I believe that the next 10 years of computing must get more constrained. The developers have to be able to do more, but they have to worry about less and we have to ship less code. There will not be faster and bigger chips in all the little devices we're talking about around the world, not floating or not in 5G node towers, not in space, not in submarines, not in ships, rowboats, my cell phone. These things are gonna get bigger, but they're gonna get more electrically efficient and slower at the same time per unit cost. And that will be good. We need them to burn less electricity. But in that environment, you don't wanna bring your data set. You wanna do something different. And that's how I look at it right now. Did I, is Nigel, Nigel, is that a good thing? Liddy, I can't see the chat. So you gotta tell me whether Nigel says thumbs up for now or thumbs down for now. Okay, he says, so clarifying, are you saying you don't expect wasm to get GC threading, et cetera? Because if it did, it would lose its edge. No, that's not what I'm saying. No, I expect there is a GC proposal. Dan, I know is, if Dan is still here, he could probably drop the PR for the proposal, the issue for the proposal. There's GC, there's memory management. All the things that people will want are coming. And so what I'm really saying is, Dan might have a different opinion, but my opinion is those features will not arrive in anything concrete before two years from now. And maybe I'm pessimistic, but I actually think I don't want them. I don't need them. I want a new module, I don't want a new thread. That's the way I look at it. Okay, so these are the portability and so forth and we'll go on. And this is Werner Vogels doing the AWS thing. Very actually Prime Video basically uses WebAssembly right now for more than 8,000 device types and that's the kind of radical portability you get with a single module. That's incredible. And of course, it doesn't mean that the module is the only thing that's on those device types, right? You gotta have something that runs it. But the point here is that the service's job is to make sure that the thing that runs it is there, but the developer only has to think about the package for the process, which is WebAssembly and it's like you compile to WebAssembly, so it's more like a native process. There is no Docker file to build for WebAssembly itself, although I'll show you that there's more stuff to be done to make it work in Kubernetes at the moment. All right, so Kubernetes, and this is my take, part of my hostile provocation, is the JavaScript of containers. And by that, I mean, you don't necessarily like it, you might not have built it that way yourself, but you got it and you use it and so does everybody else. And then they gripe about YAML and service meshes and a few other things. Oh yeah, so ingresses are not good, it's like this kind of stuff, but we use it. And it turns out that network effect wise in the world, it's incredibly useful, right? So the question is like, what do you wanna do, right? You wanna integrate and people tell us this right now. So speaking from the perspective of Azure, all I hear from customers are, I wanna run Kubernetes on my automobile. I wanna run Kubernetes in my house. I wanna run Kubernetes in my whatever it is, okay? And then they say, but when I try and run Kubernetes, it's either too big or I have different machines like I have got ARM and Intel and I've got various other things. In other words, what they end up saying is some combination outside of the hyperscale environment where everything is the same skew, you gotta choose everything and line up your cluster a thousand nodes the same way. They're identical, clusters work great there and containers work great there. The real truth is that Kubernetes is what they want for the control plane. That's what they're asking for. But what they don't know because they haven't been told and that's partly my job is that Kubernetes could work in these strange environments where either they're heterogeneous by OS or by architecture, right? Or by language, something like that. Or they're constrained. They don't have a lot of room. They have flaky networks or very thin attenuated network connections. And they maybe like barely have any RAM let alone disk storage and things like this. So the size has to be really, really small. And the performance has to be really, really good for unit of artifact, right? Those environments don't work really well in containers. And like I said, the point here is not that containers are bad. It's that we were talking about compute environments where containers don't really work well. And for sure, and CDN it turns out that's true for pure cold start and security. So all of those environments are web assembly. Okay, that makes sense. Those are technological choices, not religious battles or emotional feelings. And so people sit there and think, okay, I wanna do Kubernetes but with web assembly. And so there's lots of work here. So Giuseppe is on the line. I know he's done a lot of work. We've been squabbling recently socially about CRUN integration, right? Like so CRUN can run containers or web assembly, which is a cool way to do it. Or some companies like Wasm Cloud, which is an open source kind of actor based model for the most part. They have a microservice orientation, but the sweet spot for them is actors, they have a Kubernetes integration that allows their actor model to essentially be scheduled from the CRD. And you use the CRD and that's their integration with Kubernetes. But in reality, you can use it in Kubernetes if you like the model and you have Kubernetes control planes, but it's really designed to run anywhere and it does its own scheduling and networking and things like this. And so you can do all kinds of cool, you know, transparent networking and neat mesh scenarios like that. So that's one way to integrate with Kubernetes. And the question is whether it's the useful one for you and maybe if Wasm Cloud is your kind of thing. There are also CRA implementations and Kubelet implementation. I'm gonna talk about those in a second. And of course, the interesting thing about WebAssembly is because it can be embedded very, very easily. It's already probably in your Kubernetes cluster. You just don't know it, right? So Envoy network filters except run WebAssembly. And now that's, you know, all the rage. So almost certainly some of your Envoy network filters are WebAssembly based. Kubewarden and a couple others do policy enforcement using WebAssembly. So if you use those projects, you're using WebAssembly and that's there, it's already there. So it strangely already exists pretty much everywhere, even in Kubernetes, but people aren't conscious about building WebAssemblies for Kubernetes and just using Kubernetes to orchestrate them. And that's what we're interested in. And to do that, we use a CNCF project called Container D, which is our magic sauce. And the question is whether it's yours or everybody else's because as I said, there are tons of ways to do this. So what we did is we failed a lot. And so when I say we, I'm gonna call back to my team at Azure, which is the Deus Labs team and we do completely open source. And we failed to integrate Kubernetes in a project called walk. So if you go to hdpsgithub.com slash Deus Labs slash walk, you will find a CRI implementation and boy, did that not work. And the short version is very straightforward. CRI really is a container runtime interface and it wants to be a container. And so it's very much hard coded to containers. And so when we implemented, we were basically faking out all the API calls that are container specific that had nothing to do with WebAssembly. And we realized that the abstraction wasn't there. There were, it should really be a compute runtime interface. And so personally, I think we have room for a CRI v2 over the next five years, but it'll take a while to sort of decide how that works because of course, wasm time is not the only runtime that somebody might want to work straight with Kubernetes. So then we failed again, but we succeeded with something called Creslit, which is in the CSEF. We don't continue to invest in Creslit except for to review people's PRs and so forth. There's several people that run with it. Many people use it for the rust-based KubeLit and also for the rust-based OCI distribution crate. So that's something and it's very useful for that. There's also a state engine crate in there called Cretor that is really, really good. But the problem with Creslit is that it tends to treat a node as if it's a special node. And so you actually have to say, this is the node that runs WebAssembly and no other. And that gets to be problematic because we don't need Kubernetes to teach us more things to pay attention to. We need Kubernetes to slowly but surely let us forget about things more and more. I would like in five years for Kubernetes to sort of finally find a default configuration that's pretty much a simple, but manageable and robust orchestrator. We're on that path, but it's gonna take time to get there. And Creslit is not added. That it adds complexity to your operations, even if the developers have a clear path to using it. So for us, a container D's shim turns out to be the right path, the great usage with Kubernetes. Container D is the wedge, the hinge in vanilla Kubernetes between the Kubelet, which calls container D API to schedule a workload. And the actual implementation of scheduling, which could use different binaries that could make different adjustments that might do different things and so forth. But container D is just the API facade or an implementation inside, which we typically call a shim. So for example, Giuseppe, I think RunSeq, C run has a shim. The default shim in Kubernetes, vanilla Kubernetes, is the RunSeq shim, I think it's called container D RunSeq. And so we basically use that same functionality to plug in a different runtime, which is wasm time. And that's a bytecode alliance runtime. And we then are able to schedule wasi run loads. It's run wasi, not run wasm. So run wasi does not run web assembly only. It has to be conforming to the web assembly system interface model. And use components in that regard as we go forward. Because the sweet spot is not, let's run some custom module that has custom interfaces as something. If you wanna do that, you're more than welcome to grab the shim, including run wasi and actually rip out the innards and modify it and do something custom. But we wanna be able to actually enable an ecosystem where wasi implementations, wasm components, right? Can be used on any standard Kubernetes interface, excuse me, Kubernetes cluster pretty much anywhere. And it just works. And it all brings the same level of guarantees that I talked about earlier. And so that's our objective there to scale out the possibility that Kubernetes could be used in these weird areas. That's what we're doing there. And container D lets us do it. Now, there is a little bit of history here and I wanna sketch this out. Where are we on time? I think we're at what? We have six minutes left. That's horrible. It's horrible, I was gonna do demos. I am a bad person. So the critical thing here is that run wasi, our run wasi used wasm time. And run wasi was forked by a second state because they were working with Docker desktop and they wanna use the second state's wasm edge runtime. And so they have a second state run wasi, okay? And that is what the Docker desktop project uses. And then our run wasi, the day's last run wasi was accepted into the container D project in the CNCF. And second state and Docker immediately sat down and said, hey, let's figure out how to bring composable run times to run wasi in container D. So it's really the same shim. And so we're all working on that together. And then we're also working on OCI compliance and OCI artifacts around the roadmap. And now I can go to demos, but I'm going to switch gears and come back to inception and basically stop sharing. And yeah, so it starts in five minutes. Oh, no wonder I timed it for this. This is great. So if there are any other questions, go ahead and ask them either in chat or in the Q and A. The chat's fine. But I will do a quick demo so you understand what web assembly really brings. I can also do a quick demo that helps you understand it in Kubernetes. Everybody vote right now or ask questions. Which demo will we want? We want to see what web assembly can do that's really, really important to make sense that you would want to run Kubernetes cluster for it or do you want to see how it actually runs in Kubernetes so you can try it out? Go ahead if you're still here even. There's 22, they're technically still here, but they have the TV on over here. The ladder, how it actually runs in case. Okay, so here's what I'm going to do. I'm going to share the screen. Okay, and then I'm going to jump over here to this and I'm going to show you something I will show at the Docker community all hands tomorrow. And one thing I want to ask is you shouldn't be able to hear anything. Are you hearing audio other than my voice? I don't think so. Okay, so I'm going to do this. I'm going to go ahead and mute myself so that I can talk over myself. So what I'm doing is I'm showing you K3Ds. And so this uses our RunWazishim and so you should think that you would be able to in the future do this with the Docker desktop release or any other desktop release. And so we're going to use K3Ds and you see right here that what we're going to do up here is we're just calling in a shim right here. It's not a shim, a container. And in K3Ds, the nodes are modeled by containers and that container has the shim already on it. So we'll go ahead and create how this works. So you should be able to do this, right? In the deck that we'll share, we'll drop in the quick start for this but you should be able to find it very, very easily on the web. This is just K3Ds. This is basically real time. So you can start this pretty much anywhere you can find K3Ds and you should have roughly speaking the same experience. So what we're going to do here is deploy a two wasm time based applications using Fermion's spin. But before we do that and a DSLAB slight application, but we'll do that. We got to tell Kubernetes that the shims exist. And so right there, we've told them there are two one time classes. And those are the names, one for each app model, right? And all of a sudden when we deploy the application, you can see we've got five slight applications and five spin applications. And the interesting thing is we're actually waiting now for a container workload. Now I'm going to stop that in note. We are waiting for the ingress container to load while we have already started every single application but we can't reach them because there's no network path. Blocked by the ingestion, mounting and execution of the traffic container. So if we sit here and wait a minute, just a second, the container comes in, there it is. So now we can go ahead and start curling. And here I sped up the demo a little bit, but basically I'm waiting for the traffic container to create the local host path. Okay, I've got it. This is just a hello world, right? And so now you can see both of them there, right? So that's one real easy thing. From here, so I'm going to show you both curls, but from here you can see you can do any kind of thing. This is hello world. Now if I, from now on this demo is going to tear it down. If I go over here, one of the things I want to show is how it looks in Kubernetes and what you can do. And so here I'm in AKS. So you could run this in any cluster, you know, AKS has a service that allows you a Waze node pool service that this infrastructure supports. And I've got now two node pools, ARM and AMD. And so I'm going to actually load a regular container app, it's the voting app. And you can see that it gets scheduled for Waze pool two and it's failing, but there's a reason. And the reason is it's being loaded on an ARM node. Now remember, ARM nodes cost about 30 to 50% less and they consume less energy. So what happens if I do this with a five replicas, I'm going to do the same workloads that I ran on the K3Ds. If I do that with WebAssembly now, they go up. And if you look at Wasm Slite and Wasm Spin, you'll notice that the Wasm pools are essentially evenly distributed. Now for the container app, I have to go back and build a multi-arch build. I have to now have two copies of the container. But for the module, it just doesn't care. But there's only one module. I'm like, it's not like there are two or anything like that. And I can demonstrate that, but now I'm going to go in and choose Waze pool one, which is the AMD version. And I'm going to delete it right out from underneath the cluster. If I do that, now watch, this is not sped up. Terminating the nodes and all the applications are now redeployed. Every single one is now Waze node pool two. And that means that I've just migrated my entire workload from AMD to ARM and it never stopped. There's no redeploy here for the five that were already distributed to node pool two, which means your workload continued to be serviced. And you went ahead and redeployed all the AMD wants to ARM and it happened just that fast. You didn't touch it, right? Kubernetes did it. And all the while the Azure vote, which is a regular container version, right? Just doesn't work because I haven't done the extra labor I need to do in order to migrate the workload to AMD. And it's not that I can't do it. It's not that it's impossible to do. It's just one of those things. And so that in theory, should be good. I'm gonna stop sharing. And I wanna thank you very much for coming. And then the last thing I'm gonna do is drop in that link to the stuff. The stuff, well, I'll get it for you. Thank you so much, Ralph. Thank you everyone for joining us today. Did we get the link in the chat? I'm gonna get the link right now. Okay. All right, there it is. And we go ahead and this is the quick start right here. It does everything I just did. And I can drop it right in there. And it's a URL, so I hope that works. Thanks everybody. Thank you everyone. Grab that link before we end our session. And also you can probably hit Ralph up on Slack on the CNCF Slack channel. Absolutely. If you need to get any other information or links. And thank you all once again for joining us. Thank you, Ralph, so much for hopping in and providing such a great webinar for today. And again, this will all be posted later today on the website. You can catch the recording, all that good stuff. And thank you everyone for joining us. Have a great rest of your 2022. It's time to watch the match. Yes. All right, goodbye everybody. Thanks Libby. Bye-bye everybody.