 Hey everybody, welcome to Wasm Day. I'm so pumped to be here. The first time I ever spoke at a conference was actually Wasm Day in LA, so it's really special to me to be back here. I'm Bailey Hayes. I am the CTO at Cosmonic. I also serve as the Waze Co-Chair for the W3C's community group. I'm also on the technical steering committee of the Bike Code Alliance, but today I want to talk about whether or not this moment in time right now is the Docker moment for WebAssembly. And you might be thinking, did Liam write that? And the answer is maybe. He asked me this question at the end of my last talk, and it's been an earworm, and it's really stuck in my mind, and I think that it's worth talking about because there are a lot of aspects here that are really important, and there are a lot of similar parallels. The early days of the cloud native age, we were really inspired by the paper around Borg, but in reality, there were many different innovations that happened over a decade that made us have this massive moment in time where you saw a lot of the infrastructure and everything come together and sort of revolve around this one concept of a container. And that's, I think, because the future is often already here. It just isn't evenly distributed. So, not one place, not one time, not one company, but many different innovators working together to find the right abstraction. And when I kind of think about how software development works as an industry, it's really the world's largest, most complex multiplayer sport. And sometimes it looks like this, where it's maybe a little bit more complicated than you would want it to be, and maybe somebody introduces a new technique and everybody adopts it, but it might be complicated. But in reality, that's how we're so successful. That's how we keep raising the bar. And because we're in Paris and the Olympics are coming, that maybe you think of this one example that happened in the 1968 Summer Olympics. And that's when Dick Fosbury showed, on the world stage, the Fosbury flop. But the Fosbury flop actually had been around. It had shown up in some different competitions, but it wasn't until a lot of people saw this and had their aha moment that this is something that we could do to really raise the bar of our level of competition. What I really like about the Fosbury flop's Wikipedia page, because I had to go look it up, is that there were many different techniques that were in use at the time. And to me, that seemed a whole lot like the way that we were doing lots of different virtualization technologies in the 2000s and 2010s. I'll name a few of them. That's the straddle technique, the western roll, and the eastern cutoff, or the scissors jump. So if it feels like sometimes when we're looking across our landscape of a lot of different ways to do and ship software, turns out that applies to just about everything. And so I really loved that analogy. So new techniques obviously will unlock new levels of play both in software and maybe in the Olympics. But what I think for us, the most important concept to keep in mind is what Thomas Kuhn said in his book for the structure of scientific revolutions. And it's that he described a moment of innovation where suddenly the world seems to be different, and that is a paradigm shift. And I believe that the paradigm shift for us is happening right now, and it's around WebAssembly components and with the launch of Wazzy.2. And a few reasons, but I'll only name a few because you've got the rest of the day. It's because things are now language interoperable so that I can take two components written in two totally different languages and have them talk to each other. And the way that I do that is with interfaces. And what I really love about these interfaces, and I'm going to hit it a little bit more later, is that they're strictly defined, they're semantic. I can pass in high level types, but I can also do that in a way that lets me bring it across all of these language barriers. So that is all defined over this IDL called wit. Now this next slide you may have seen before, but I can't give a talk with this title without at least addressing it, which is Solomon Hikes who was one of the founders of Docker. He said that if Wazzy existed in 2008, we wouldn't have a need to create Docker. I totally agree. But we did create Docker, right? We've been building at it. We're at CNCF, we're at cloud native. So does that mean that components are irrelevant? Or is this really talking about that period of evolution that happens with technology and that maybe we're finally hitting that moment, that paradigm shift? And the reason why I believe it's important and why we need to rally around it now is that the reality is that the way that we build software is broken. I said that building software is the world's largest multiplayer sport, but if it's a multiplayer sport, we're not exactly playing it the best because we're making really tiny little teams. Our court is filled with spikes and barriers and all kinds of stuff that keeps us from working together. And one of those examples is the way that we build up language silos, where if I'm coding and go and my friend Taylor is coding in Rust, it's not really convenient or idiomatic to be able to collaborate on sharing libraries, sharing code. The way that we do that today is maybe we instantiate an API in front of our code. We put maybe HTTP in front of it and we sort of force everything through this one API style. But when you actually look at it, you're like, wait, hold on. It's not just languages. It's our package managers. It's all the frameworks and libraries. Are you using Tokyo and Rust or are you using a different version of Async? That's one example. Maybe it even eliminates the types of platforms that you're able to run on. And even if you just say, oh, just put an API on it, it's so easy. It's fine. Well, you know, hey, are you using GRPC or are you using REST? Are you following a standard for your REST APIs? It gets complicated. And if you're looking at this slide and you're thinking like, whoa, that's just like a lot of stuff that feels really stressful. You really cluttered that slide. Well, to me, I did that on purpose because that's how I feel the current landscape of software development is today. And if we go back to something that I think a lot of us have really internalized for how to solve this problem, because we've been grappling with it for a long time, in the UNIX philosophy, there are three key tenets. And if you write software according to those tenets, you are probably finding a really great way to build software that is multiplayer. And that is write programs that do one thing and do it well, write programs that work well together. And this last one is the only one I have a little bit of a quibble with. And it is write programs to handle text, streams, S streams, because that's the universal interface. And so somewhat similar to how we have all of our microservices today forced through one type of approximation of your API. You're kind of like shoving a square peg in a round hole. I feel that that's sort of the same idea here where we are saying everything just needs to be text according to the UNIX philosophy. But like I just said, we are building our microservices not exactly like the UNIX philosophy. And I wonder, you know, hey, why? And I need to shout out. Like UNIX is amazing. It works great. But when we are looking at software that we are building today, you know, we have learned that we need APIs that are versioned. We need semantic information about the different calls that we are making and it is the only way to write maintainable and scalable software. So how do we get to that? Well, you can probably guess what I am going to say. It is obviously to me the WebAssembly component model. Because with the component model, you are able to write things that do one thing and does it really well. Not just like really well. I think in the limit, we are going to see certain components that are literally the best component. Because it is the fastest. It is the smallest. It has the best API. It won't matter what language it is written in other than maybe the languages that are extremely performant have a tiny footprint are probably going to be the ones that everybody revolves around. But what we are going to be able to do is have components that can slot into any application that solves the problem better than anything else. And it is going to be very tiny, very isolated to the specific problem domain that it is trying to solve. And so our applications will combine all of these. Now, the second part, because we are trying to solve for the world's largest multiplayer sport, let's make sure that we write programs that work well together. And clearly, being able to compose components that are able to run together is incredibly important for that goal. And so if we look at, you know, I am not necessarily knocking the problem of having to run over a transport. But to me, the problem is that I am not able to today say exactly what this program is going to do and how I can consume that information. The API is not enough. And the reason why I say that is if I look at the way that I deploy my microservices today and I put an API in front of it, it is going to take maybe several milliseconds to call. Even on the same network, that is pretty fast. But because components isolate the memory, so when I compose two components together, and let's say they are using the exact same environment variables, I don't know if you have ever had this happen to you, it definitely has happened to me where I was trying to set some port. It had the, you know, everybody exposed the environment variable port. And then when I was using a third-party library, you know, who gets the port and how do I map it to the right thing? That's really a knowing part of it. I guess another example would be let's say you're using a Python library, you're pulling in a bunch of stuff. And then at some point, somebody clobbers your module. That can happen, especially when you're pulling in third-party libraries. So by taking the superpower of WebAssembly, of being able to create a sandbox that completely isolates that module, I have separate linear memories for each one. And that allows me to make programs that work so well together that they're able to run in the exact same process. And I'm able to call from one component to another in nanoseconds. Now this last one is that third point of the UNIX philosophy that I had a little bit of an issue with. And that's, I agree, we have to have a universal interface. But to me, the universal interface is wit, the WebAssembly interface types. And that's something that we standardized around with Wazzy.2. And we launched it with two different worlds. Inside those worlds, you can think of it as targeting a specific environment. The Wazzy CLI world is the one that's very similar to what we had originally released in 2019 with Wazzy preview one. And that basically gives you a lot of the things that you need to run as a CLI. It's even called Wazzy colon CLI as the package. It gives you things like a file system, being able to talk to standard in, standard out. And you're able to run it kind of like you would run any other CLI. You can embed Wazzy and do it. Or you can use Wazzy CLI directly and say Wazzy run. But there's this other world that's pretty different actually from the Wazzy CLI world. And that's Wazzy HDP proxy. And that allows us to write to a different abstraction. It doesn't pull in sockets. It actually is completely isolated to just HDP interfaces. That's what that component, if it targets that world, it says, hey, I export an incoming handler. That's the way that you can call me. And I only speak HDP. I love that. I kind of knocked HDP a little bit earlier. If you thought I did, I wasn't. What I was saying is that let's be really clear about what these components are building, what they're targeting, and what their lingua franca is. And so you're able to pass in basically these high level types. And to open up the hood a little bit and look at what that is, this is an example of what a component looks like rendering with WAD. It's got some interesting things, but my favorite here is to always highlight that this whole thing, this new WebAssembly component model, it's all still based on the WebAssembly core specification. Underneath, you still see I32s as far as the I can see. That's the original types that you worked with. I remember writing some of my own bindings to kind of like shove a string in from JavaScript into my C++ was a module. So I was personally very excited to have these top level interfaces. In this case, this is kind of like if I had targeted the Wazzy CLI run, Wazzy CLI command world, it would export this run function that now anything that wants to work with me knows that's what I do. I run. That's it. Just once. You can't call me again. And not only that, but I need an environment that's kind of specific for me to be able to run. And that's with my imports. And that's really powerful. Now, if that is where we are with the component model, that does not answer at all how this could possibly be the Docker moment. Because there have been many other abstractions that are really similar to this. I get asked a lot. Didn't Java do this? Didn't Com do this? Didn't Cobra do this? Lots and lots and lots. But the reality is that lots of innovators come together and we keep iterating. And we keep working together until we build the next abstraction. And to me, that's really why Docker was so widely successful is that it had this amazing community. When I realized that there was such a thing as a Docker moment, for me personally was when I went to my local meetup and we had a Docker champion there. It was maybe 2014, maybe 2015. And at the time I was working on this really complicated tool chain because it was building my C++, throwing in some JavaScript. It was asmjs, which is really the precursor to WebAssembly. And I was constantly having this problem of, hey, it works on my machine. And everybody else is like, this is black magic. So I believe that having a community and having people on board other people who are really excited about Docker at the time, the Docker champions really led the way in building a community. But at that tech meetup, not only did I just build my first container, I built a container that I immediately shared with the person next to me. And that was my, like, aha moment. Like, wow, okay. I can build something that's portable. We've since learned that it's not perfectly portable, but it was wildly portable at the time. And so that was a really special paradigm shift in basically the industry. So building on community, collaboration. And it was very developer-centric. It solved the problems that I had that day. It added a new tool to my toolbox. But really, to me, what was the thing that was the paradigm shift? How do we know that that's happening? Well, we know what's happening when you have many different companies and organizations come together and say, yeah, let's standardize around this. Let's make it interoperable across all of our different platforms. And you can see that happening today. So my call to action, like, let's do this. Let's start building better together, building WebAssembly components. And if you want to know how you can get involved, there's a lot of different ways. In particular, I think Wazi is one area that's extremely exciting. And I'm biased as a co-chair, but trust me on this one. Wazi.2, it launched January 24th. It's actively being added to many different standard language library tool chains, which basically means it's got to be stable. It's got several years of support. So it's a stable foundation that it's time you can come and build on it. There's this other aspect here that maybe is a little bit different if you were familiar with Wazi preview one. And that's where we're actually going to be doing many time-based releases, regular releases that add only additive, non-breaking changes to Wazi. And that's going to let us really accelerate our development and our growth on this. And I believe add features that the community needs now and be able to consume it very soon. So I'm extremely excited about that. And that's really what's going to evolve, I think, just the developer experience, adding new tools, help us add new languages to the ecosystem. And my goal really is to see this go and be extensible everywhere. So on top of the .2 foundations, we're going to see several new worlds. Some of them are going to be talked about today, including Wazi Cloud, Wazi Embedded World for running on embedded devices, Wazi NN for doing neural networking and inferencing, being able to run GPU workloads with Wazi Web GPU. So it's so much more than just those first two worlds that launched. These will likely come online this year. And so to me, that means we're going to see an application evolution across our stack. But I don't want you to think that when I say here a platform revolution, just like what happened with Docker, where we saw basically all the platforms were reorganized to orchestrate containers at every scale, the platforms of tomorrow, in my opinion, are going to be orchestrated around components. So when I say we're going to create a revolution here, I don't mean this one. But I do mean being able to do this across many different foundations, including the CNCF and the Bicode Alliance and others, and work together because we've got this one thing that's interoperable across all these different ecosystems and stacks. And you might be thinking, okay, maybe it's just the start of this, right? Like, okay, it's very early days. I've tried to use this stuff maybe a month ago, and it was kind of friction-full. And I can assure you when I tried things in 2014, I felt some bugs and rough edges. That is definitely the case, but it's evolving so fast. And really, this wasm-native revolution is happening right now. It's already here. If you look across the CNCF landscape, I can see so many different little shoots of wasm popping up everywhere. It is not isolated to one runtime that's doing this. It's not one group or organization. It's across all of us. And that's really, for me, our paradigm shift. So if you want to get involved, please go to the workshop that shows two different CNCF projects that show you how to build your first WebAssembly component. And also check out the component model book. I think it's a really great resource for learning more about how to get started with components. And if you do all that, one, thank you, my biggest call to action to you is to go and add Wazzy to a target for your favorite library and make it part of our ecosystem. It's going to take everybody everywhere to do this, but I think we can do it. And it's going to be incredibly powerful because the only way to build software is to build it better together. Thank you. Wow, Bailey, knocking it out. You were talking about Unix, right? And like it or not, the standard is still CE compatibility. Why do you think developers should make library for WebAssembly components instead of FFI or CE compatibility? Yeah, so that's a great question. One, I actually intentionally snuck this one in there just in case I got asked this. So I'm going to go right back. Okay, you see this? I snuck in libc right here. And I did that on purpose because you know what, I'm not saying don't do this. Do it. If it works for the type of ecosystem that you're running in, you can make any type of interface you want. What I want to see in Wazzy, and now this is an open standard, open community, so it's not just what I want, although you know, it would be great if it was. I really want to see that we design interfaces that are fine grained, right? I don't want to fall into the pitfalls of past mistakes. I think that we can build a foundation that is capability driven and capabilities safe. Those are key principles. Dan Gohmann, who really was one of the key creators of Wazzy, he followed a thing called Cloud ABI. And that was all around how do we build basically these interfaces in a way that we're only giving away the capabilities that it absolutely needs? There's going to be a really great talk on a little bit more detail on that with live demos later today. So I don't want to give too many spoilers, but why not Lipsy? Because it gives a very broad footprint. It kind of forces everything into that one singular, well singular 500 and what, 26, this calls API versus that one semantic API that the component maybe needs to expose. You want to follow up on that one? So you mean it's just one machine, one virtual machine instead of one interface? Yeah. So instead of having a really broad set of things that you got to pull in and depend on, let's get it to this like the exactly thing that you need. And that way as a platform operator, because I work at Cosmonic, it's a managed pass, I really want to know, hey, is your component trying to use sockets, for example, which would be available if they use something like all of POSIX. That's something that I need to know so that I know how to sandbox it. But what I want to see with these components is that if they build exactly their semantic API and they don't pull in something like HTTP, I can take the exact same component and run it inside a UDF, inside a database that doesn't need a big overhead. I want something that's itty bitty so that I can run it in the exact same process as my query processing engine. And I want to take that exact same component and run it in a TypeScript application running in the web. And I want to run it server side. And I want to be able to scale it out everywhere. Hello. So I just have a question about the communication. If you use Wasm everywhere, can we completely avoid GRPC or any other GraphQL or REST? Like you can completely avoid and use Vassie and which is it possible in the near future? Yeah. I want to give a shout to a tool that Yash created. And we're going to bring into the bytecode alliance, I believe, and he called it Wasm HTTP tools where you can take a WIT and produce an open API document so you can do REST calls and back again. So WIT is very much designed to be machine readable. So we can do a lot of these different existing transports without having to necessarily change them. I can create components that talk to the services that I have today. But I am a big fan of the idea that maybe we could just have everything be WebAssembly component native. Thank you for bringing this and making this live. I have maybe not a very comfortable question for you. Personally, I dream of a world where containers are gone and data scientists no longer do Python. And I really hope that this is the killer for it. And I also think that one of the things that you didn't mention that made Docker very successful, that it made Python usable in production. And especially data science applications. But what is the state of Wasm support for C Python? And are we going to see maybe in the near future something like components for most common data science libraries like SQL learn and being able to run data science applications using Wasm components rather than a silo of libraries piled into the container praying for it to complete with zero exit code. There is a lot of innovation happening in this space. Kind of back to the same theme of you will see many different shoots of innovation doing things in different ways. I would like to start, I guess, maybe it was two years ago or yeah, about two years ago, one of my co-workers Kevin Smith at single store had taken the C Python interpreter and compiled it down into a Wasm module. And then several different maintainers that actually worked on C Python were working on the exact same thing at the same time. Later, that's evolved quite a bit. It's been moving through the phases. It's totally usable today. And our friends at Fermion, Joel Dice has been doing a lot of amazing work on both making things work with Wasi lib C and then also extending basically the developer experience for building Python components. And that's what the tool called componentized pie. You can check that out inside the by code alliance. But basically, by being able to bring over not just Python, I think that's the real trick with the data science. And I'm guessing maybe you're a Polarys fan. Polarys is pretty cool. But if you look at the types of libraries that people bring in for Python, it's not Python. It can be C plus plus. It can be all those native stuff. It can be Fortran. It's often Fortran. So you need to be able to not just bring over Python, you've got to bring over that whole ecosystem. And so the only last person I'll give a shout out to is the pio died folks. They've been porting basically the entire data science stack to make this a reality. Spicy question and a great one. Keep these coming. We've got a few more minutes on these. I think the component model is very interesting. I kind of want to have into the question about like network communication because I mean in Kubernetes and what do we have? Everything is kind of in the idea of the 12th factor. Everything needs to be exposed as a network service. But I've never done Erlang, I have to admit, but Erlang has this wild model of it just runs distributed and you can just swap out function. Is that something that we see eventually with WebAssembly? Because I see the potential for it that, oh, we don't care about the network anymore. The network, it's just there. But we as a developer don't need to care about it. Yes. It kind of feels like you're reading some of the lines on my team. I don't want to spoil things. So I can't say too, too, too much. I will say that, yes, with components you can kind of expect the interconnectivity fabric to be flat. That's just not something that a developer needs to worry about. We can generate the HTTP protocol that it needs to use. We can generate the GRPC. We can generate whatever special sauce we need to run it in a database. What's important and what I think we're going to see coming in next year or so is platforms that understand components natively and know how to distribute and scale them for the given workload. So to answer your question, does HTTP and services go away? I don't think so. I think the key that made Docker so successful is that I could run it on my bare metal Linux box that was already running all my other workloads. I just started kind of doing the lift and shift pattern. It wasn't cloud native when I took the first container that I shoved my entire Spring Boot app in there and it was like two gigabytes or something crazy. And then it was running. And then I was like, okay, that's pretty awesome. But we should break down that monolith. I think we're going to see the exact same patterns, right? We're going to see the strangler pattern of bringing components, making it compatible with the existing ecosystems that we have, and then extending it out to the future.