 Welcome everyone good to see you here We've we've come from Europe. So we're both jet lags. Yeah, excuse us. It's better today, but I don't know it's worse today I'm Justin Comac. I'm the CCR Docker Yeah, so I'm Michael. I'm part of the was something at being where AI labs so You're really one Yes Yeah, I think I can start with this one So one of the things that I usually like to say is that containers change the way we develop Distribute and deploy applications So I remember when I joined my first company that the first step that I had to do was to Install everything my laptop so I had to download the language runtimes for the application Download that my sequel database install all the data that they wanted to use to start actually coding for the project that I was Working for the thing is that As you may imagine Everyone has their own version of the environments We have differences on the application on the runtimes version different data different databases So it turned out that it was a complex environment because this is where I really learned the phrase It works on my machine basically so everyone was having different things We were funding some issues and it was complex thing to manage and everyone that's joined the company had to go through the same process And it was difficult also to keep everything up to date And if you mix the production environment into this equation This can be really really difficult So it was until the point in which we started learning more about containers when we started changing things So instead of having to download and install all the things in your order tools in your laptop You can just download the Docker compose file You can start building your application and you can start coding in just a few hours instead of after one day So setting this this context I Read about this specific tweets from Solomon Hikes, which is one of the Docker founders I think some of you are familiar with this. I think you are very familiar with this I was I was sitting next to Solomon when he write this tweet. We were actually It was actually just when wazzy came out and we were experimenting with Incorporating wasm into docker-build and working out what multi-arch looked like for wasm and some of the things that We're going to talk about later on today We were experimenting with early versions of that because it was kind of exciting But it was also back then kind of difficult as well But I think the the kind of the sort of aha moment that Solomon had at the time was really about These things are very similar in a lot of ways It's about packaging a set of code together into one thing that you can run that's repeatable It's portable. It runs anywhere and you know that kind of it You know repeatability you're talking about it runs on my laptop. It runs in production very much the same There's a security boundary around wasm that's very similar to the one around container I mean it's architecturally it's very different But it gives that security isolation in the same way So there's a lot of similarities and so that's kind of where that you know that kind of thinking about You know They they they fulfill a lot of the same roles and they fulfill a lot of the same purposes and they're kind of interchangeable in that way And that's really what we're going to carry on, you know, you know this is kind of carried us through in terms of talking about You know having this having this doing wasm with docker today and interchangeability Yeah And then at that time I wasn't aware of the web assembly consisting at all It was something as you were mentioning it was something new and fresh So that was I was excited and if containers change the way I develop and deploy applications What's was and how can it helps me to continue improving and actually running the applications together? So here we have two new concepts at least that time which was web assembly and wasi We're going to do just a very brief introduction about these concepts. I think we are in was and come I think you all are pretty familiar with what assembly, but yes, let's use the people on the recording might not be safe Melia That's true. So yeah, it's good that we a little bit of introduction here So basically web assembly is an opening standard that defines a binary instruction format It means that you can take code like in cc plus plus rest and instead of targeting and operating Specific operating system architecture. You are targeting web assembly This models which contains all the source code of the application you are building can run on top of our assembly runtime or virtual machine depends how you call it but still thinking about the similarities that that Justing was talking about Containers you still have one missing piece which is okay. We have Three we have a web assembly model running in a runtime, but it's fully isolated How can I reach the same? Resources that you can do you can reach with a container and this is basically about wasi So was this is the other portion of that of that to it So it's a standard to access system resources or access System resources on the server level so it provides low-level APIs for accessing things like file system sockets and environment variables Because with a container those were provided by the kernel API is which was kind of you know, that was the system API What was basically the kernel API for containers, which is how have they got that possibility? Exactly You have that a bilo by the default because the way that containers work But in web assembly you don't have that information by default because the model are fully isolated So you have all those resources and the way you access them is using wasi Which is a set of API's that allows your web assembly model to for example read the file in the system access sockets and environment variables So now that we have both things the good thing is that thinking about containers and with assembly They are not mutually exclusive technologies You can use both to get all their benefits together and this is why we are here today to show you how to do it So yeah, so let's let's talk about web assembly and containers So both of them are really you know a sandbox to run portable applications But just the portability kind of is a little bit different and the sandbox is a little bit different you know as we talked about that with Containers the the output the IO layer is the is the kernel interface with web assembly has to be specifically defined And it's more structured the sandbox is namespace isolation versus the sandbox being the You know they're kind of the browser model of runtime isolation and lack of any way to get outside without a controlled interface Web assembly at the moment, you know, this is a is a single binary But we're moving into a component model where you can actually connect these together and have multiple multiple components making up an application with containers, you know, you have an image Historically part of the uniformity of containers was because for many of the years There was really a it was a Linux AMD 64, you know kind of uniform ecosystem So there wasn't really a portability question. We that's changed in the last few years I mean we've had windows containers for a while But no arm 64 is a is a real platform with a real market share now and portability is Much more of an issue and now and so with containers you have to basically compile multiple Images bundle them together so you can run on different architectures web assembly is portable by design coming out of its browser Heritage browsers were always portable and and so and the web assembly, you know virtual machine is designed To be you know jet compiled and so on so it's already portable Obviously from the ecosystem point of view, they're very different containers have been around for a long time There's a huge ecosystem and they're because they're just Linux applications ginger and all like they You can use existing applications kind of unmodified because there's already applications for Linux whereas web assembly with wazzy you have to work at how to compile the interfaces into into the wazzy piece and there's been a lot of work, but There's there's there's impedance mismatch between existing applications. So there's there's work There's lots and lots of ongoing work as I'm sure you've been hearing about About how that works and how that can be made better Yeah, and actually one of the things that I found quite interesting is that As you mentioned like at the beginning Linux and the 64 seems to suit all the use cases that people had at that time But over the time new devices come up new architectures. You know is exactly so for example I remember that for me Linux in the 64 was super good for almost everything But then I wanted to have my own personal server at home and I use others very buy But now that's not enough now I need to find images that includes the air and version that I want to run for that So it was not easy to to make that that portability But you still have all those all that well established ecosystem with all the applications So you can basically just install docker or any container runtime and then you get access directly to a lot of applications that you can run so You know We've had this kind of history with docker of working with wasm being excited by wasm and You know one of the things we wanted to do was make an incremental path for existing docker users and existing People you know to have a path to wasm that just is kind of feels natural and incremental to them and that they can gradually move, you know parts of applications or some some piece of their application where it's appropriate where it works well into wasm and you know Basically you kind of mix and match these technologies as they as they need so they can they can learn They can experiment and they can work out which things are Effective and working and work out like you know as the ecosystem evolves we can evolve with them and help them do this So that was our our aim in trying to ship wasm stuff with docker kind of early as well It's the fact that we felt that the models in many ways even though there's lots of differences in many conceptual ways They're very similar Yeah, and we are going to demonstrate that that with docker You can actually integrate those together using the same experience that you are used to do with with containers So here I have to demo. Okay. It's looks okay. I don't know why I have a key there, but I think it's fine. So, yeah, so the first thing that we are going to do is to check How you can actually create your first container with WebAssembly? So for that I'm going to take a very basic RAS application, which if we see the source code is just a hello world So we are going to compile this we are going to build the container and we are going to run it with with docker so in this specific case the only thing that you need to do is to compile it to the To WebAssembly in this case I am using wassum32 the wassie So I get all those access to the resources in this case. They are not required at all But it's good that that we have well, I mean this case Yeah, we are using the the STD the STDI for for showing that the print statement. So we actually need it so After this compilation we have already our RAS model there. So we can start using it directly if we use it using a WebAssembly runtime like wassum32 or wassum32, we can run it directly, but let's see how we can do it with docker so For the docker file, it's pretty similar about what you are used to do with with docker You have a front in this case You don't need any base operating system because as a WebAssembly container You don't have the operating system layer. You can just start from scratch The only thing that you need to do is actually copy the model that you want to put there and use it as an entry point This is something actually that changed lately. So you need to give it like the full path instead of a relative path Having this you only need to build it using build x. I'm setting up the platform to wassum and then I'm giving it name compiles And we get the image So now the same way that you are running containers with docker ram you can do it with with wassum containers The only change that it applies that you need to use the runtime that you want to use in this case Which is wassum time There are all the runtimes that you can use like wassum edge and different ones and then the platform that you want to use Just to target the right container that you just created and the name And it works. So you have already your first Container base based on Rust and WebAssembly But that's not all and one thing that I found quite interesting is that There are already things that you can run using WebAssembly containers and you can put together So let's compare for example, how do you run a Python script using a WebAssembly container and at the full container So here we have a simple script Pretty similar to the Rust project and I wasn't very creative that day So we are just printing the hello from and then we are putting here the platform just to see the differences between containers and WebAssembly So I'm going to run this first using the the Python 3.11 alpine image. So yeah, I'm both Python. I pass my my My script after mounting it using the dash B option Yeah, I got it as expected. Hello for Linux And the same thing we can do it using WebAssembly because the same way that you publish Containers into the into the Docker Hub or any other registered that you have registries using regular containers You can manage WebAssembly as a different platform. And in this case we from from being were a labs We publish different Interpreted languages like Python Ruby and PHP ready to use as WebAssembly containers So here I'm using exact the same version of the of the Container that I ran before in this case I don't pass the the binary because we are running it directly And I just pass the argument with the with the script that I want to run And it also works. You're using almost the same exact experience. You just need to set the right runtime to use and then you can run it And it's it's easy the same way that you are doing before But there is still one thing that I want to show you that I found Fascinating about WebAssembly and is that if we do Docker images GERP, this is not going to work. So Let's do Docker images if we check The two containers that we just run There is a big difference. So on the Python even though we are using the alpine version It's 86 megabyte while Using the Python was some version you get it to 28 and this is what we are going to talk later on about more about this so The thing is how it works. Yes, so in order to kind of understand how it kind of helps to understand a little bit about how How the Docker ecosystem is structured? So originally docker was just this Back in the early days docker was just this monolithic engine that just ran stuff. But over over the years particularly as we've split things into CNCF projects that are multifunctional Docker's been split into layers. So there's There's the container the layer in the middle which was designed around a joint project with Google to run Both in docker and in Kubernetes originally that was that was the aim and then underneath There's the actual run times and so what we've what we've done with wasm was we've kept some of those layers and then we've inserted Inserted adapters to run wasm in the in the places kind of in this hierarchy. So and so Underneath the container D there's a there's a shim API which is Actually was a kind of interesting one because it was not originally designed as a sort of public API But it was really a convenient API to use to Interpose other things into how things run so it became actually a really popular extension point and so that's where the wasm shim or the container D shim for For normal containers sets that runs You know runcy normally to run docker containers or you can stick all the All the different wasm run times each each plug into that layer But from the you know kind of abstracted by the container D wasm shim project that understands them So there's a there's a there's a kind of exact kind of matched structure There are some things that will change over time for example at the moment Content is you know, essentially a Linux project, but there's no it almost works on other Operating systems. It almost works on Mac. I submit a bunch of time Porting it so we can do things like actually run all this stuff natively on On any hacks because wasms portable in the way that the runcy and this stuff requires Linux because it's a less container run time So there's there's lots of opportunities where you can modify this architecture and do new things with it because wasms Different but it gives you that same plug ability and later on we'll talk about how you can do exactly the same thing in Kubernetes for example exactly and In terms of the images, um, you know Wasm is smaller. That's one of the things that you know people have Talked about as one of the advantages for a long time a lot of it is because you know we As we talked about with wasm you can do from scratch because it doesn't have all the pieces the operating system pieces You can run containers from scratch, but a lot of them are not designed and don't work with that because they require system components, and I think that you know When you're in an operating system environment, you tend to make assumptions about what you can use and your applications tend to Well, just shell out to do this and things like that. There are disadvantages in doing that and lots of ecosystems have kind of Tried to reduce the number of times you have to do that And like I think Python is one of the more closely tied to the kind of the Linux environment, whereas the JVM languages tend to use more native code that So there's probably less difference between the sort of WebAssembly version of a Java app than there is with a with a Linux version, but You know these you know these these differences are kind of real and and part of the thing is also you're forced if you We use WebAssembly not to shell out because there isn't a shell running So you've got to actually, you know, make sure your application doesn't how I use these features So so there's work on you as a user To kind of fit with how the environment works. So so there's you know, again, it's part of the It's part of the work you have to do to put your application, but you also end up with a much more tightly defined Application that you know more, you know, it's got a clearer security boundary. It's not So there's lots of this pros and cons either way Yeah, and the good thing that we were talking before you can use both on the case is that makes more sense for you So that's that's a good. That's a good point So but one of the things that that we would like to also get a bit into more into details Is how the shims work actually because when we talk about shims We are talking about a compatibility layer between what container they invoke and saying all the commands everything That you need to do to spawn the application on the world of that you want to run and then it goes directly to the Weapons in the runtime that you want to choose for now. We have wasn't it was in time But there are more rankings around that you can actually implement so If we think about those there are many different things that all the runtimes have to implement So for example, they need to subscribe to the container the life cycle spam processes stop Then interact with OCI resources manage is TDI everything needs to be done What's an edge in what's on time and in any other runtime that that wants to be integrated with this So why not to create something common and this is the room was a project So the run was a project is a library that allows you to create this kind of shims and has trapped you to From many of the different common functionalities that you need to implement on those So basically run was is sets between container D and your application framework I will talk a little bit more about that under runtime that works underneath like was an edge was on time so Currently what we showed was Web assembly runtimes directly like Modules that can run inside those runtimes are basically web as pure web assembly models. You don't have any extra Feature on top of that But there are application frameworks that gives you more features like adding things like key value stores Routing stuff on things like that. So those frameworks are also available in container. They are shims So those one the ones that I think we have now are spider lining from Microsoft spin from fermion They have a workshop this morning at different talks and we have was on worker server from from being where so as you mentioned Like it was it wasn't designed for that But it was pretty cool how you can extend the container the capabilities using this this shims API and also run was it to quickly create this shims together So here you have also the the different repositories that you can check for this and Coming back to the to the to the architecture that we had Before we see that we have the Docker engine best best as you were mentioning before Is this something that it's just for docker or this is something that we can actually Reproduce in other in other environments and one would example is Kubernetes Since the Kubernetes environment heavily relies on containers, but it's that something that we can actually change why not Getting the same benefits that we are doing with docker containers and web assembly also in Kubernetes And the good thing is that we are already all the work done because if we if we run a cluster that based on container They for running the workers Sorry for running the workloads you can run also the the different shims like the web assembly close to the container shims So what it's required actually to to get this work together So the same the same approaches you are following for for containers in your laptop using docker You can reproduce that in Kubernetes So you only need those shims together with the shims that you already have for running containers And then you are able to run with assembly models on top of that, but In this specific environment is not that easy because as we see here This is a pretty small cluster We only have three nodes and you have to install all these manually It may get a little bit complex and you need to keep everything up to date So it's not an easy task for for administrators So One of the projects that simplifies this is kwasn So kwasn is a Kubernetes operator that loads and downloads all the web assembly Runtimes installed them directly in the different Kubernetes nodes Allowing you to start running it just by Adding this help repository installing the operator and then you annotate the nodes So all the nodes that you annotate with this kwasn will automatically Download all the shims and we configure container before you So after running this three commands, you can start creating pots that relies on web assembly models And start getting the advantage of both worlds in your Kubernetes clusters So yeah, so We won't really explain to you that like kwasn when kwasn when containers of technologies that work together They have a share a lot of similarities from a developer point of view. They can be very very similar You can Incrementally move applications without having to kind of totally rewrite the world With Docker, we really wanted to Support this incremental way so that you can just you know, anyone can come along learn about wasm start using wasm It's a it's a great place to like If you're a if you're you know, if you want to help people use wasm It's a it's a good starting point for them. It's they have the similarities with The existing ecosystem and as you can see the tooling has similarities with the existing ecosystem as well It's we're not rewriting the world to do this We're just incrementally swapping out the bits where we made the ecosystem pluggable And that's why it also works And exactly the same way with Kubernetes because that's part of that same ecosystem as standards We're using that, you know, the same registries the same ACI formats the same Container D and the same shims and I say it's a very, you know It's very incremental approach to introducing wasm into people's into people's lives so they can kind of explore how it works to understand You know what the you know, how they actually go through the process of building wasm applications how it actually works And so it really is a kind of bridge on into the wasm world for people who are You know used to building things with containers and you know, particularly people who come from this is our native world or You know using using containers in that day-to-day develop and it's very incremental approach And we think that incrementalism is is really important I think there was a kind of view with some people that wasm was like like a whole new thing We're gonna throw everything away, but um, you know, I think we've learned a lot of things with Containers that are valuable about how to deploy applications Immutable applications repeatedly deployed at scale is a really important pattern. There's lots of tools around containers for security and signing and you know Managing registries and there's a whole sort of long large scale infrastructure with Kubernetes That's everywhere in the world easily available And so you don't have to completely change the world throw things away To to work with wasm and you can you can do it in a more incremental way Yeah, and there will be things that won't change actually because for example, even though we are showing Like basic examples like the rust example or the Python script if you are creating applications that are more complete You will need things like a database you will need things as a key value stored that has persistence So those applications are actually already implemented and you want to reuse them You don't want to implement those in WebAssembly directly. So You can use the tools like Docker compose for example You can use the same one you can put your services You can set up my SQL database and then you can you can set up a WebAssembly model that runs queries Against that specific database. So that's the good thing that combining both you get all the different worlds together and you can Run more complex applications and more interesting things you can explore you can try you can experiment and you can run actually because In the end if we have the same Isn't architecture in environments like Kubernetes It means that you can actually put that in production and start serving a specific request and providing value to your users Yeah I mean I remember again back back when we were in 2019 when we were the first experimenting it was very It was very daunting because you kind of felt you had to do Everything in WebAssembly back then and it was like it was gonna be hard But he was spent all your time trying to fix problems with Building things and making things work and it was like really really difficult and it felt like you know They felt like there was a really big journey to get anything done whereas now you can find you can find bits that work and Build on those and build out more over time Yeah So yeah, we have here kind of a summary with all the links for the different projects that we were mentioning So the good thing is that you can start using today You can go to desktop was some documentation to start getting into Docker You can download the the different things you have examples there to create applications around the containers You have also the Ranguasi Container V was machines projects which have more information about how they are built and they are pretty active in the community and the CNCF community We have conversations now around OCI artifacts how they should manage WebAssembly workloads there How you are going to actually create was on containers and what are the shape the different features that all the different Runtime should follow so those kind of conversations are happening And I recommend you that if you like this ecosystem You are interested in that you join those channels and start following the conversations And we we're keeping things up to date We've we've added a lot of different gems for example, so you can try you know everything You know try spin try other things so you can try and Play around with the different parts of the ecosystem to learn about how they work really simply as well And then we we're carrying on you know growing with with the ecosystem and working out You know so if you've got things that you want to see Support it if you've got ideas. We're really open to listening and helping Helping people learn helping support your projects in wasm whatever it is that you want to do. We're very happy to do that It's it's a product that you know part of the community. Yeah So yeah, that was all that we have for for this talk. Thank you very much for attending it We have a few minutes questions I think Yeah, so I think we have three minutes, so I think we have time for some questions Okay. Yeah, so let me go back to that slide Actually, yeah, yeah, actually it wasn't there. It wasn't yeah. Yeah, it was okay here We have them. Yeah, so the question is about the different flags that we were using for docking round What they mean and how they actually connect to to run a web assembly mobile so the first thing that we have is the runtime which is basically selecting what's the Identifier for the container the shim that will run this specific application So when you when you run with with this Specific flag and by default using docker desktop You are not installing or only was sometime which is the one that I use in the examples But you are getting for example was an edge and if you install them with k wasm in Kubernetes you will get was sometime was an edge spin WWS and then your application may want to target one specific Runtime so this is the reason of that specific plan to specify the one that you want to target because for was something and was an edge They are pretty pretty similar, but for others like application frameworks. There are many differences. So that's the way you target it Yeah I mean, I think it's partly you know a function of you know the ecosystem is experimenting with lots of different things and different So I think if in future we would like to make this more automated to work out which one you need and add metadata into the build so that a lot of the stuff goes away You know so I think that you know some of this is just kind of temporary things we should be able to work out If you put if you If you build the container where you shouldn't need the most most platform Yeah, necessarily if it's if the containers built with the right metadata and things So I think that you know some of it's some of its temporary Temporary line noise, which will hopefully go away Yeah, yeah platforms detectable from the from the image metadata I mean One of the things that you know made Docker successful was the huge ecosystem built around standards and I think that web assembly Does come from this very much comes from A community that respects and really value standard. So I think they've kind of learned that lesson that you know The standards kind of it in the Docker ecosystem came out a little bit later And they were kind of driven they were more standard standardizing what had been built rather than starting with standards But it's a bit, you know kind of different approach, but I think there's You need standards to make an ecosystem big. I think that I'm you know, you also need you know Developer experience that's that's easy as well. I think that You know, there's still There's still work to do in just terms of making things just work. It's getting way better And supporting, you know, it's fully multiple languages and things is way better than it was a few years ago And it's we're getting much newer. They're just works Situation which I think is also really important because people get really frustrated if they get stuck in things That are just hard to fix and they don't understand because they would just want to, you know Run their application and it doesn't work. So I think there's a there's still work to do there But it's way better than it was I think we're still I think We still haven't Shown people what the what the compelling value for them as developer of using wasm is there's a there's a lot of excitement around it, you know Some of the things about it, but we don't kind of know which things are more important I think that With containers it took a long time to work out which were the actually the valuable the most valuable bits There was a lot of discussion about like for many years about containers versus VMs And that wasn't the interesting thing about containers was how they compared to VMs It was what the kind of workflows they enabled, you know That the kind of whole cloud native development the whole scalability the repeatability reproducibility those things were the things that actually were valuable in the end and Actually things like this the security boundary of containers was Less, you know, there was a lot of content, you know, how how strong was it was as strong as a VM The answer was no, but it didn't matter, you know So I think the the different kind of nuances take a long time to kind of feed into What can I do that's different and amazing what what what is this ecosystem doing for me? And I think we're still in the learning phase with WebAssembly about which things are going to be important and which things are Less important and which things people are gonna get really excited by so I think there's still a lot of experimentation and Kind of and learning and and building needed to find those things Was that philosophical enough answer? I think we're holding it away from refreshments, so yeah, yeah, thank you. Thank you very much