0:00 Introductions

0:00 Okay. Thank you everyone for joining me. This is a new podcast that we're launching called the Cloud Native Compass, which focuses on containers, Kubernetes, WebAssembly, and everything in between. And today's episode, we are talking about WebAssembly and server side WebAssembly. I have three wonderful guests who will each introduce themselves now, and we'll start with you, Kevin. So I'm Kevin Hoffman, CTO of Cosmic. Created the WasmCloud open source project, wrote a book called programming web assembly with Rust, and just in general have been using and experimenting with web assembly since, well, since before the standards were fully baked.

0:16 Guest Introductions

0:44 Thank you very much. Connor. Hello. I'm Connor Hicks. I'm the founder CEO of Suborbital. We focus on using server side WebAssembly for the purposes of building extensibility into SaaS applications. We build effectively a plug in system for SaaS, cloud based apps. And I was experimenting with WebAssembly for probably two or three years before that, so I've seen a little bit, but don't think I've been around quite as long as Kevin. Hi, everyone. My name is Kate Goldenring. I'm a senior software engineer at Fermion where we're excited about serverless WebAssembly applications. And previously, I came from a Kubernetes background.

1:29 So I'm still a co chair of the IoT Edge working group and the CNCF. So still enjoy the Kubernetes space and currently have moved into this new WebAssembly world, excited about the serverless side of it. Alright. Thank you. So as part of your introduction, as you've all obviously shared a little bit about how you got into WebAssembly, but I'm hoping we can dive into that a little bit more and just kinda understand not just why you're here, but, like, what your path was to get to WebAssembly. What did you find interesting? What feature like, what really got

1:43 Path to WebAssembly

1:59 you on that road to join in this in the WebAssembly landscape? So there's no right order here. If anyone wants to tackle that question first, please feel free to blink twice, put up your hand, anything you wish. So a while ago, and this was, you know, when we were all riding to the office on the backs of dinosaurs, I was trying to solve a enterprise problem where I had a number of teams that were all trying to contribute business logic to a shared portal. And so one of the problems I was trying to fix was

2:02 Kevin's WebAssembly Journey

2:34 how do I make it so that these teams can all work in the environments that they're comfortable in and still and the languages that they're comfortable with and still be able to contribute to this, you know, shared target platform. And so one of the many thousands of rabbit holes I went down took me to AsmJS. And then I also did some experimenting with this thing called CloudAVI, which to me feels like a sort of a spiritual ancestor to Wazzy. And from there, the rabbit hole just grew bigger and bigger until I found my way to web assembly and,

3:18 you know, wrote my first Hello World in in c. And then, you know, once I figured out how to do it in Rust, it was pretty much all downhill from there. And the the technology that ended up helping these various teams do what they needed to do is what ultimately ended up as part of the open source Wasm cloud project. Okay. For me, it was a COVID, you know, playing on my own open source projects type thing where I got frustrated with how containers were behaving in a particular project that I've been playing with on the weekends

3:46 Connor's WebAssembly Journey

4:03 while we were in lockdown. And I had kinda filled around with WebAssembly before that, but I decided to try to pull it into this project I was working on to try to get faster startup times for basically a job processing framework that I was building. And I pulled it in. It was a very rudimentary Rust implementation with a couple of very basic bindings to be able to, you know, just read system stuff. This was while Wazy was still a little bit, you know, in its early days. And the thing that really got me hooked was

4:47 that that performance that I was able to pull out of the, the job scheduling system that I was building compared to the previous implementation of it that was based on containers. And so, you know, that that one weekend of hacking was enough to convince me that there is some real utility for WebAssembly, and then that was about three years ago. So now I've been working on it full time since then. Yeah. I mentioned in my intro that I kind of came from the Kubernetes ecosystem. That's exactly what brought me into the WebAssembly space, which is a bit unusual. But I was

5:12 Kate's WebAssembly Journey from Kubernetes

5:23 maintaining and still am a project called Aukri, which is a CNCF sandbox project. And while I was at Microsoft and we were trying to we were wondering what would it look like to port this application to being a WebAssembly application. And we had a sister team, which is the Dais Labs team, of which many of those people now came and founded Fermion that was working on a project called Crestlet, which was basically a a first attempt at what does it look like to run WebAssembly instead of containers on Kubernetes. And so I jumped into that effort and

