 Welcome to Amsterdam and KubeCon CloudNativeCon 2023. Join John Furrier, Savannah Peterson, Rob Streche, and UPSCOT. As the Kube covers the largest conference on Kubernetes, CloudNative, and open source technologies together with developers, engineers, and IT leaders from around the globe. Live coverage of KubeCon CloudNativeCon 2023 is made possible by the support of Red Hat, the CNCF, and its ecosystem partners. Hello, and welcome back to the Kube's live coverage here at KubeCon CloudNativeCon Europe. I'm John Furrier, it's Savannah Peterson, host of the Kube. Savannah, we've got a great new format here, a panel. Excited for it, John. Concepts. Kelsey Hightower is supposed to be here. Got lost. He's getting jumped by his fans, but two great guests, Matt Butcher, Thromion, and Justin Cormac, Docker, both CTO and CEO, respectively. To unpack, WebAssembly, also known as WASM, and get the view on AI. Because you know, this is what we've been trying to get a hold of. I'm excited for this one. This is hot. Everyone's talking about it. Let's dig in. Matt, welcome back. Last year you launched at KubeCon Detroit. Yep, yep. Welcome back to theCUBE. Yeah, thanks. I'm happy to be here again. Justin, you've been on theCUBE multiple times with DockerCon 2021-22. Yeah. Things are good. I know business is great for Docker. So congratulations. You guys are rolling with WebAssembly. Congratulations. Thank you. It's a hot topic. Oh, yeah. It is. Yeah, especially here at KubeCon. Oh, yeah, baby. You know, binaries, assembly. I mean, that's the language of love for developers. That's right. Let's get steamy in the afternoon today. Here we go. It's a sexy topic. Like in martinis, we're talking. So let's unpack it. Let's get on the record on the video. What is the purpose of WebAssembly, WASM? What is it? What's it do? Why does it exist? What's the North Star? Let's lay that out there so people can actually get a good video definition of the concept. I think the good place to start is what it was originally built for. You know, as we know, as web developers and now cloud developers, JavaScript was the language of the browser. And over time, over the browser's history, you know, we started trying to use other languages like Java, like ActiveX. And compiling things to JavaScript as a way around not having other languages. So things like Gmail was compiled from Java. None of them really kind of had the staying power. Plus a lot of the things we've really valued about these other programming languages didn't quite carry over in that set of circumstances. So WebAssembly was invented to kind of attempt to rethink what it would be like to have multiple languages that could serve sort of an assistive role, I think I call it, right, with JavaScript in the browser. And the idea was you could take a bunch of off-the-shelf languages like C, you know, the one language that has deep, deep pedigree, and rust a language that at the time had been around for, you know, a couple of months, I think, when WebAssembly started in 2015. And the remarkable thing about it was that the core team who started working on WebAssembly, they said, we want to do this in the open. We want to do open source reference implementations. We want to have all the browsers supported and we want to standardize it all up front because then the industry will just agree this is the way it ought to work. It's not a compiler. No, it's a specification for the instructions on how to run the code. But it's compiled generally by the normal language compiler nowadays. So like if you have used Go, Go just has WebAssembly as a target. You know, you use Rust, it has WebAssembly as a target. So it's built into your normal compiler and it's just another thing you can output instead of native code. And what's the benefit for the developer? What's the value to the developer? I mean, this initial value proposition was that you could take existing code, like you had some code to do some image processing. You could just run it in the browser without having to rewrite it in JavaScript, which would be a huge pain because this is like code that you developed over decades. Yeah, we're trying to get rid of wastage in all of the software development and this was a way to do it. And I think also there were some use cases where writing in a low level language like Rust or C++ and then compiling it to WebAssembly would help with some of those kind of number crunching types of operations. That's where Figma and Adobe really found a lot of use cases. So bottom line is it was a pain in the ass for developers to rewrite code. Okay, that's why the mass adoption on the compiler side was rampant. Easy, makes things easier to integrate and run code. Yeah, so what took so long? I mean, there was a lot of full starts and things and kind of attempts to do. There was ASM.js, so it was an iterative process, not just like, this is the best idea ever, let's just do it. It was like, we tried this, we can still do better. You know, it's a good idea, it's hard, let's do it right. Yeah, yeah, yeah. I think there were three characteristics of WebAssembly. It proved to have value outside of the web browser in its initial environment and we're starting to see it sort of spread out into different ways. And those three, maybe you have a different list. The three for me are it has a great security model, which is always one of the things we want to make sure we do well and oftentimes it's one of the last things we think about. This time it should be one of the first things we think about. The second one is its performance is just off the charts. We want fast execution environments because when you look at a website and you first load that website, you want it to load right away. Well, as you can see, in the cloud world, we're really struggling with those same things. How do we keep speeding things up and how do we get the most out of it? So I think that's the second one. And the third one was this kind of neutrality. Typically, when I compile a C program, I compile it to a specific operating system and a particular architecture. And that means if I build it on a Mac, on the latest, greatest M1-M2 processor, you can't run it on your Windows box. Somebody has to recompile it and run it there. WebAssembly provided a binary format that could run on all these different devices really from very specialized, small IoT devices up to the big server-grade hardware that we see in the cloud and elsewhere. Yeah, it's the right once-run-everywhere thing that the Java promised. And it worked to some extent with Java, but not everywhere. Java in the browser was a thing for a little bit and then went away again because it didn't have the right security model. So again, the first one, the security model, it has to be the right security model for all these different environments. And that's hard. And we learned a lot again over the decades of working out what the security model had to look like and that's why the WebAssembly security model is different and stronger than the previous ones. Yeah, just a follow-up on that real quick. I know Savannah wants to jump in, but the extensibility question might come up. So I might say, okay, that's great, but what about the security model if it changes? What makes it extensible? Is it standard? What's behind the extensibility? Well, I think part of it is that WebAssembly on its own doesn't specify the external interfaces to the outside world. It just has a model where you define those when you create the run time in the application. And I think that's always been the browser model. To build the browser security model, you have things you plug in, like new standards. Each time you add something, you make sure that you understand the security model of the new thing you're plugging in and it's hard. So WebGPU came out recently as adding a GPU security model is difficult, so it's taken a long time. It's hard work, but it's like you build these interfaces and the libraries to implement that and then you validate the system as a whole with that API and make sure you understand its full behavior. And it doesn't have a sort of generic, extensible thing. It doesn't have a really big standard library like Java did. Java had a lot of security issues in the standard library and that was part of the weakness of the Java security model, the standard library was big. WebAssembly is quite small. It's back small and easy to understand for the run time. And I think, I mean, to flip the question on its head, if WebAssembly is sort of like a nice closed little system and it's really up to the people who use it to say, okay, we're going to allow it to do this little thing now. We're going to allow it to go reach out to the internet and grab a resource and pull it in locally. We're going to allow it to read these four files on the file system, but nothing else. And so that kind of inverted security model, that capabilities-based security model where the control of what it's allowed to do is external to the language itself means that when we start with it, it's very secure. And then as long as we follow the rules and we're wise and diligent in the way that we build the system, you just open it just a little bit and allow a couple things through. It's like a little clam, it's very cute. And a lot of testing and a lot of trust testing. Sometimes it's got a pearl in it. I was going to make a pearl joke, be me to it, Matt. Be me to it. I love it. Well, so let's stick in there a little bit. And Justin, we were talking about this in our virtual green room here just before. Where are we at with Wassum now? What's the lay of the land? I mean, John was joking, what took us so long, but we're still pretty early. It is early. I mean, it's been a few years. I think that we've actually, if you look at what we've done in the last few years, as you can see, we've come a long way. I think the biggest thing, I mean, you did a blog post about it at the beginning of this. Yeah, but almost every language now supports Wassum or is about to support Wassum as a compilation target. And that was really difficult before. It was like, well, you can use Wassum as long as you write all your programs in Rust or C. And it was like, anything else, you're out of luck. And it's sort of the old Model T thing. You can have a Ford in any color you want as long as it's black. Yeah, exactly. But we're past that. So now the compilation target side of things is settling down. There's still work to do. And there's new features in WebAssembly to support new things being added and things like that slowly. But the basic thing of like, I can write a program. I can find a compiler for it. And I can compile it to WebAssembly Works, which is really what you need to enable the developer to get started. Yeah. So that really feels like it's got somewhere over the last few years. And I think part of the newness, part of the reason it feels new is the same reason we kind of saw Java feel new when it was really a few years old and Ruby feel new when it was 10 years old. You need these kind of technologies. We write them for specific cases. And sometimes we're right and we do a great job on it. And other times we're just totally wrong. And Java was originally written to run in very small devices. It was an embedded language. That's probably its least utilized use case at this point. That's definitely not what I associated with at all. No, it found its niche outside. And Ruby was a simple one. It found multiple niches as well, because Android was one of them. And the enterprise was another, which was very different as well. And Ruby was kind of the same. It was a scripting language to orchestrate unixy things. And then Rails came along, Ruby on Rails came along, and suddenly every developer that was doing anything on the web or doing anything in sort of orchestration had to know these languages. And I think that's what's going on with WebAssembly. As it started out trying to tackle a problem, it has found some traction. There are a number of popular websites like we talked about Figma and Adobe that use it. But now, and this is where Justin and I get really interested in it, we're starting to see applications of this technology elsewhere where we kind of lift out the WebAssembly runtime from the browser and plop it in Docker and can execute WebAssembly there. And we plop it in, you know, Fermion and we execute WebAssembly there. Or you plop it in Nginx or Istio and like other places. Or databases. This is where I think it's compelling. This is where I want to, we'll get to the AI thing later, but this is where, you mentioned browser, but browser is a browser. It's not a mobile app. They have mobile browsers and you got AI apps coming. The application frameworks are growing significantly. Open source is growing. So there's now new capabilities. What are they? What's the sweet spot? What do you guys see the value? What do you see as areas that are going to be opportunities for Wasm to grow with developers? That's not just browser specific. I've kind of got my four and you've probably got a different set. I mean, browser is the obvious one. We talked about that already. I think IoT is another one where you're dealing with very small. Mobile browser too? Yeah, my, Wasm is supported in all browsers, mobile and desktop. That was part of the importance of it being a universal platform and supporting that. Yeah, probably every device on this table already has Wasm support in it. That's kind of how quickly it's moved out there under the radar. So, and I think IoT will be a big application. I think we kind of jokingly call it the last plug-in model you'll ever need because it is a great technology to plug into existing systems and allow developers to extend them. Plug-ins is an area that people don't think about much because it's a kind of weird thing. It doesn't really have a very big ecosystem but it's really important. And, you know, it's the basis of, you know, it's a, there's always, when you're trying to build a platform you need an extensibility model for like how do I do new things that the platform hasn't thought of for me. And that's usually some form of, you know, embedded programming, embedded scripting, you know, all sorts of, I mean like, you know, Salesforce, for example. It's a big scripting platform, basically. It's like, these things are huge and you just a new tool. I don't want to go there. I was going to say, are we really going down there? No, no, no. I'm just going to redirect. I'm like a bumper over here. It's going to keep us in the layer, which is rare for me. But under the, is there a middle layer kind of underneath the apps, the browser? You mentioned containers is a hot area. So where is the fit-in to all this growth here? As you start, people start moving off, say, you know, virtual machines, bare metal apps to cloud native. Yeah, and that's where I'm most excited about it is I think with WebAssembly, the kind of fourth use case and the one that Fermion is most passionate about, I think the same one that Docker is most passionate about is that we can use the WebAssembly runtime as a lightweight, very portable execution environment that complements the existing virtual machine and container ecosystem. But because it's got that strong security model and ultra fast startup time and cross language, cross platform, cross architecture story with it, it means we can build some of the things that have really been sort of a struggle for us to build in the past, do really well in the past. An example of that is serverless. I mean, when we think about serverless, couple years ago it was all the hype, but it didn't quite live up to the hype. We didn't figure out how to solve some of the difficult problems. So it started to kind of downtrend a little bit. And then we looked at it and we said, well, okay, some of the problems we were seeing is there's a mismatch between the architecture underneath and the kinds of applications we're trying to write. WebAssembly is a better architecture to sit underneath that and be able to start things just with supersonic speed and just execute them very quickly. If you kind of look on Stack Overflow about the kinds of problems people have with serverless platforms, a lot of it's about cold start time, keeping my app warm, all this kind of... And vendor lock in too. That as well, yeah. But I think that people are spending time managing things about the platform rather than things about their application. They want to just write their application and have it magically work. And it's not quite that. Right, yeah. This has been one of the side effects of successful DevOps. It starts to operate and then you got to start managing that op a little bit. Yeah, and this is where potential AI comes in or other things. So how do you guys see that nurturing of the infrastructure? I mean, basically you got to nurture your app. Right. I mean, take care of your app by not paying attention to the things that you just need to run. Yeah. That's what you're instantly saying. I mean, yeah. I mean, there's a big overhead with applications about running it and the infrastructure you need and the code you need and the configuration you need. And it's been liberating that we've had these platforms that we can do this and we can build cloud native things. But there's a lot of complexity. There's a lot of time and a lot of effort that people have to do to deal with these. All right, bottom line is we wrap up the Wasm portion. What is the outcome going to look like for developers? Shoot the arrow forward five years. In your mind's eye, if you had the pixie dust, the magic wand, what would you hope have happened? Well, we'll start with, go ahead. I'll start with you. Fake left? Yeah. No, for me, I think what we are most excited about is I think that this is going to redefine some of the layers of the cloud. It's going to allow us to build the kind of serverless functions we've wanted to build for a long time and the serverless apps we've wanted to build for a long time. But it's going to do it in a way where, first of all, I hit on vendor lock in just for a second there. That's one thing we want to avoid. We also want integration with Kubernetes, with Docker, with virtual machines. And so I think what we're going to see is a move toward a simpler developer model in this serverless functions way and a move that also compliments the operational model that has become popular now. So the way I think about it is the pendulum swung many years ago very hard in the developer side. We had Heroku and things like that swung all the way over to the operation side where the developer was suddenly like, I don't understand any of this, but the operator really liked it. Now we're trying to reset it in the middle where we can say the developer concerns are here. WebAssembly does this nice job of wrapping all of that right up. And the operator still has all the flexibility on their side to build the kind of applications that they love building with tooling like Kubernetes or even if we rewind back, you know, Puppet and Chef and tooling like that. So similar tool base, easier to code. Yeah, makes the developer story much easier, but still gives the platform engineer the kind of control that they really want and need. Everybody's happy. Everybody's happy, love that for our future. I think that the enabling developers to just write applications that can really run in all sorts of places and use the same code in a lot of places and, you know, recut your app depending on whether you want to run it. Parts of it in the cloud, parts of it in the browser, parts of it on serverless like these. This gives you the flexibility to structure your app. I think we're seeing, you know, with microservices, we're seeing that it's a very different kind of operating model than it used to be with modelers where your app would run and sit on a mainframe or, you know, in a big data center. Now parts of your app are running on the edge, parts of it running in the browser, parts of it are running in microservices. Like, you've got this flexibility to put things where they need to be, recut them, move them around for performance reasons, for latency reasons, you know, for ease of development and shipping reasons, ease of update. Like, all these things give you these options, but if you have to have a different technology for all these different things, it's really... It's a cluster. And not, no pun intended. Yeah. Or maybe intended. Well done there. Well done. And the market that market is ready as a tailwind for cloud natives, so much more growth. Look at just the migration from old tech to kind of cloud natives, still a lot to go. Go on. Oh, yeah. I mean, it always comes down to the same things. We want to do more faster and with less complexity with high security. Yeah. And it seems like that's where we're driving. And cheaper. Also cheaper. I mean, obviously. And cost-optimized as well as everything else. But it is. It's about that accessibility. I mean, Docker's been a platform that's been making a lot accessible for people forever. And forever. At least for my forever. It's what my mind is concerned when it comes to the internet. And yeah, I just, I love it. Is there anything you guys disagree on? I mean, tea and coffee. Yeah, that's tea and coffee. But I think, you know, there's still... Tea and coffee. It's still new. It's like, and there's still a lot of different directions that could go in. There's different things that could be important. I think that we haven't seen, we haven't seen yet the thing that makes a million developers say, I must use Wasm tomorrow. And that, you know, and that's the thing that we're still kind of feeling our way around. Except this interview. Maybe this interview will be that. Well, compiler targets is a big table stakes. That's critical. Absolutely. Number one baseline. Yeah, absolutely. That's a major achievement. That's why I feel that this, you know, last year was kind of the first year that Wasm could start to succeed. Because before that it was just... You know, we looked at the, you know, five years ago, I think it was Solomon's Tweet. That was when we were experimenting with stuff. And it was like, this stuff's early. You're going to spend all your time building the tools to make it possible. And not working out what the amazing bet is. And now it's different. You know, we track all the top 20 languages in their progress toward Wasm. And at this point, 17 of the top 20 have Wasm done or are significantly in flight. So I think to your point, from three years ago to now, we've seen the tipping point. Yeah, you're going to need that next figment and say, okay, I could do that fast. I get it. I think it's going to, the bit will flip. And then I think the tsunami of the migration of developers to it. You can see that everything's tightened up. In my optimistic take, it's flipping now. What do you think? Now? A year? Two years? For me on what's that? Last week? It's flipped right now on theCUBE. Right now. Yeah, right now. There we go. This was the moment. No, I think there's definitely like the trajectory is up and to the right. The amount of interest at KubeCon, like in Detroit and here, it's just like, this is... It's one of those moments where it's about time. It's here. It's real. It's getting real every day. The targets are there. Reusing code. Then the flywheel kicks in. Yeah, exactly. Guys, this is a master class. I learned as much as I crack jokes. Thanks so much for unpacking that. We're back with another panel on AI right after this. We're going to unpack it all. Stay with us to Kube. I'm John Furrier with Savannah. We'll be right back.