 Right, hi everyone, I'm really excited to be here. I like conferences of this size, so it's much nicer in my opinion we have to get to know the people and when it's 100 people and not 8,000. So today we'll be talking about build, share, and run of WASM using Docker. So I'll start by introducing myself and then hand over to Michael. I'm Chris Kroner, I'm a director of engineering at Docker in the content group. We're responsible for some of the low-level pieces like runtime build and registry as well as content you'll know of things like Docker Visual Images, Docker Verified Publishers, and some of the newer things we've been doing at Docker which include desktop extensions and Atomist. Michael? Okay, thank you Chris, yes, my name is Michael Yuan and I'm a founder of a company called Second State but more relevant I'm the maintainer of the WASM Edge project at CNCF. I'm gonna tell you in a couple minutes after why is there need another WASM runtime outside of WASM time and what are the unique features that we have and why we work with Docker, so please. All right, so when I was thinking about talking today it really got me thinking about why do we want isolation and it's quite a prevalent thing inside software we have isolation and separation in lots of different places. The first case is facilitating reuse and we heard a lot of this earlier about the component model. When you build well-defined interfaces you can create these boxes of value and reuse them and that's not just for yourself inside your own company or just on your own projects but you can then share them with other people and that's a really valuable thing it has this compounding effect of not rebuilding everything. The second one is about sharing compute resources so by isolating your workload you can share compute resources in different ways. This starts with, my dad was an engineer as well and he would use punched cards and the scheduling mechanism was literally a piece of paper, you write your name on the list and you get a slot of time and you get to go and run your punched cards. That theme in computing of we want to use the maximum we can of a shared resource which is compute has continued except the boundaries have changed a little bit, right? So we want to define good boundaries because we might not necessarily trust the people we're running code next to. We might not trust our own code not to pull down somebody else's workload as well. Like that's another case where we want to have these well-defined boundaries. So you want to be able to say what are the capabilities of what I'm running? Can it hurt other workloads? Can other workloads hurt me? How do we make sure that the code doesn't interfere with other code running? And then ease of delivery of applications. I think this is another thing that's really made software unique in its velocity is the speed with which we can deliver value to customers. If you compare a manufacturing plant or things like that it takes months or years to get things to people whereas in software it's literally seconds and that is an incredibly powerful again compounding effect that's enabled by isolation. And we do that by having well-defined packaging mechanisms. If you know, if you have a well-defined box like a shipping container or a software container you can build infrastructure that allows you to deliver much, much more quickly and that's a really, really powerful thing that isolation and separation enables. So taking a look at some of the isolation techniques that we have in our domain, we have kind of a spectrum and there's lots of different ways of doing this. So one example on the extreme side is air-gapped. This is where you literally don't trust anybody outside of your compute space and you make the compromise on that ease of delivery by literally having to physically be next to the machine to deploy it. But that comes with a bunch of security guarantees. Hardware virtualization, this is kind of the thing that kicked off cloud computing, right? You no longer need it to plug a computer in or have access to a data sensor. You could use an API. I mean, this is crazy if you think about it. You could literally call an API and create an instance of compute. Then, you know, where at Watson day I have to bring up stack virtualization. When you control the runtime and the language, you can start looking at what kind of guarantees, what kind of, how can we cut this up? What boundaries can we create? What interfaces can we create to give us this isolation in various different forms to improve the software delivery? Containers, of course, I work at Docker. I have to bring up containers at some point. Containers are interesting because they leverage the same kernel but they isolate the processes from each other. So they can't see file system unless you let them, they can't see each other unless you let them. This also gives you some of those guarantees of my workload won't bring down somebody else's workload. You can set up limits in terms of memory and things like that to ensure that. And then raw processes, we kind of defer to the OS to say you handle the boundaries between things. By default, a lot of the time that is, it's open bar on the file system within that user's space. Mac OS, for example, it started locking this down a bit. If you touch sensitive things, they'll prompt the user for permission. But that's, this is another box where you can ship a raw process and you have access to lots of things. And then kind of finally on the extreme end, you have dynamic libraries which have well-defined interfaces. You can get a header file, for example, which tells you exactly what inputs you put in, what outputs you get out. And you can share memory inside the process so you can get really high performance. So that obviously brings up the question, well, which isolation mechanism, which of these tools should I use? And I get to pull out the Simpsons meme here. It really just depends. And it's kind of hard. When I started this talk, I thought I could throw up something like this and I have to quickly push the down arrow before you take a photo of that. I thought I could put up three dimensions and say, if you care about isolation, use this. If you care about ease of use, these are the ones that are better. Or if you care about resource utilization, use that. But I realized quite quickly, it's much, much more nuanced than that. And that's why we have the CNCF landscape. This is, but I show this in every talk when I talk from the CNCF. It's everybody laughs because it's so painful. And part of it is because developers love building tools. But the other part of it is there is no one perfect tool in any domain. And I feel like it's our, especially at Docker's job to try and help people navigate this landscape. If you show this to a developer who's just trying to ship a feature, what are they supposed to do with this? This is crazy. We need to help them navigate this space with the right tools to solve the problems that they have. So the theme of this should be, pick the right tool for the job that you're doing. And with that, I'll hand over to Michael, who can talk a little bit more about Wacom. All right, thank you, Chris. So when to use Wathom? And we all quickly go through those points. Of course, running something in the browser, that's original use case, right? If you're building an application from source and it can output Wathom, that sort of is a prerequisite, right? You have to have a language that can output Wathom. If you don't, like in Python or JavaScript, you have to have a runtime that embedded in Wathom. And what I find most interesting is something that need a quick startup time. So that's the serverless use case, where if you look at AWS Lambda, one of the biggest complaints, that's the code start too slow. So how do you deal with that? You can have warm up instance, right? However, with Wathom, like we have seen in Fermion Spring, you can just spin up as requests come in, so you don't need warm up. And even if in cases where we're gonna talk about in a minute, where you do have long-lived servers, like CRM, something like that, Wathom takes a lot less space than, say, a container plus Linux kernel and all that, right? So for something that needs startup time, whether it's start on demand, or it's a warm up instance, Wathom both offers significant advantages. And then we have seen from early talks about component model, there's a lot of security considerations that's especially relevant today with all the supply chain, software supply chain security issues. And that requires small incremental overhead, that Wathom can run in a much smaller package than most competitors. And when not to use Wathom, of course, application require modest threading. However, as we have also seen, there's threading proposals in WebAssembly already. And at Wathom Edge, we're already implementing that. You know, but currently this is one of the limitations, but I also want to point out that if you look at common server side languages like JavaScript, it's also single-threaded. It's just multi-task on a single thread, right? And the second is garbage collect languages. At this moment, I'm pleasantly surprised to see Fermion's presentation that said Java actually runs. And there's a way to get around the GC, because the short lived application, you don't need GC. And I thought that was very interesting. And then the third thing is that, that's what, to borrow our old industry term, is that it's an opinionated setup. So Wathom is that it needs something that you have to develop based on its ideas. So very much unlike Docker, that has been popular for a very long time. You can't just take a Linux application around Wathom, so you have to use a different set of tools that also give rise to the need for developer tools. So, I want to give you a quick demo that's to show you some of the things that we have done in the developer tooling area. So the application I want to show you is a microservice. You know, so if you look at, so it's written in Rust, if you look at this code, it's a Tokyo application. It's normally it will not compile to Wathom or you know, it will not run on Wathom. But I'll tell you in a minute how we did it. So make it run on Wathom. You know, so it's a Tokyo application that start up a web server that lessons at port 8080. So it's using the standard Tokyo MIO and HyperLibrary in Rust. And what it does is that when a request comes in, it asynchronously start a handler method called classify. You know, what it does is that does AI inference. It's called a TensorFlow model to look at the input image and then generate the output, right? You know, so it's what I just said. It's a single threaded but a multi-tasking. You know, it's utilized a non-blocking IO that's available in the system. So it's, you know, while the data comes in, it doesn't have to wait. It can handle the next request. And the classify method is not difficult either. If you are familiar with machine learning or AI inference on Python, you'll find it's very easy to follow even in the Rust language. So what it does is that it has a request body. Because it's a handler method, so it gives you the HTTP body. And then, you know, you are supposed to return the HTTP response, right? And so in the method, it's first load the TensorFlow model which is a mobile net is the image classification model. And then it gets the image from the, here it's a post classify. It gets the image itself from the HTTP body and then transform that into a tensor and then run the tensor model through the TensorFlow runtime which gets back another tensor. That tensor is a list of probabilities of different image labels of their probability in a file. Then you look up your English names for that label and then print it out. So that's all there to it. You know, that's an entire microservice that does AI inference on a very small device. So let's see it in action. So I'm going to do a live demo here. So let's see if it works. Although I did cheat a lot, cheat a little so that I cache the cargo build from last time. So if I do the cargo build, I can build this, yeah, so it's done. So because everything's up to date, right? So I can build this Rust application into Wasm. And then I use the Wasm Edge runtime. You know, Wasm Edge runtime supports the whole Wasm NN standards. So it does TensorFlow, PyTorch, OpenWin0, and all that. So if I run this, what it does is that it lessons on the port 8080, you know, that's, it starts the server inside Wasm. It's not a host function that embeds Wasm, but inside Wasm, it starts the server. And then on this side, on another terminal, I can query the server. I can send it a picture. Send it a picture and it would return immediately because this is done on native, you know, TensorFlow. So what it says is the pictures, there's a high confidence that the picture contains a military uniform. So what is that picture? You know, so that's the picture is someone, is something that everybody has seen in the past. You know, it's Dr. Grace Hopper, right? You know, she's, you know, in her US Navy uniform. So that's the entire demo for Wasm Edge. And so, let me, yeah. So just to summarize, you know, what is Wasm Edge? Wasm Edge is a Wasm runtime in CNCF. It's compliant with all the, I say, published Wasm standards, and it's also strived to implement a lot of those, you know, standards in the pipeline. And we very much would be loved to be part of the component, you know, model process, you know, to be one of the implementers in that space. And so, while we conform to all the Wasm standards, and I think one of the interesting that we do is that we are ALVN-based ALT, you know. So that's, that gives us, you know, there's lots of benchmarks that give us a near-native performance with, you know, you know, between the Wasm bytecode and the native application, compared from Rust. And we support a wide variety of OSs, including non-posec OSs, like CEL4, you know, it's a real-time operating system, widely used in drones and in autonomous vehicles. And it supports popular CPU architectures, like, you know, like RISC-5, right, you know, so. And then, we are, you know, our use case, we're especially optimized for the cloud and edge. So, like you have seen, you know, we have done, you know, a networking support through our VM, so that inside the VM, you can run asynchronous applications that has, you know, network capabilities, like Tokyo. Right, that's open store for connecting microservices, databases, you know, and other web services. And we also have a driver for Kafka queues and, you know, things like that. It works well with service frameworks like DAPR SDK, which I'm gonna talk about tomorrow in DAPRCon. And it has native support for AI inference, so if the underlying TensorFlow or PyTorch model runs on GPU or TPU, the Wasm runtime will be able to take advantage of that as well. And it has first-class support for JavaScript, you know, so we are striving to be full Node.js compatibility within this quarter, you know, so we have, you know, we have several developers that implement in the entire Node.js APIs, you know, our JavaScript interpreter. So I think that's, yeah. Okay, so I'll pick it up from here. Yeah, yeah, okay. Thank you, Michael. So, looking at the developer tooling for Wasm, it was brought up in one of the talks earlier today. It's not that easy to get things set up. Rust and Golang have made things a lot easier to do things like cross-compiles. I come from a C++ era where it was much darker and much more difficult than with those tools. But you still have a lot of those same problems of, I'm running Rust version of this, you're running Rust version of that, the CI is running some other Rust version, and then there's all the other tooling. You may have a different runtime like Wasm Edge set up. You may have testing tools or other things that you're using. And what that lands up meaning is you run into that same problem of, well, it works on my machine. I don't know why it's not working on yours or on CI, which as a developer really hurts me. I hate that. It also requires learning a lot of new tools and new flows. And I think, especially people like you who are on the leading edge of technologies, you're kind of used to playing in the tooling space and this is okay for you. But for developers who are nine to five developers working in companies, this is really, really painful. Each new tool that they get given is just extra overhead on top of their normal jobs and having to learn them is really hard for them. It slows them down and it frustrates them. So we talk about the magic of Docker and I think there are two core magics. The first one is what works on my machine, works on yours and then in production. If you use, the way that I use Docker now, I have many fewer instances where I have to do whip commits against the CI because if I have a Dockerized flow that I run locally and then on the CI, I'm sure it's gonna run the same. That magic is really, really profound. The second one is I can build things and then share them and you can build on top of them or I can consume things that you've built and this is that compounding effect that that isolation gives us, the ability to build on top of what others have done that makes our industry move so quickly and deliver so much value. The foundation of that in our, in the container ecosystem is images. So this ability to store things in OCI artifacts and then either consume them directly as a network service or to build on top of them. And the other magic of Docker is now that we've got millions of developers using it, there's a simple flow that developers already know. They really know how to do these commands and I would posit because you're tooling people mostly, you probably have all used these commands too and you probably are quite familiar with them. So this didn't happen by accident, right? The core thing behind the success of what runs on my machine, runs on yours, runs on CI, runs in production is standardization. The reason you can run a container on your desktop with Docker desktop, then in GitHub CI or GitHub Action CI and then on and deploy to ECS, AWS ECS is because of these runtime, the runtime specification, the image specification and the distribution specification. These are the core things that provide that magic. This doesn't happen by accident either. You can't just standardize a thing. You have to work in the open and I'm really encouraged to see what's happening with the bytecode alliance and other efforts inside the Wasm community. That really allows you to develop these open standards and collaborate not just within your company or your team but across companies and industries. This really is the rising tide lifts all boats and the reason the container ecosystem is so big is because of these open standards and because we can work across and not have one thing in any of these domains. On our side, we're using the OCI to do this mechanism which is kind of analogous, I guess, to some of the bytecode alliance pieces. So with that, I'm gonna swap laptops because I'm doing a live demo and we want to really tempt the, yay for live demos. I always appreciate them, so I feel like it's, I have to do it. All right, are we gonna get a, did that work? Not yet. It is working, yay, all righty. Yay for live demos. So what I'm gonna demo is I'm going to demo a technical preview of Docker desktop. I'll share links, don't worry, you'll be able to get it, which has WASI support built in. We're using WASIM edge through a container to be shown at the moment but that should be pluggable as well. I'll start with a Docker compose file here. I hope most of you are familiar with Docker compose but I have the canonical three service application. I have a client, a front-end JavaScript client, a server which is a Rust server compiled to WASI, WASIM 32 and then I have a DB, just a Maria DB because I couldn't get my SQL working on my M1 Mac I'm not sure why. So what this will do then is the server, the Rust server will write things to a DB and be able to query them and the GUI will be able to read them out and notice that two of the services are in containers and the one is a WASIM module. To build this, I have a Docker file and what this does is it cross-compile from my local architecture straight to WASI, WASIM 32. You'll also see here that I'm running WASIM edges AOT optimizations so we get much higher performance here and with Tokyo and coroutines, essentially we can handle many more requests in parallel and then speaking to Ralph earlier, this is you close your eyes but we're using a from scratch image and we're copying the WASIM results into that so we can reuse some of the OCI pieces. So what I'm gonna do is like a good cooking show, I've pre-baked this but I'll do a compose build and you'll see if it can resolve everything. Hopefully everything's cached, there we go and if I inspect this image, you'll see that it's got the architecture WASI, WASIM 32 and an OS WASI. This is just if I do a Docker images, you'll actually see it pop up so that you can see it's the WASIM day one or the server one, I've just re-tagged it and then of course if I do a Docker compose up, this would implicitly build it but otherwise it just launches everything for you so this is a flow that specifically front-end developers are very familiar with with Docker where you just do a Docker compose up, it builds everything it needs to build, it downloads all the images it needs and you've got something up and running. I'm gonna start up a second terminal here, hopefully it's not too big and I'm just gonna initialize this and then I'm going to upload a couple of orders so you can tell I'm a back-end engineer because this is my home and if I go over to here I can reload and this is querying that front-end service now so what's happening is I've queried the front-end service that's hitting the WASIM, the rest WASIM server which is querying the database and pulling things up and I can do operations here that kind of travel through as well so that's containers and WASIM sitting side-by-side kind of transparently actually which is, it seems like an anticlimactic demo but there you go, yeah. So here it is inside desktop as well, we also made it so you can see that this is a WASIM32 thing that's running and notice that the networking is working as well just as it does with Compose and of course I pushed this earlier to Docker Hub so you can see up here we have it up on a demo repo, right? I'm gonna pull it back to the slides so what we've done here then is we've got the same workflow that a lot of developers who use containers today already know, this Docker Compose up and then you're just going, some of them will do Docker build, some of them will do Docker push as well but they've got the same flow that they've used for containers before but this time they're using WASIM. We output an OCI image and because we output an OCI image we can reuse OCI compliant registries and this is great because having worked with teams who run registries it's less fun than it sounds and it's reusing what we have is really valuable. The other thing is because of the WASI runtime standard we can then take that and run it, take that image and run it on a WASI runtime. In this case we used WASIM Edge but there's no reason you couldn't use any WASI compatible runtime. All of this is built into Docker Desktop and we have millions of developers who use Docker Desktop so this means that they would just have this have this right there for them to use and the interoperability with containers I think is an important piece too because like VMs haven't been displaced by containers and containers are not gonna be displaced by WASIM and we need an interop story. You need to use the right tool for the job and in a lot of cases for example you'll have existing web services or a DB and so what you wanna be able to do is interface with them. So what's next? Well, we're just getting started. Docker is new to the WASIM space and we realize that we wanna work with the WASIM community. We really do wanna do this in a collaborative fashion and we wanna share our experience from the container ecosystem. We've learned a lot over the last several years and we wanna bring this to help bring WASIM to more people and I think some of you may have already seen the blog post but we're actually joining the bytecode alliance as well so we can help do that formally. Of course it also wouldn't be a WASIM speech if I didn't show you Solomon's tweet which is notorious in your circles. So I think people as Justin pointed out in the keynote people kind of misinterpreted this and I feel like we really are coming full circle with what I demoed today. In that second tweet where he says, imagine a future where Docker runs Linux containers, Windows containers and WASIM containers side by side. Well, that's exactly what we've demoed today. So I know you're all most, well most of you are probably engineers. You wanna get the code. I've got a QR code you can scan there otherwise you can look at my GitHub repo. I've got links to the versions of Docker desktop and some demo repos that were provided by Michael's team as well so you can just Docker compose up and to play around. Right, thanks everyone. Thank you. Questions. I've got stickers. What is, I have stickers. Well, it just means that questions may prompt stickers. No, I'll give stickers as well. Reminder anyone at home, you can ask your question in the web serverly channel and we can relay it here. So admittedly this question was in the Slack from Brooks so I'm taking inspiration from him but how would you compare and contrast the current WASM movement with the early days of Docker and Linux containers? Oh, wow. Nice, nice, a soft level. I think some of the, I wasn't there for the very beginning so I don't have a strong story to tell there but I think the things that I'm seeing on the WASM side is a lot of these initial settling we saw where we were trying to work out what standards matter, which things need to be standardized, which things, where should people differentiate, where should companies differentiate, all of that sort of stuff. I'm seeing those sorts of analogies happening and that's was why I kind of called out the OCI work where we've done where think about, think about how do we build an end-to-end story because I think that we need to find killer, we need to find a couple of killer use cases that are end-to-end so developers can really start adopting WASM. Right now it still feels quite fragmented which makes it really difficult for people to adopt. There are, obviously there are people who are using it in production in various different cases but there's no mass market easy way of doing that and Scott's gonna have to cover his ears but I think because you could throw process as existing binaries into Docker containers and they were just better just doing that, that kind of helped us as well because there's a lot of brownfield software out there and helping people get that running, putting that inside a container was net better than running it on a host and that kind of removed some of the friction for getting people to have an end-to-end flow that was better than what they had before so I think that would be the thing that I would focus on with WASM now. Chris, Sven in the Slack, so everybody who wants to ask questions of Slack feel free is asking how does Docker know when to run a WASM runtime? So right now it's configured inside my compose file and let me just hide this. Come on, there we go. I've configured it inside my compose file to make it explicit to show that I want to use a container D-shim so what's happening here is the Docker engine is it runs things through container D and container D you can have different shims for doing different types of workloads. In this case we have a WASM edge shim and so I've told it please run it with a WASM edge shim. Ideally what we're talking about with the Moby maintainers because the Docker engine is part of the Moby project and that's an open source community that we work with Marantys and Microsoft and some others on. What we'd like to do is have some auto detection where based on the architecture type it would just do the right thing. You'd probably want to make it configurable for users to choose exactly which backend they want to run because there may be people who want to use some of the bleeding edge stuff with WASM edge or other people who may want to use a different runtime for other reasons. I can repeat the question as well, yeah. Yeah, so the question was you now have Docker with WASM does that mean we're part of the Kubernetes ecosystem and to clarify that? So the way we've integrated this is through Container D which is a low level piece for managing how it works with containers is it manages the process life cycle and setting up namespaces and things like that. Kubernetes is a layer on top to orchestrate those containers and so because we've integrated at the lower level this should just work with Kubernetes as well. I think Ralph may be talking about that a little later so I would stick around. Yeah, but this is the advantage of building in at that level, right? We can re-leverage things that already exist. I think reinventing the wheel for the sake of it is unless you're getting really great benefits it's not worthwhile a lot of the time. Any other questions? All right, please join me in thanking Michael and Chris. Thank you.