5:53 implemented, the device plug in manager in that Kubernetes kubelet, written in Rust, which is why it's called Crestlet, and kind of saw some of the issues we were having around using a new kubelet implementation as the way of running WebAssembly on Kubernetes and how just the load of what we needed to do kept getting bigger and bigger because it was a full kubelet. And at that point, many people had switched to moving on to Fermion, and I kinda got hooked on WebAssembly seeing all the benefits on the server side that originally were those benefits that were made for the

6:27 browser. So that made me also join on with Fermion and keep going in the WebAssembly space. Thank you. So, you know, all three of you mentioned server side, Wazi, for people that aren't that familiar with what the Wazi as a as a spec yeah. Specification. Right? What that is? Maybe we can give them a bit more context on why that's important for today's discussion. So I guess I'll start with the hard part, which is that Wazi is influx and it's one of those things that means something different to different people even though, you know, it's it's an official standard. Right?

6:35 What is WASI & Component Model

7:03 So when when you look at WASI, some people and again, the documentation in different places treats it this way is they feel like they treat WASI as though it's like a POSIX replacement but for web assembly. And it may have originated that way and with that goal in mind, but the way things are going today, it seems more like the WASI is more along the lines of the the implementation technology that's enabling things like the component model. And so I guess the the short version is that WASI was originally created as a way to give

7:53 WebAssembly modules access to external services, but those external services were low level, like being able to read from a file descriptor or being able to write to standard out and things like that. And that seems to be evolving towards the component model where now the idea is that the the external services are high level abstractions like web client, web server, key value store, things like that. Oh, I was just gonna add just because I don't know if we've said it yet. WASI stands for the web assembly systems interface. So it's what Kevin's mentioning. It's those interfaces that are

8:37 allowing a guest or a web assembly module or soon to be component to talk to a host and use those resources from the host. And it's essentially just a wit or that type of file where you're defining all these functions that give access to your guest code, those resources on the host. And as Kevin mentioned, it's been evolving to from providing just the bare minimum of what you may need to run an application directly on the server into more of this idea of what is what does a cloud look like that is made up of web assembly

9:08 functions. And so we're getting those key value services and other kinds of services that you would expect from the cloud, and all that's being defined by these WIT interfaces that give access to host resources or other resources that the host can point out control to. Yeah. Another way I like to look at it is think of an interface in a programming language, being able to define an abstract set of methods or behaviors for an object and then having multiple implementations of that within that language. You can think of Wazee and the associated component model as a generalized version of that

9:45 where you can define a set of interfaces. Some of them will be common and and set by a standards body as, you know, the things that you need every day, like accessing randomness and the clocks and stuff like that. But some of them will be user generated, and at the end of the day, you result in a shape, a an external, set of inputs and outputs that any module written in theoretically any language could conform to. And if you load a module that conforms to that interface, it will theoretically satisfy the requirements of your program.

10:19 And that's, I think, where we wanna get to, and it's just a matter of working through that very complicated problem in the standards body, and that's what's happening right now. Okay. So what I'm gonna try and do is repeat all of that back in a summary fashion and hopefully not get too much of it wrong, but feel free just to let me know. I I'm I'll make some assumptions as I go. But, you know, I think what I heard from Kevin is if we could take a Wazee something like POSIX, but not directly like POSIX, then it allows

10:29 WebAssembly Sandbox and Interfaces

10:46 us to be able to speak to the host fail system, to the networking stack, and so forth. It feels like it was said that the component model was an evolution of this or an implementation of this. I'm not sure which, but maybe someone can clarify that. But what that means is both. Yeah. Yeah. We'll go with both or it depends. I like the answer to depends what we use to squint your eyes. But, you know, we have the component model there and we the reason that we need this, right, even if we go back a little

11:13 bit more is that WebAssembly as a runtime is a really strict sandbox. Right? Is it safe to assume that it has no concept of a file system. Right? Because it runs in the browser. It has no concept of I don't know. I mean, it has networking. Right? But does it understand layer seven? Is it just l four? Does it have none of that? I'm not even entirely sure myself. But these sorts of primitives that don't exist in the sandbox and the component model enriches that with some of these common interfaces like Kate and Connor were saying. I think

