 So welcome everyone. I know we're kind of at towards the end of coupon. So I hope everyone had a great coupon. Super excited to be presenting at my first ever like in person coupon outside of the collocated events. So super excited for that. And so we're also excited to introduce the WebSimly working group to the masses for today's talk. So if all of you are interested in learning more about WebSimly or are working in a cloud native startup or in a project and are looking at ways in which you could, like, you know, introduce WebSimly or just curious about WebSimly in general. This talk will be curated for all of you and will be helpful. And hopefully by the end, you will be motivated enough to join the working group and like this help, you know, increase the adoption of WebSimly. So I'm Shwai Amar developer relations engineer at Millie search. And with me, we have Kevin, who is the director of engineering at San idea over to you. Sure. All right. So let's see. It's last day of cube con two o'clock in the afternoon. Everybody's in the food coma. So who wants to see some really cool demos? We have none of those. So the agenda here, basically what I want to do is cover what WebSimly is, why we should care about it, what it has to do with the cloud. And then we'll get into the CNCF WebAssembly working group and, you know, some of the things that we'd like you to do to help out and contribute. So actually, before I get into there, did, did anybody attend the co located WebAssembly event earlier this week? Okay. Who here has deployed WebAssembly somewhere not on a browser? Okay, well, you don't count. All right. So not too many. So WebAssembly is a stack based virtual machine. It is designed to be portable, secure, small and fast. And coincidentally, those are pretty much the main criteria we have for deploying applications in the cloud. So when we say portable, that means that WebAssembly is CPU and OS agnostic. It can't access the operating system, the kernel file system. I'll explain a little red asterisk there later. You can interpret the WebAssembly code or you can jit compile it into native code. It all depends on your needs. WebAssembly modules are not supposed to be used as shared libraries. They're not a replacement for DLLs or .so files. And at least for when you're building on Rust, there are two different target types, one for regular WebAssembly and one for wazzy. And I'll get into what wazzy is in a minute. So as far as security, as I said, that has no access to system resources, can't make sys calls, can't access files, kernel instructions, IO. And again, there's a little bit of an asterisk, but I'll cover that. You can't do things like create a buffer overrun inside a WebAssembly module. It's physically impossible based on the instruction set to tell a piece of code to jump to a non code instruction somewhere else. And for those who've never had to try and troubleshoot those things, that being something that isn't physically possible is a tremendous weight off the shoulders. You can use custom sections inside the WebAssembly modules. Basically, they're just arbitrary piles of bytes. But a number of the run times, including a couple that you'll see here at the CNCF, use those custom sections for things like signatures and security metadata. And the host is the thing that runs the WebAssembly module. So you probably know that the browser is a WebAssembly host. But what we're here to talk about is cloud native run times being the hosts. And those are the things that get to tell whether a WebAssembly module has access to something or not. And by default, it has access to pretty much nothing. WebAssembly modules are tiny, depending on the language that you're using, and what exactly you are doing inside that function. Some of them are, you know, less than 64k. WasmCloud is a one of the CNCF WebAssembly run times. And you can generally deploy a service in under two megs using that framework. And one of the interesting side effects of WebAssembly being small is that the act of deploying it is no longer a big huge thing that happens once and then never again. Because they're so tiny, you can deploy and redeploy them over and over again. And you can take them and move them from one place to another in order to optimize for compute or proximity to data, anything you want really. The other thing that workload size or lack of workload size gives us is that you can cram a whole bunch of compute into a really tiny space that makes WebAssembly modules ideal for running in embedded environments on IoT devices as cloud functions or edge functions. But you also can save a ton of money in terms of utilization. When you're deploying everything, I realize this is a Kubernetes conference, but when you deploy everything in Kubernetes, there's a, you know, a utilization penalty that you pay for pushing everything out as Docker images. There's always that, you know, some unused bit of that Docker image. And I've seen systems where that's upwards of 90% unused. But with these WebAssembly modules, you can pack them in as densely as you want and try and maximize or optimize for utilization. So as I mentioned, it's a stack based virtual machine. I'm not sure if that phrase actually means anything to anybody, but in short, what it means is that it doesn't need to make as many stops while it's interpreting the code. And one of the additional side effects of the way that this particular stack based virtual machine is written is that it can start executing at the top of the module while the back of the module is still streaming in. So in a lot of coding environments, you need the entire executable in order to start working on it. But with WebAssembly, you can start at the first instruction and start moving forward while you're still streaming the rest of the file. So that is a really interesting way to optimize your startup speed. Like I said, you can pause and resume these modules easily, because their active memory is just a pile of bytes. So if you want to pause it, capture the bytes, resume it and just shove the bytes back in. So there are three main kinds of WebAssembly that people are actively using today. And it falls into three different categories. The first one is freestanding WebAssembly. The next one is WASI. And the third one is components. And freestanding WebAssembly basically means that you have a WebAssembly module that has no dependencies and doesn't import anything, you know, anything esoteric that requires things like JavaScript shims. There are a pile of demos out there showing WebAssembly doing all kinds of interesting things like running DOOM and all that. Those are tricks, smoke and mirrors done with JavaScript. WebAssembly on its own can't actually do those things. But it's perfect for running workloads in the cloud. WASI, and this is where that great asterisk comes in, is a standardized set of imports that your WebAssembly module can take. And if the host runtime supports it, it will provide an implementation for those imports. And WASI gives you things like being able to write to a file descriptor, read from an environment. It's not the actual operating system environment. It's a simulated one. Read and write to a file system. But again, it's an isolated sandboxed file system. One of the big mistakes people make is thinking that, well, I can just take my existing application, compile it as WASI, and then everything will just magically work. And sadly, that's not actually the case. At some point in the future, that may be a more reasonable statement, but right now, even if you're using WASI, the code that you write needs to know that that's actually what you're doing. You can't just sort of blindly write to the network and hope that your WASI module will work properly. And the third is components. And components, does anybody actually hear about WebAssembly components? I see you in the back. Okay, so the idea behind WebAssembly components is that you already have these tiny little pieces of compute that you put your business logic in. And they are secure and fast. And you want to be able to deploy those. But if you can define the interface between any two components with a standard schema language or description language, then you don't actually have to have these tightly coupled dependencies between WebAssembly modules or even between the host. So, for example, one of the things that we're trying to do with components is define standards like web server messaging or message broker, key value store, object store. If you build your WebAssembly component to those well-defined standards, then, in theory, you should just be able to pick up your WebAssembly component, put it in one environment and it runs, take it from there and put it under another runtime and it still runs. One of the demos that Bailey Hayes did during the WebAssembly conference earlier this week showed just that. It was a wasm cloud runtime and a fermion runtime and I think just running wasm time from the command line. So all three of those worked. And it was the same component that hadn't changed across all three of those environments. And it's that it may finally be that right once run anywhere promise that we were we were promised but not delivered on by that other language. So the WebAssembly landscape has grown quite a bit over the last, I don't even know how long this thing has been tracking, but I remember when there was no landscape and people would laugh at me when I said that WebAssembly was ideal for the cloud. And so now we have a bunch of different languages that support WebAssembly, a bunch of different runtimes, everything from, like I said, wasm cloud, there's fermions runtime, there's a bunch of low-level runtimes that are ones that are optimized for being run on embedded devices. The idea there is that as long as you're writing to these well-known standards, you should just be able to shop around and pick whatever runtime is best suited to your application needs. And so what we want to do with this landscape is hopefully encourage people to get involved and contribute and to help us reach that point in the future where WebAssembly isn't this big heavy technology thing that everybody needs to worry about. It's an implementation detail. It's a checkbox in the compiler, and nobody has to worry about it again. So what I want to show real quick, I know I said I didn't have any good demos, but I do actually have a demo. So the first type of WebAssembly module that I talked about was this thing called freestanding. And I have a single function. This is in Rust. Does anybody have this syntax confusing anybody or is it fairly straightforward? It's just an add function. I add two numbers and return them. And there's a little tag on here called noMangle. All that really does is tell the compiler to export this function. So theoretically, if I do this without a cheat sheet, we'll see how well that works. Did I do that in wrong order? There we go. So it was sometimes going to yell at me because I'm doing something that they don't plan on supporting. But way down at the bottom, you can see that I've exercised this machine's massive compute capacity to return two plus two. But the interesting part isn't that I'm I have a simple function. The interesting part is that whatever this function did, it's portable and fast and efficient. And I can take that module with no dependencies, no node modules directory, nothing like that. And it'll run anywhere. There's a suitable runtime. Let me see if I can show that. So if I were to strip all of the unused stuff off of this, it comes in at about 300k. So there's another type of WebAssembly module where instead of exporting individual functions in what typically is called the library pattern, you run your WebAssembly module as if it were an executable. So you run the module and it invokes the start function in that module and then it runs to completion. And this is a pretty common pattern for things like web servers where you run the module in response to one request. But there are countless other uses for it. The main thing to remember with these is that they are limited entirely by the host. So if I run it and the host doesn't enable standard IO, my application will have no IO. If it doesn't enable file system access, my app has no file system access. So again, this is an incredible demo that I'm sure you've never seen anywhere before. But what's interesting here is that I've taken this WebAssembly module that technically does not have operating system access or file access or anything else. And the runtime has granted it secure access to standard IO pipe. And so that allows me to do things like display text. I had originally planned on showing a component demo, but the component model right now is in a pretty heavy state of flux. There are breaking changes to the contracts, the code generators and the runtime almost on a weekly basis. So long story short is I couldn't get the demo working. So yeah, I think that's pretty much what I wanted to cover was just the basic introduction to what WebAssembly is and what it looks like to use. Alright, so thanks Kevin for that amazing demo. I know like what Kevin mentioned is that we're not we could not like make the component model demo work. But if you're interested, this type Bailey Hayes, we have had some amazing demos done by her. She works at Cosmonic with wasn't cloud as well. So you can look at some of the Cosmonic based or some of the web component component based model demos at cloud and it wasn't gone and was my own. But of course, today we are going to speaking about what exactly is the context for WebAssembly in cloud. So we of course, you probably might have heard this term that we can start off as a browser technology, but we soon realized this entire idea of being able to this just run this WebAssembly model anywhere in the cloud without having to worry too much about system dependencies. That meant that you can basically take care or you can essentially use these WebAssembly models very efficiently in server side and the cloud ecosystem as well. And according to a lot of the recent surveys, you will actually see a lot of usage of WebAssembly outside the browser in server and serverless and cloud ecosystem. And I think some of the biggest reasons where you will actually see a lot of awesome usage is primarily on edge, version machines, communities. So being able to directly run WebAssembly models in communities, we'll be talking more about how that is being implemented. And of course, if you are coming in from a traditional communities background, being at KubeCon, how you can leverage WebAssembly and also of like talking about workload orchestrators as well. So of course, like we like to officially introduce the WebAssembly working group. So of course, there has been this WebAssembly working group that comes as part of the W3C. So if you're not aware, it primarily deals with the standards of the web, because of course WebAssembly started off as a browser technology back in 2018 with Mozilla folks. So there is a dedicated WebAssembly working group, but that kind of deals more in general with the WebAssembly standards and how it's like kind of operates on the web. But of course, this WebAssembly working group within the CNCF is more dedicated towards WebAssembly and its adoption in cloud and in the cloud cloud native ecosystem. So it comes under the tag runtime. So if you're not aware, the technical advisory group for runtime kind of deals with the different type of runtimes that we kind of see in the CNCF. And I think we started off back in June. So we had a first ever working group meeting back in June. And I and a few other folks were part of the initial chatter where we kind of were defining what is the mission and how the WebAssembly working group will be utilized. So this talk is primarily dedicated to its understanding what are the main missions for this working group and how all of you can also join in case you're interested in whether you are end users of communities or you're contributing to WebAssembly or you're calling to WebAssembly or even to cloud native ecosystems or cloud native projects and how you can leverage WebAssembly support in these projects. So the primary mission for the WebAssembly working group is just to help enable WebAssembly to be able to run workloads related to communities, edge computing and other cloud native ecosystems. So the idea is to help different cloud native projects that come under the CNCF to help adopt WebAssembly as a potential runtime in comparison to your standard containers. Of course, you might have heard, hey, like can WebAssembly replace containers? That's not true. But ideas to help kind of run them side by side or identify those particular use cases where containers might be a bit too slow because as Kevin kind of pointed out that these WebAssembly modules are very small. They are not going ahead and you know, being deployed with any dependencies. And of course, the cold start time for these WebAssembly modules is pretty quick. So if you're especially like running any workloads in edge compute where you're limited by the amount of compute as well. And of course, you don't want to probably wait for, you know, your standard containers to spin up, which can take more than, you know, a few seconds to do that. Like that's where you'll be getting a lot of benefit of running WebAssembly. So the other point is, of course, like we have already started to see a lot of WebAssembly being integrated in different type of CNCF projects. So of course, the landscape and you can just go to wasm landscape for CNCF. We've already seen a lot of different adoption. So whether it's with open policy agent being able to use WebAssembly to basically decrypt and be able to, you know, work with these policies and address them directly in the client side, or it's with Dapper where you're able to directly get support for WebAssembly. Or of course, it's being used in Envoy and, you know, different type of service measures where it you can essentially use WebAssembly to create operators and just to have this one single binary that can now serve across multiple languages. So we're seeing a lot of usage in already in the ecosystem. But of course, the one of the main missions is to help further adoption for those projects who might be looking at WebAssembly, but they are kind of in, you know, Cache 54, like whether they should adopt it or what are the use cases. So really just helping define clear use cases where WebAssembly will work and where it will not be working. So that is why all of you can join the WebAssembly working group if you are kind of in that spot or you're looking to at least look at WebAssembly in the future. So the WebAssembly working group will be working very closely to help define use cases for different type of cloud native projects. Of course, with any working group, there is only the entire folks who help kind of define and run it. So of course, since it is part of the tag runtime, the Liaisons are Ricardo and Heba. So they are the folks who kind of started off and you can actually reach out to these folks in case you ever want to get involved with the working group or you want to actually collaborate with the working group, right? So the TOC Liaison is Nikita and the working group chairs are David Justice and Daniel and of course, the technical leaders are Angel, Kevin, Kevin with us and Sven. So you can reach out to these folks on the CNC of Slack if you want to like, you know, have deeper discussions around how you could, you know, leverage the working group. So yeah, feel free to reach out to these folks. Of course, as I mentioned, some of the deliverables is primarily just helping document and implement a lot of the cloud native WebAssembly use cases. So I think like one of the most important points to kind of note over here is that as we are, you know, whenever we are talking about any new technology, right? There's always this question of how do we implement it, right? And I think like one thing that will probably agree is that the use cases are something that are still not very much defined because of course, we are still kind of evolving as a technology in the CNC of landscape. So one of the deliverables would be to create documentation and use cases on how people can actually adopt WebAssembly for their workloads if you are in the CNC of landscape. And of course, like providing continuous updates. That's what we are doing over here at KubeCon, but also you'll find a lot of like WebAssembly conferences, including the cloud native WebAssembly day. We have recently introduced the WasmCon, which is at, you know, by Linux Foundation. It took place just a couple of months back. Feel free to take a look at a lot of the videos because that particular conference actually captured WebAssembly not just from the cloud native space, but also actually captured a lot of use cases. So if you're interested to know how it's being used in social good or in certain companies, then definitely like, you know, check that out. And of course, like providing a lot of proposals. So as WebAssembly and Wasi are kind of expanding, so there are a lot of different, you know, proposals being written. So very recently, we had the proposal for the garbage collection coming into picture. There's still a lot of like a lot of other proposals for debugging for networking capability in WebAssembly. That is still like, you know, kind of matureing right now as you speak. So coming up with new, you know, new proposals, like we are in talks of like having potentially a tracing proposal that might come in the future. So if you're interested in all of that as well, that's what, you know, the working group will be working towards. And of course, primarily the agenda that, you know, so we kind of meet every two weeks on Tuesdays. One of the major agendas for for the working group is to introduce the different CNCF Wasm projects. So of course, if you might again, go back to the landscape, there are a lot of different open source WebAssembly projects that are now currently being incubated into the WebAssembly, you know, the entire WebAssembly ecosystem under the CNCF. So I have been a long time contributed to the WebAssembly runtime called Wasm Edge that that was incubated just a few, you know, months back. So the agenda of these meetings is really to just introduce new WebAssembly related projects that can be beneficial for, you know, the CNCF ecosystem. And of course, develop specific workloads for communities. So I think like one thing that we didn't specify until now was that now you can actually run WebAssembly workloads directly in Kubernetes itself natively with the help of the WebAssembly run shim, right? So earlier we had the container shim, but now we have the container container wasm shim that allows you to run your WebAssembly workloads side by side with your standard container workloads. And again, you can feel free to take a look at the projects that has run wasi, which allow actually allow you to actually do that. So some, you know, AKS and some of these providers natively now support you to be able to run wasm workloads directly in the communities as well. So yeah, primarily just talking more about like how interoperability in terms of like cloud native ecosystem, whether you're talking about like WebAssembly support and service mesh in dapper and, you know, the standard community scheduler. So core communities or, you know, any of the ecosystem changes and how WebAssembly will be supported. That's what we're primarily covering. And in the few months, you know, since the working group has gone live, we have been able to actually cover a lot of like major accomplishments within the CNC of landscape. So of course, we kind of started off with standardizing the WebAssembly landscape that you see right now. So of course, earlier it was kind of a hit or miss, but you have spent a lot of time and the CNC of itself has really invested a lot of time. Chris from, you know, the CDO at CNCF has personally invested a lot of time. We had the wasm con as well. But outside of that, if you talk about core communities, we have been working a lot, of course, outside of the run wassy project that allows you to run wasm workloads. A lot of work is also going on into the community scheduler extensions. So that wasm can be directly supported over there, but also a lot of work is going on in the underlying architecture for being supported, like the continuity, continuity wasm shim, but also how you can basically have native support with OCS and with continuity itself and like, you know, have basically support for projects like Project Yuki so that those can also support web assembly workloads natively. And that's some of the things that, you know, are there. Of course, with machine learning, a lot of work is going on to help make advancements in being able to run machine learning workloads either as service functions with spin or even like being able to run like large language models directly on edge applications with projects like wasm edge. So a lot of like machine learning stuff is also happening within, you know, the ecosystem. So if you're interested in like machine learning workloads, running them with web assembly, that's also some things that we have covered so far. And of course, the biggest question is how can all of you get involved? That's what, you know, the main agenda for today's talk was. So you can join the web assembly working group Slack channel and again, feel free to take a, you know, click off this of this particular slide. So we are mostly having discussions around that. But of course, there is within the CNCF Slack, we have the WebAssembly channel as well and the run wasi. So if you're more interested towards like general web assembly, you can join that. But of course, if you are interested in understanding more use cases and how you can adopt WebAssembly in your own project under the CNCF, feel free to join that. We have weekly calls on Tuesdays. All of these calls are also, of course, published on YouTube. So you can take a look at some of the existing ones and you can join the mailing list that comes under the tag run time. And of course, you can always contribute to the different CNCF wasin centric projects as well. And these are some resources. So the first one is just the, you know, the official working group, you know, basically the mission and the objectives that we kind of want to cover. The next one is just some meeting notes that we have had from the previous working group meetings. And of course, the landscape itself and the recordings of some of the previous meetings. But yeah, like, I know we are running out of time, but we'll be more than happy to take up any questions now. And of course, you can reach out to me or Kevin on the working group Slack. But yeah, you can scan the QR code to give any feedback. Yeah, and we will be open to questions now. I think we have time for one or two questions. Does WebAssembly offer a good alternative to scale to zero function solutions like AWS Lambda? So I guess the classic answer is it depends, right? It really depends on how you specifically define scale to zero. But because of the tiny size of these modules, in some cases, they don't consume any resources while they're actually up and running anyway. So if your definition of scale to zero is consume nothing, then in some cases, they can actually consume nothing while also being ready to take requests. It depends on the runtime and how that's all configured. But yes, the scale to zero stuff is easier and faster with WebAssembly than it is with trying to dispose of a full Docker image. And for this, I think you can definitely check out spin by Formion. I think they are kind of in this space. So I'll definitely recommend you to check out spin project. Yeah, why isn't cloud does it as well? It has scale to zero in it. In the context of using Web Assembly as a runtime executable, I was wondering if there's been any talks on building a GUI toolkit or some kind of interface to an existing GUI toolkit to be able to run desktop applications in the runtime. Yeah, that's a they're tackling the easier contracts, like the various cloud dependency ones, so key value message broker, all of those things. The hard part with trying to get a WebAssembly module to control a user interface over an abstract contract is defining that contract, right? We've been we've been doing that wrong for decades. So it is possible. I've seen some people try. There are some things where it's there are a couple of frameworks, some in rust that give you the ability to have these declarative UI frameworks. And when you compile your WebAssembly module, it can then, you know, manipulate the browser DOM, things like that. There's also I'm blanking on the name, but there's another contract that uses a frame buffer. So it's basically your your Web assembly module is asked for, you know, essentially a bit map every 60th of a second or so. But there's no there's no one good solution for user interface with WebAssembly. Thank you. Hi. So let's say we've got some application code that needs to use calendars, daytime type information. We have ICU, which of course the data type or data tables alone are like 30 plus megabytes. How does does WebAssembly and the WebAssembly runtime have any way of plumbing information like that in so we don't end up with 30 megabyte wasm files? Sorry, I had a lot of trouble hearing some of that. So you're trying to were you asking about time or yeah, like date time. So we've got business logic that uses date time information that of course uses ICU data tables and ICU to do things like daylight savings time. And yeah, generally with WebAssembly and again, it depends on the language too because some of them do some of them do fancier things. There's a bunch of things in rust that that are designed specifically around that problem. But the short answer is the WebAssembly module has to ask the host for the time because the module itself cannot ask the operating system for the time. All right. So that'd be through like wazzy and then that would do the computation. Wazzy has a standard for supplying time to WebAssembly modules. And again, depending on which language you're using, like if I if I built a like that little Hello World, I probably should have done that little Hello World demo that I showed that was compiled to wazzy. If I had printed the current time, Rust would have translated that code into something that asked wazzy who for the host time. All right. Thank you. Thank you, Ron.