11:43 Kate, your example was k v storage. If we provide an interface, the k v get and k v set It depends. Yeah. Does that mean the component model can drop in a Redis component, a MySQL component, a, you know, a simple file component that does, you know, files as the best TV. And then as a consumer within your WebAssembly program, you don't care. Is that is that right? Yeah. I think the main so there were two things that I I wanted to point out. So one is, again, depending on what you're using it as your your definition of WebAssembly.

12:19 WebAssembly on its own, so the the standard, the one dot o freestanding web assembly has no concept of networking. So there's no networking. There's no file system access. There's no IO at all. There's just the ability to take in numbers and give back numbers. And that's essentially a direct result of the sandbox that you're working in. The only thing that WebAssembly on its own without the assistance of a host can do is just pure functional compute and access a shared sandbox piece of memory. And that's all it can do. So the first thing that people run into when they

13:07 do that is they need they need access to more than just pure compute. And so how do you do that? The the first thing that enabled people to do that was Wazee And they were able to then access, you know, sandboxed file systems. And what we're talking about as the evolution of that is what you were saying where the next step is to grant abilities or to grant these interfaces to the guest modules to the components. So moving moving forward from Wazee's low level capabilities to the next level up. So, you know, high level cloud services. And just to follow-up

13:56 on your question, David, I think you mentioned there that, yeah, you can have your guest then point to multiple use different hosts over this interface. So in the key value scenario, you're saying you can do a series of gets and sets. The interesting part about this isn't one, like you said, that as a developer, I don't need to care about what the host implementation is or whether I use Redis or DynamoDB, for example. But another part of it is that I could change my mind. So I can have the same web assembly module, and keep that constant. And then maybe later,

14:36 I want to switch to Redis. Then I don't need to rewrite that that application. I just need to change the host side of it. And then one other point I wanted to make is I think Wazee and the component model, I personally see them as very related because the specification is moving towards the component model. But I think it's easy to think of them as separate in the sense of I think of the component model as a new way of envisioning applications and the way that we see applications and making them composable and, making essentially dependencies.

15:09 You can click them in place and swap them out more easily. But I think of Wazee as this evolution that enabled us to run WebAssembly outside of the browser that has now decided that a really good way we wanna do this even more so is with this new way of making applications with the component model. Yeah. I think what's what's important that Kate was mentioning that I think it's it's subtle and a lot of people don't really see the impact that it's going to have right away, but the idea that you can change your mind

15:27 Runtime Flexibility and Code Portability

15:44 at run time between implementations of these contracts is way more enabling than some of the technologies that have come before it. So in addition to me being able to change my mind about which implementation of a key value store I'm I'm dealing with, I can change that at run time. I mean, depending on the host, obviously, but I can change that without having to rebuild my code. My code is now no longer tightly coupled to the shape and scale of my deployment. Yeah. And and a kind of adjacent benefit that you would get that I don't think

16:25 we've really seen with any other technologies is the ability to not only change out implementations at runtime, which will be extremely awesome in its own right, but then also the ability to move code to different layers of the, excuse me, the network stack, I guess, one way to look at it. Like, you can move code from executing in a central AWS region out to, like, an edge worker style region and not have to change it at all because maybe in your central cloud, you use DynamoDB for KV, but then on the edge, use the Cloudflare Workers cache or something like

17:04 that. And you would be able to either manual or maybe even one day automatically depending on load or whatever, you could move the execution of that code around, and it could just figure out how to make your business logic work with the dependencies that it needs. Okay. Thank you for that. So there's a few different interesting things here. Right? It's like we've mentioned containers a couple of times now. And, like, this containers would be, like, what we consider almost the standard developer experience for a lot of what we're talking about right now is the ability to use different backing

17:20 Why WebAssembly?

17:34 services. Right? But how is WebAssembly changing that? Now we've got a component model and this is runtime thing that we can swap out and the code doesn't change a lot. That's all very nice. But like, how does WebAssembly really continue to improve that developer experience for developers? Like, why are we seeing what started off as this browser based technology for doing computation now being used for functions and service within game engines even on mobile phones and, you know, desktop extensibility is another one. Like, Versus Code is probably gonna have a plug in system that's mostly web assembly based at

18:06 some point. Why are so many people being drawn to this versus the status quo of like containers? Yeah. I think the there's two or three main points depending on who you are and what you care about. One of them is the fact that web assembly modules are often far more lightweight than your average container. That's not always 100% true, but on the average case, that is that is true. And so, therefore, storing them, downloading them, starting the execution of them is often much faster. The second is the security posture. A lot of people see you know, since WebAssembly was an evolution

18:45 of something that came out of a web browser and web browsers run untrusted code all day long safely on your laptop, since WebAssembly was born from that, it could bring some real security improvements to cloud, execution as well, both in terms of, like, you know, third party dependency vulnerabilities and just malicious stuff that makes it into your your sort of source code, but also intentionally running untrusted code. And then the third is just a common target for multiple programming languages. Containers somewhat satisfy that, but the ability to, as we just talked about in the last few minutes, like, have

19:27 a common set of interfaces, capabilities, APIs available to you, and then being able to have all the different programming languages that you care about target that exact same environment and not have the overhead of a Linux like environment to go along with it has a a couple of really great benefits. Yeah. There's a there's a couple of things that I think people take for granted. So one is that the the idea that containers are portable is untrue. Right? Containers aren't actually portable. There are, you know, there's a whole cottage industry of tools to help compensate

20:07 for the lack of portability around containers. And the there's a a saying I'm not sure where the quote came from but you own what you deploy. So your unit of deployment is something is everything that you own. And so the larger the thing that you deploy, the larger your ownership burden is. Right? So we started off deploying in virtual machines an entire operating system plus the application that we needed to deploy. And so we own basically everything from top to bottom. Then with containers, we own a slice of an operating system and our application and all the application dependencies.

20:56 But with WebAssembly, all we own theoretically is our business logic. We don't own the external dependencies anymore because we're no longer shipping them with our WebAssembly modules. Right? Assuming that the future with this component model turns out the way we all want it to, I don't own the implementation of the key value store that I that for my WebAssembly component that I'm shipping. I can ship that somewhere and then the environment is the thing that owns that database. So I may still care about it and because I may, you know, have multiple hats, I may still be the one who's, you

21:43 know, dealing with the the implementation and the installation and configuration of all that stuff. But in terms of the developer working on just that module, they don't have to worry about owning that full full stack anymore. All they own is their use of the abstraction. Okay. So thank you for saying that containers are not portable. As a developer working on an m one Mac, I guarantee you containers are not build once run everywhere. And I think the tooling there is is really painful right now. That's one of the draws for me personally with web assembly.

22:14 Current WebAssembly Use Cases and Challenges

22:21 It's that you do just you you build it once you get the web assembly binary artifact, whatever that is, and it it does run everywhere, which is really cool. But I'm gonna take that that question that I asked. I'm gonna flip it around a little bit and see if people are listening and they like the idea of web assembly. They like the idea of working in random languages. We've already said rust three times now, so let's get that up to at least 12 before the end of the episode. But they wanna explore those languages. They wanna compel to us a common ubiquitous

22:35 When WebAssembly?

22:53 target that does run anywhere. What kind of applications does the current state of the component model and was it really excel with? Like and I'm assuming rewrite in Postgres is not the answer there. So what can we do today? Yeah. I think you pointed out where well, they're of saying a long running daemon style application like a database is not what you probably wanna target for Wazee WebAssembly at the moment. What seems to be a really good use case for WebAssembly right now is serverless. If you think about the previous unit for serverless or maybe micro VMs is a common one for

23:37 AWS Lambda, Firecracker micro VMs, those take about a hundred and twenty five milliseconds for cold starts, while WebAssembly is sub millisecond. And so you can really see event driven applications that need to run from a cold start, execute, and go down in millisecond or sub millisecond time. WebAssembly is a really good use case for that. Yeah. I'm I wanna I I don't remember who brought it up, but the ability to change your mind also extends to this type of thing. So Kate's point is excellent in that, you know, WebAssembly is great at serverless, but I think what's even more important

24:22 is that you're not locked into serverless with WebAssembly. So, you know, you can run a WebAssembly component as a stateless wake on demand function or you could leave it running and have it, you know, have 500 instances of your WebAssembly module distributed across, you know, hundreds of different servers. And your decision at that point is just a choice of which runtime or which host you wanna deploy your your component into. And your your choice of using serverless or a micro service or some other hybrid is no longer a design once and live with the consequences forever

25:14 decision, you can actually change your mind. You can go from running it serverless in a test environment on your laptop to running it distributed across multiple clouds in production without having to rebuild your modules. Okay. I'm gonna ask the hard question now. And it's like, you know, the the what's missing, like, the I I I don't even know how to phrase it in a way that's gonna even help you answer it. But let's assume we have a world ten years from now where all applications are written as WebAssembly. What are we doing to push into these

25:49 things where we quite missed the mark right now? Like, how do we write long run and doing processes for purpose? Like, how do we have databases that are purely written in WebAssembly? Is it just a maturity thing? Is there a tooling thing? Is it the component model? We need a v two. Like, what what's the trajectory there? What's the path forward to being fully Wasm? We we need a v one before we need a v two. Yeah. There's a couple of things that come to mind. One is, you know, debugging and observability. This is something where we've seen a bunch

26:20 of prototypes. We've seen a bunch of projects working towards being able to easily debug and observe WebAssembly execution. But just like the component model, they're in flux. People are still trying to agree upon the best way to do it, and the tools aren't fully baked yet. The component model itself, like I said, we're not even at v one yet. So getting to something that we all agree on, and we can say, okay. This is going to be stable for the foreseeable future. And, you know, future updates will require breaking or migration or whatever. Like, that is going

26:51 to be an an important inflection point for the whole industry. And then I think just having the different language tool chains catch up to that. Once we have that v one of the component model, we then have more work to do. Right? Having just the spec isn't enough. Rust will obviously get there quickly, but then all the other languages need to integrate the component model tooling, be compliant with the spec. And there's an additional layer of complexity for the interpreted languages like JavaScript and Python to for for all of those things, the component model and debugging and and the tooling. So

27:31 there's just a couple of steps I think we need. All of those things, we're we're seeing progress on them. And if we kind of get to this point of coalescing on the standards and the tooling and the tool chains, then we should be able to see that future pretty clearly. I think at a really high level, so Connor mentioned a bunch of different types of tooling, but in general, the tooling is just not there yet. There are some languages with better tooling than others, so I think we would all agree that Rust probably has the best tooling ecosystem right now.

28:07 But so the the tooling obviously needs to evolve, but I think even at a higher level is WebAssembly is not yet a boring technology. So part of the giant hype cycle around WebAssembly is that everybody is trying to get into the space and the the difference between now and the ideal future is WebAssembly becomes boring. It no longer is an end goal and is just a checkbox that you tick when building something. You write your code. It comes out as a component. All the tooling knows how to deal with components. You have tooling that stitch components together, and

28:52 it's all just part of the day to day routine. When when WebAssembly is as easy to produce as an ELF binary, then that's when the you know, that's part of the tipping point when things go from the the dangerous part of the adoption curve to everybody's using it even if they don't know about it. Yeah. Just if I think Kevin's exactly correct in that. If we get to a point where WebAssembly fades in the background in the same way that a lot of developers don't even know that they are interacting with POSIX or whatever. Like, it should proceed

29:31 to a similar level of so boring and so reliable that it just is a standard, then we will have succeeded. And just to add on to the comment about it being a standard, it is a standard, and it's community driven. So there is a pace at which things move, and that does require that we get certain interfaces in place. Recently, we got threads. We got socket accept. But without those things, you can't even imagine a long living Daemon application. So you can see we're moving forward, but there are other proposals that still need to happen.

30:08 And the other thing that we need is a registry for all of these different components. So if you Warg is what it's called. But if you can imagine one place where you can centralized use other people's components and make a composable application. So a developer experience that's easier around that too. So I don't need to know how to make every component, or even understand the low level WebAssembly tooling. Yeah. I think the day will come when we'll have a nearly universal package registry. Like Kate's point about work and having this, this library of components you could pull

30:44 from. Like, that is one of the big dreams, I think, of WebAssembly is that I could be writing a Python program. I need a library to do some hashing algorithm that I don't know how to implement in Python. I could pull down a package that implements that algorithm, and I might not even have any idea what programming language that algorithm was written in. It could be c. It could be rust. And I won't know or care what language that came from because the tooling will just understand that, hey. This is a component. I can understand how to load and run

31:14 a component or compile it into my larger program or whatever, and we just continue on. Yeah. I think that's a subtle and often overlooked point is that when we when we switch to the component model, the the size of the the LEGO bricks that we're using to compose our applications is much smaller. And so when we talk about how, you know, it's WebAssembly is language agnostic or you can use any language, a lot of people immediately think, well, I can that just means I can choose one language to build my application in and another team can choose another language.

31:54 And while that's true, I think some of the real underrated power comes from what Connor was mentioning, which is if I have if I am am trying to build an application and let's say I need to do some, you know, heavy duty cryptography type stuff and there's a different language where that's easy to do in its WebAssembly targeting form. And so I could write my business logic in Go, build a WebAssembly component out of that and utilize another component that does the quote unquote hard stuff for me and the component that I I've that I link with at compile time or

32:42 run time, that could do that stuff for me and I don't care what language it's written in. All I care is that it satisfies the contract. So that the idea that I have these contracts and interfaces that are being satisfied at a high level, that means that I can interchange things like my database or my web server and things like that. But at a low level, it means that I can actually build applications out of units of compute that are smaller than what we think of today as traditional libraries. And that's super powerful, I think. Yeah. I

33:17 WebAssembly Adoption and Community Growth

33:17 think that's one of the often understated powers of WebAssembly. And I hadn't really thought about it directly like this. And, you know, there is no WebAssembly package package thing yet. But using NPM as an example, if I'm working on a an application and I just do NPM install three different packages that are running three different languages, but I'll get billed to WebAssembly and I'm able to consume them in a really strong developer experience fashion. That's really powerful to a lot of people, you know, especially if you're have a data science team that wanna work in Python. You've

33:46 got your web dev team that wanna work in Ruby. You've got, you know, your infrastructure team here all go and rust and then it doesn't matter at this point in time anymore. We're just consuming each other's interfaces, abstractions, and components, which very, I like I like that feature. That's the future I'm here for. I want that one. So Alright. Well, I know two of you, Kevin and Kate, you were both at KubeCon. I'm not sure if you were there, Connor. Right? No. Okay. But I'm assuming that's not the only conference on the circuit. You've all been to many conferences over the

34:00 WebAssembly Adoption

34:18 last twelve or twenty four months or whatever. Like, I'm I'm curious just when you speak to people and you say WebAssembly, is there an instant acknowledgement? We had a phase where people are like, oh, WebAssembly. Or is it like a, oh, what's that? Tell me more. Like, what's that like these days? I think the way that I have seen that evolve is just standing in front of our Fermion booth at KubeCons. And just a year ago at, KubeCon North America, so I guess less than a year ago, the first initial question of, hey. Do you

34:48 wanna learn about WebAssembly? There was immediate what? And now it's evolving to people already know what that is a lot of times, and that's been really interesting to see in just eight months or so how the just that experience of people walking by, they already know that. And oftentimes, they want to hear more and learn more. And we had several WebAssembly workshops at KubeCon. We had one about spin on AKS, and then WASM Edge had another one. And there were, like, 350 people at our session for this workshop hands on with WebAssembly. And then there seemed to be around, like,

35:26 200 or so at the Wasm Edge 1. So people not only are hearing about it and interested in it, but also wanting to get hands on with it. And it seemed like that's happened fairly quickly. Yeah. The session that I gave at KubeCon, like you said, I've I've presented at a couple of conferences and have been for a while now. And I can distinctly remember, you know, giving presentations when there were, like, three people in the room a total, and those three people didn't know what WebAssembly was. And then there was a a next step

36:00 where there were more interested people in the room, but none of them had really experimented with WebAssembly yet. And at this most recent cube con, the room was completely full which is a a totally new experience for WebAssembly for the WebAssembly community. And in addition to be there being people that were just interested in the technology, there were actually people who raised their hand for people who'd used WebAssembly in anger and had been building real things and deploying real things with it, not using a browser, which, you know, I'm actively trying to make that in the future

36:39 and that completely surprised me. I just had no idea that it was catching on that quickly. And, from the WASM clock booth and Cosmonic booth and just sort of walking around and talking to people, people generally seem to know not only what web assembly is but it's no longer a really really hard sell trying to tell people that WebAssembly has a place outside the browser. I think we're we're starting to get to the point where the early adopters and the innovation curve now includes people that don't just assume that WebAssembly is a browser only technology. And I think that's a that's

37:22 a huge milestone for the community. Yeah. I think it's it speaks a lot that a first edition of a new WebAssembly conference, WASM.io, that happened a couple weeks ago was able to draw such a great crowd. And this was something that was not attached to a larger conference like the WASM days at KubeCon. Those ones have been steadily getting bigger. Like Kevin said, we've had full rooms and whatnot. But even a brand new conference was able to pull in enough people to to, be extremely successful and and also, you know, the quality of speakers does is, I think, a

37:53 given because everybody in this community is very friendly and talented. But, yeah, it's been a steady increase, and I think the the rate of change is is increasing as well as people see things getting a bit more mature. They see examples of real word real world usage, and they start to realize where the use cases are, you know, filtering out to. It's definitely becoming, easier to talk about, easier to convince people of its utility, and you're finding a larger percentage of people just inherently already knowing it, which is great. And on the note of Wazamayo

38:35 and great speakers, I just wanted to shout out PJ Laskowitz, talk on basically all these different production scenarios. He's with the Omnify Foundation, and I was so excited by the end of his talk. He was mentioning how it's being used in production in medical devices, automotive, the edge. I it was just stuff that I had no clue was already happening in production. So if you wanna get excited about it as well, that's definitely a really, interesting talk to watch. Nice. So Kevin said something that kinda made me smile a little bit. And he said that WebAssembly

39:03 Browser vs. Server-Side WebAssembly Activity

39:08 isn't just a thing that we run-in a browser. From my perspective, and I'm not a front end dev. Right? So I've got a lot of bias here. But the Wazi server side WebAssembly stuff is probably being used much more than WebAssembly in the browser. And I don't know if that's just because I'm not in the front end world, but I have tried to write WebAssembly to run an browser from my website. And I just didn't think the tooling was as mature or good as what we have on server side WebAssembly. But I again, just from my perspective, I

39:36 think server side WebAssembly is moving faster and better than in browser WebAssembly. Yeah. I think I think people got to production with browser based WebAssembly first, like Figma, for example, and and Adobe and others. But I have just a is purely just observational on my part. Like, there are more startups and companies that have been formed around the server side of things, whereas the web browser side of things has been more just purely community and and, like, open source and not driven by companies and startups. So I think that could be contributing to why it

40:14 seems like the Wazee and server side part of it has been progressing faster or maybe there's just more noise about it. That's that could be at least from my side, that's what I've been observing. I think it depends on the metric you're using to to measure size. So, you know, WebAssembly in the browser has probably reached more people because it's in the browser. It's probably reached more people than you know, people don't know that they're using it. So, you know, Conor brought up Figma. There's it's it's making its way into all kinds of web based applications and it's just sort of a

40:55 an understood thing now. Adobe has applications on on the web that use the that use WebAssembly. So sheer number of people who, you know, have have hit a web page that's using WebAssembly is probably pretty high. But to Connor's point, I think the the real developer ecosystem growth right now is definitely happening on the server side. Yeah. I'm sure there's probably a Cloudflare report because they do these reports every year that talks about traffic and distribution and technologies being used. I'm sure web assemblies in there somewhere is a number, and we just have to find it. But I imagine those numbers are

41:39 pretty huge. But we are approaching the end of our session, and I I wanna just kinda throw out and talk about Docker's recent announcement and what that means for web to back end developers and WebAssembly and hybrid architectures. But, you know, Docker and container d, a couple of weeks ago, announced that we can now use container d to distribute and pull OCI images, which contain Wasm binaries. These can be run side by side with containers using something like Docker Compose and the container these shims even allow us to we've run Wasi to run these workloads in Kubernetes.

41:41 Hybrid Architectures with Docker/containerd

42:14 So we're seeing and what I'm excited about personally has been able to do a Docker Compose up and have, like, a Postgres or a Redis or whatever. My WebAssembly application running and all speaking to each other with no effort and being able to ship that to Kubernetes. And I'm curious what your thoughts are. Do we think that hybrid architectures with containers and WebAssembly side by side is gonna be the next big thing over the next, what, five years, let's call it? I don't know if it's the next big thing as much it is a a necessary step

42:46 in bridge building. So, you know, right now, like, we said, we all pretty much agree that the ideal future is one where you just build a WebAssembly component and then you choose where to deploy it based on the features of the host runtime you're deploying it to. It's no longer a technical concern. It's more, you know, just shopping for features. And to get there, we need to bridge between people's legacy code today and people writing greenfield WebAssembly components. And so one of those steps is to make it so that people can run certain types of WebAssembly workloads in Docker and,

43:29 you know, with run Wazy and things like that. I think it's a little misleading because there's only a certain type of WebAssembly modules that you can run-in these things. You know, if you're if you're building a WebAssembly module that uses a very specific subset of WASI, then it sort of just works. But if you need access to other types of runtime services, you know, maybe ones that you need access to through the component model or through proprietary interfaces. You can't get those in the Docker environment. So there's still a lot of work to do, but

44:12 it's a it's a foot in the door and a step in the right direction to get adoption going. So we start out with hybrid architectures and then, you know, eventually, we move to the the the pure electric model, right, where now we're not using we're not tethered to any of the legacy stuff. Our our greenfield stuff works just fine. I'm gonna do some more hyperbole here. You start your sentence with, yes, this is the next big thing. If you're not writing WebAssembly next to your containers, you're gonna lose your job and you're not gonna be a developer

44:44 anymore. That's what we need to tell people. Right? But that was your answer was too balanced. I'll I'll add it to the up. It's fine. Don't worry about it. Any thoughts, Kate or Connor? I would just say as a short answer, I do think containers and WebAssembly will live next to each other. And that will probably happen for a long, long time, if not forever. Because people might not wanna move their legacy code to WebAssembly. And, also, some things do are suited well for containers, like we said, those databases that maybe your WebAssembly module still communicates with. Whether Kubernetes

45:23 or Docker is the way you want to orchestrate or run WebAssembly, right now, it is a great stepping stone. Like Kevin mentioned, it might not be fully featured, and maybe it will become fully featured, or maybe there will be something else that will better suit running and orchestrating WebAssembly. Yeah. I think Docker is a very common tool for developers to have in their toolkit these days. They probably already have Docker desktop installed. And so Docker is essentially giving the WebAssembly community a bit of a a boost here where if a developer comes across WebAssembly, they're interested in trying it

46:05 out. Docker just lowered the bar in in terms of complexity to get started and try it out, which is undeniably a very important thing. Whether or not the, you know, Docker Compose method of combining containers and WebAssembly will be the thing that is, you know, shipped to production environments or whether it's even the paradigm that we use going forward, I don't know. And whether Kubernetes is involved or not, I don't know. There's obviously you can find tons of think pieces about that around the Internet, and I won't go into it. But I think, Docker is just such a well understood tool

46:45 for a lot of people at this point, and it's going to be as both, Kate and Kevin said, it's going to be a stepping stone. It's gonna be a bridge. It's going to be a step towards getting us to that next evolution where WebAssembly is just a fact of everyday life. We'll sometimes use it, sometimes not. Maybe we won't even know, and this is a good step. Awesome. Well, thank you all so much. It's been an honor speaking with you all. I'm now gonna allow you all just to have some shameless plugs. Feel free to share links, Twitter handles, websites,

47:15 Shameless Plugs

47:21 anything that you want of the audience, and I'll make sure that they are all in the show notes too. So we will work in reverse. We'll go with you, Kate, first, if you wanna start and take it away. Okay. Well, I guess you can find me on Kate Golden Ring at Twitter, but on Twitter. But for anything, if you're curious about Fermion and on how it does serverless web assembly, that's simply fermion.com. And you can get started deploying serverless applications to Fermion cloud, and we say sixty six seconds or less. So we're really about that.

47:52 Web assembly, easy to get started, developer experience. And that's, we mentioned key value a lot. And in part, we just launched key value support in the cloud. So if you're excited to see what that looks like right now, you can go ahead and try that out. Yeah. You can find me on pretty much anything at cohix, c o h I x, the hacky derm server on Mastodon, Twitter, blue sky, but I haven't logged into that more than one time so far. As for suborbital, like I said at the beginning, we help you integrate a plug in

48:25 system into your SaaS application, uses our globally distributed edge network to execute these untrusted plug ins, and the developers can write plug ins using a completely web browser based code editor. No local installs needed, and you can check all of that out at suborbital.dev. So Cosmonic is that's my product, and we provide a managed hosting environment for WebAssembly applications. And so you can deploy components. You can deploy modules. We have key value store up and running. We have what you deploy can have public web endpoints. And so we talked earlier about the need to orchestrate applications

49:18 and you can orchestrate a WebAssembly a distributed WebAssembly application in Cosmonic with no need for Docker. And, you know, the website is just cosmonic.com, and there's a there's a launch button in there for our free trial.