0:00 Introduction to Server-Side WebAssembly

0:00 Server side WebAssembly, where variations range from 0.3 to three to 25. In this episode, we get to chat with Mikkel about WebAssembly then and now, Spin three point o, Wazi 0.3, and Spin moving into a sandbox project for the CNCF. And Laura took her shot. She got us talking about the enterprise, FML. Of course, I had to. At least we talked about Ross. Enjoy this episode. Welcome, Mikkel. Thank you for joining us. This is Cloud Native Compass, and we are excited to pick your brain on everything cloud native Fermion, WebAssembly, and Spin. For anyone who is not familiar with you,

0:25 Technical Difficulties and Banter

0:37 Fermion, or Spin, please feel free to introduce yourself now. Thank you, David, and thanks for having me here. So my name is Miguel Marc Hannait. I am Danish, which is why you would hear that weird surname. I am the head of product and developer relationship at Fermi where I've been for and now I actually don't know whether it's two or three years. So you pick whichever one you want. I think it's actually three years. At Fermi we are doing web assembly. We talk about it as the next wave of cloud computing, which is why it's so well aligned with the topic of

1:01 Guest Introduction: Mikkel Mørk Hegnhøj

1:07 cloud native, hopefully you're gonna talk about today. Prior to being at Fermion, I spent more than ten years in Microsoft building various cloud services and developer tools there, which is also where I met Matt Adrado, who are the founders of Fermion, and how they sort of got involved in all of this. Excellent. Awesome. Thank you. Now, of course, I want to chat about Spin, which as of November, only a few months ago, released version three. The pace at which that project is evolving is fantastic to watch. But I think we should set a little bit of context

1:37 and just talk about WebAssembly and the evolution of that over the last three years if you've seen it. No surprise to anyone who's listened to this podcast before or seen any of my YouTube stuff. I'm quite bullish on WebAssembly. I think it's an enabler and something that everyone needs to start paying more attention to. And I'd love to hear your version of it as someone from the inside who's actively trying to make this possible for developers to adopt and succeed with WebAssembly. What have those last three years been like for you, and how is WebAssembly evolving? The

2:00 WebAssembly Evolution and Spin 3.0

2:02 last few years, and I actually think it's three years now that I get to think about it. Thank you, Laura. You're keeping straight. He actually says something about how quick time has passed, but also how much have happened. Like you have that weird paradox that you feel like time just like snaps away. But then on the other hand side, there's so many things have happened. And I actually think that's a good indication that a lot has happened. We moved, we really moved forward and just to think back to even November when we did spin three point and where we

2:31 are today, even all has happened. So yeah, so it's an interesting space. I think over the last three years, the whole ecosystem around WebAssembly has my first encounter with it when I joined Fermion three years ago was just trying to figure out what's even going on here, what's the ecosystem trying to accomplish. Lots and lots of really great and promising visionary stuff, but less practical things that were usable and approachable for people to actually do things with. Whereas over these three years that has really flipped. I think a lot of the visions has come to fruition and I hope we

3:07 get to talk about the upcoming Wazio three as well, which is another big milestone in what you can do with WebAssembly, but also seeing Spin and a lot of other projects in the WebAssembly space, really bringing this in the hands of developers that it's easy to get to. There's great developer experiences. You can easily build applications, manage services popping up so it's easy for you to actually run them. The ability to run things in Kubernetes and really try to get WebAssembly as a core primitive of cloud computing in all those places where you expect to,

3:44 or where you do cloud native computing today. And I think that's, I used the tagline, the next wave of cloud computing when I introduced myself. I think I did, something along the lines. But that's really what we think about WebAssembly here in the progression that we've seen from all the way back from physical servers to virtual servers to containers, and then being WebAssembly. And the new kid on the block in terms of that core primitive into how we do cloud native things. Thanks. There's quite a lot I feel we can dig into there. And I'm gonna try and knock you down.

4:13 Love that, the next wave of cloud computing. And I think we'll just, we'll leave this here. We're gonna come back to this to talk about how building WebAssembly applications and operating WebAssembly applications is different from traditional container based or VM based applications. Let's Yeah. Come back to that for sure. But you talked about Wazee 0.3 there. Yep. And I don't wanna be foolish, but I'm gonna try and see. When WebAssembly first came out, it was just the browser based sandbox. Wazee is what brought WebAssembly to the server. And I believe 0.1, there was no such thing as the component

4:43 model. The runtimes all implemented their own interface things. And then with 0.2, the component model came along and says, actually, let's have shared interfaces to provide shared behaviors with different implementations. And I believe the Fermion team was maybe not spearheaded. Maybe you were spearheaded, but you were definitely a major part of that conversation. As we progress to 0.3, is this us leading to something that is truly ubiquitous from a WebAssembly and server side point of view for people to adopt it now? Because in my head in one of the conversations I have, I'm I'm now gonna

5:02 WASI and WebAssembly Components

5:13 go on for ages and chat. When I go to conferences, I'm always going, web assembly, and waving my hands and trying to get people to listen to me. And one of the major concerns is the 0.2 from the Vazee. Isn't that too early? On opposite side of this, we've got spend, which is on version three, which is built on top of Wazi zero point x. So what is the stability here? How do we get people to There's two questions here. One, what is 0.3? Where is this taking us? And then it's Are we at a stable point for people

5:38 to start kicking the tires on this stuff? Yes, I like to think of these in terms of, if you were to look for stability, you should not, so WASI is a specification, let's start there, like WASI specification, right? And the specification typically has a long time to move from releases to releases in terms of there's a lot of alignment and agreement that needs to happen in the ecosystem, which I think is good because the specification needs time to prove itself before it stabilizes, because that's gonna end up being the foundation where, you know, main promise of longevity

6:12 of what you end up building comes in, promises of portability between implementations and so on and so forth. That's where you snap that to in terms of what the specification is. And there are definitely scenarios where some of that has more impact and is more important than other scenarios. So if you think about the runtime implementation, so for instance, WasmTime is one of the most popular Wasi runtimes that exist. I think there's a nuance to this is like how do you even apply your versioning concepts because wasn't time is I think version 25 or something like that, because they basically have

6:48 a way of saying every time we do a version, we do a major version release, and that's how you can think about the runtime and what they do. But what most people will end up taking a direct dependency on would be those, the tools and the implementations which they as developers would write against, SPIN being one of those, Which is a framework and a developer tool is where you're gonna meet WebAssembly in many cases. And there are other examples of SPIN as well, and more of these come up in various scenarios. And SPIN then across its major versions,

7:20 that obviously has support for the underlying specifications, but SPIN is I think is where that's at least been our approach to that project has been like, SPIN is where we're gonna give you the promises of backward compatibility and we have across SPIN one and two and three, which we're at right now as the major versions, kept the backward compatibility for things that we have been able to run previously, which means you can still run things that are not your SWSI-one even with Spin three point zero, so if you wrote into that specification, that's still supported at that point.

7:52 So I think it's important for people in terms of how they think about this, what are the tools they're gonna implement against, what is the direct dependency they have and do they rely on that dependency to do the long term support across the specification grabbing? At least that's how I think about it and knowing that we are early on with some of the specification pieces, at least I think it's important for the frameworks that people use directly that they help with the promise of longer term support and backward compatibility. Yeah, you've just, you talking there for a

8:23 few minutes has given me a kind of a eureka moment in my head. And I think I'm going to condense everything you've just said until a single sentence, and I hope you're not too offended. But I think from a developer standpoint, exactly what I want is slow moving specifications that I can trust to still be there, but fast moving implementations that can iterate and provide me what I need to be successful as a developer. Can I write that down? I'll just say that next time, Rob. Yeah, I've never viewed it through that lens before, but yeah, I want my specifications to

8:57 evolve slowly with the implementations providing that testbed to iterate advance, test things, kick the tires and all that. So I really like that. And even though the Wazee specification is 0.2 moving on to 0.3, these things have been in the works for a long time as well. WebAssembly is not exactly a new concept. It's been around since, I don't know just threw out a year and hope that I'm right. But I think it's like 2016, '20 '17, maybe I'm wrong. That's a great question. It is actually know what that was. Someone should go and Google it, but yeah. No.

9:28 But you're probably right. Yeah. So I was gonna say now I'm not as up on WebAssembly as David is. I'm kind of that person in the call. But last I remember, there was a move from building on top of I think it was Nomad, and now it mostly builds on top of Kubernetes. So from, like, an operator standpoint, I'm curious from that perspective of has that move been a significant one? Throw this out there. As you start thinking for like spin four point zero and whatever's next for web assembly, are you thinking that you'll probably stay on Kubernetes or do you think

10:04 you might branch out to try to encourage even more adoption? I'm pretty sure Kubernetes is the path to get adoption. I think if anything you will find in most companies that run Thing, is that you can be pretty certain as a developer, if you hand over a container to your operations department, they know how to run it. And they probably will use Kubernetes in 95% of the cases or something like that. So I think that's a given for sort of like the mass adoption. It's true that at Fermion we did create something we called the Fermion platform

10:23 WebAssembly in Kubernetes

10:40 on Nome to begin with, mainly because we didn't see a good solution to run other types of workers inside of Kubernetes than containers. And that was really the main thing why we picked up Nomad at that point in time because Nomad are able to run even just processes along with containers and other things and that's how we package that. So the big invention that happened there, was together with, well actually Microsoft did a concept called RunWasi which evolved into a way of providing a shim for containerd, the runtime, to not only be able to run containers

11:14 but also to run WebAssembly natively so to speak. So you don't grab a WebAssembly in a container, you basically run the WebAssembly directly. And with that component, it sort of saw like what we didn't take on at that point in time is you now have native WebAssembly support in Kubernetes by using ContainerD and using that shim, which means that it makes so much more sense to start running inside of Kubernetes. So if you take that compared with the breadth of adoption of Kubernetes, I think that's definitely the way forward. That makes sense. Yeah, and to add on more context there,

11:47 just because like this is now my dream saturation. We're talking about WebAssembly and Kubernetes, same as it. So if we bring in some rust Yeah. I was gonna say, where's the rust in here? Let's go. The reason that serverless workloads on top of Kubernetes sometimes have a bad time and get a bad reputation is because in order to actually start a container or a pod inside of Kubernetes, there are a whole bunch of assumptions that needs to be made. One is it needs to speak to the CNI and get an IP address. It needs to speak to

12:15 the Linux kernel and get C groups and namespaces and all this stuff. Meaning that the base or the bottom line for starting a container is actually measured in usually hundreds of milliseconds. Those are ways to improve that, but hundreds of milliseconds. Yep. And for why was something I don't think that makes sense. I believe it's who's always talking about the invocation of the startup time for WebAssembly binary is measured in nanoseconds and not milliseconds. Yeah. That is true. Yeah. Why would you take all of that performance improvements and throw it away just to run it on Kubernetes?

12:44 There's There's a lot of things that need to need to be challenged and changed there. And I loved what the Microsoft team are doing with to enable this because Yeah. It provides that new bedroom, found your framework that allows these web assembly applications to maintain velocity without sacrificing the runtime environment. Because Michael just said, everyone has Kubernetes. I don't even think Hashi corporate running Nomad anymore. They're a bit of a keep going too talking about Kubernetes. So That is Yeah. I don't know. The the fact that we can have our stateful container based databases running side by

13:17 side with a future of hopefully WebAssembly invocations, think is a a powerful future that we should all be aspiring to eventually. And it's it's just how do we get there? How do we onboard with developers? And I'm sure Michael's got all these answers in his back pocket. We can dive into that. Yeah. But how do we go from okay. We've got last easy 0.3 coming up. Hot on our heels. We've got spend cube now, which is open source and released to allow these people to run these WebAssembly workloads natively on Kubernetes, say by say, but from everything else.

13:44 We now need to get them right in Kubernetes application, WebAssembly applications. And now we're on to Spend three. Like, why don't you give us the TLDR? Why should people start paying more attention to spend and what did the V3 release bring to the table? So I think I just wanna make a small remark on what you said on the performance thing, because the way that I think about that, Maya, is that I think what we've done with Ron Wassey and SpinCube, so SpinCube being the project that pulls all these things together with ECHELM child installs and then you just deploy the Spin

14:13 app, but basically it's all the underlying technology stacked up and operators and so on and so forth, is we've ensured that Kubernetes is sort of a, that a Spin application, WebAssembly can become a first class citizen inside of Kubernetes, right? So when you operate these in Kubernetes, you operate them same way you would operate the container there, which also gives you the huge benefits that the whole ecosystem around Kubernetes just worked with this. Last week I did a recording of an introduction to SpinCube that involves showing how you can just apply a Kita scaler to your WebAssembly workloads, right? The

14:42 same way you do to your container workloads, which is a really good example of just fitting into the broader ecosystem, which I think is part of the answer to getting the adoption, right? Like the same way that operations teams or platform engineering teams provide platforms that support containers is really easy for them to enable now just supporting WebAssembly inside of the same platform that way. I think the missing piece there to your point about performance is work to be done to have Kubernetes being a first class host for WebAssembly, meaning that you actually get the full benefits

15:13 of, for instance, the scaling to zero and starting from zero, lack of the, not the lack of cold start, but the fact that there hardly is any cold start going from not having a WebAssembly component loaded and then loading it, we've done run times in that, around that as a commercial project for Fermiad, where basically we can host 10,000 applications, WebExplained applications on a single Kubernetes node, but we can't do that in the Kubernetes model because of pod limits and those type of things, which means we have to break out of that being the first class citizen. So there

15:44 is that trade off there, right? That sort of speaks to that. But I think being a first class citizen in Kubernetes is part of the road to adoption. So back to your question, David, about what we've done in Spin three point the main things that we have been focusing on in Spin three point zero is this idea of WebAssembly Components. And it's actually also a good sort of, there's a tie back to when we talked about WOSI three and that being sort of the next release of the specification. The major, the sort of the marquee feature

16:10 that WOSI three will bring in the specification is to be able to do combination of async and sync programming between components. So we might wanna talk a little bit about what WebAssembly components are so that we get an idea of what this is. So WASI stands for the WebAssembly System Interface. So it's basically a set of APIs that you need to implement if you create a WASI compliant runtime, which means that it's a virtual machine, it's like an operating system, so if you write a WebAssembly and using these APIs, you expect that WebAssembly to be able to run inside a WASI

16:26 Spin 3.0 Features and Future Directions

16:41 compliant runtime. But WASI is also just, so together with WSC, a way of describing those APIs and interfaces called WIT, which is the WebAssembly interface type language was developed, but it actually enables you to define your own set of interfaces and APIs through WIT. And what's interesting about WID is that WID operates, well, is meant to bridge the same way that a WebAssembly you can say is portable runtime because it's a byte code format and you have this virtual machine. What Wid enables us to do is have the definition that the programming languages now can

17:14 understand. So you can have a definition of an interface that you can provide in a Rust implementation and use in a JavaScript implementation, which means that you can actually have libraries, which is what we would normally call them when we're in a single programming language, from other programming language that you use in whatever code you're writing today. And in the WebAssembly world, we call these, when they're compiled, we call them components. So you can implement a WebAssembly component in a given programming language that you can now go and use in another WebAssembly component written in another programming language.

17:48 There's a path of this which is just polyglot development and then it's like, well I don't wanna break down my libraries in different programming languages, I use one programming language, already right. But there's another path of this, there's another way of telling the story, which is maybe it's the package manager and all package managers. Like, you know, if someone wrote a really secure and fast Postgres driver in given language, we don't have to write a Postgres driver in all these other languages when we're using the WebAssembly world because we can basically just use that component from other programming languages. So the component

18:21 model is a core focus in three point where now between these libraries we're actually able to combine synchronous and asynchronous functions that work inside of each of these components, unlocking a whole breadth of scenarios, particularly around streams and other things where you want to stream data with that, I think is one of the typical use cases that will light up there. Yeah. So this means, I haven't been keeping up with 0.3, so this is new to me, but I'm loving where else is going already. This is essentially like a distributed promise across any language where, again, if I got an async function

18:56 in JavaScript, it does a fetch request to our remote host, but I call that from Rust. It's able to handle the promise in JavaScript for a short no response, but it's handled at the WebAssembly world point of view rather than in each individual component itself. Is that correct? Yes. I said that like a yes and no rather than just a yes, but. Yeah, yeah, I don't know what the no would be, yes. That's really cool, I like where that's going. The main thing here that we've discovered is that there are certain frameworks and programming languages that

19:25 Distributed Promises and WebAssembly

19:28 like makes such heavy use of async. So one of the things that people may have stumbled upon when they've been looking into WebAssembly is like, but there are all these things you can't do, right? There's probably still like garbage collection, multithreading of things that people used to take on to, and there's definitely things, because it's not a full operating system, like it's not a full DIPC compatible thing like people expect other places. A lot of these frameworks just take assumptions that we're not able to honor WebAssembly yet, right? So it's just yet another step on this ladder of making more, I think

19:58 Frameworks and Programming Languages in WebAssembly

20:00 really the effect of this will be that more stock libraries you get from your NPMs and your cargo or your NuGet or wherever, we'll actually just work at WebAssembly once we have o three o working. That's really the net effect of this. People just compile down to one layer and everything can work together. It makes sense. Yeah. Yeah. Just preaching to myself here. I'm a Polyglot developer. I don't as much as I would like to write most things in Rust. Yeah. I definitely appreciate having that option to jump out to writing some goal where it's appropriate.

20:31 I like writing a lecture. I like playing with Ponyline. I like playing with Zig. If there's a language that's of an interest, I generally like to play with it. And I feel like WebAssembly and especially Wazi and server side stuff just allows me to sit down and experiment with all these things. And having spent the first ten years of my life writing nothing but C in parallel, you get locked into how things are done in those ecosystems. And it's not until you start experimenting and playing with more languages that I feel that I broadened as a developer and began to

20:58 Polyglot Development and Experimentation

21:00 pick up new patterns and new paradigms. And I think made me a better and stronger developer. I encourage people to look at it from that lens. Don't just set and rate go because the entire cloud native ecosystem is in go. There's a lot to learn from Lust and Elixir and Zig and all these other really cool languages. Just this week, I've seen a language library shared on Gab. Someone starred it, and it was an actor framework written in Swift. And I like distributed systems. I like actor based systems, and I've never played with Swift. So I went and lost three hours of

21:29 my day just playing and taking it down. But it's fun. You've got to find the moments as well when you're doing this stuff, right? That's what stops you hopefully from burning out and just having a smile on your face when you do. I mean, just the diversity of ideas that are implemented and concepts that are implemented, just like, I think enables you to reasoning about things in a different way. Just like hearing other people's opinions, which is also always inspiring. Definitely. Just hear that you're enabling David's Oh, Shining Syndrome is what I'm hearing. So that's very classic, it's very nice. Yeah, it

22:02 is. And I thank them for it. There's a very specific scenario that we did end up writing the other for a few weeks back because someone requested it, which was like, hey, I'm a JavaScript developer and I wanna do something really easy that I can ploy into low compute environment, but I actually wanna do image manipulation. What's a great way of doing image manipulation in JavaScript? We can just implement a component in Rust over here and use a really efficient Rust library to do image manipulation, expose the features to an interface defining bit and now you just wrap the ACP request

22:33 in your JavaScript and you call into the Rust component that actually does some of the heavy lifting, right? So I think there's another thing which is using some of these programming languages appropriately really easy. JavaScript is easy with ACP and JSON, Rust is not necessarily easy with ACP and JSON, but it can do other things well. So I think that's a good sort of more down to earth practical use case for this type of polyglot. Right. Yeah. And if we also expand the scope a little bit, people write servers, people write applications that run server sites. Some people write applications that

22:40 Practical Use Cases for Polyglot Programming

23:06 run front end. There's desktop applications. There's mobile applications. There's a lot of opportunity for interrupt, but they require you to use different language. Yes. Sure. You can use electron for desktop and mobile on our end. But we all like native feeling apps that work well within each ecosystem. Web Assembly gives us this wonderful integration point as well where you can have shared type definitions that can be consumed across the entire stack, which Yeah. I mean, I spent a lot of time doing this with JSON schema and GraphQL and a whole bunch of other type languages. And

23:36 then you're always compiling the language specific assets for this. And it's cumbersome. It's painful, especially when you go across multiple repositories and multiple projects and you've got versioning and distribution. Sure. I could throw all an MPM, but I wanna do that. No. And I think there's better ways now. And WebAssembly is front and center with that regard, at least in my opinion. So, again, I said I'm bullish. I'm not gonna even shy away from saying that I really like where WebAssembly is going and more people need to be doing this. So From an enterprise standpoint, though, it's actually very

24:04 useful because you're not really having to deal with a lot of the how do I chase the new thing that I need to do and get more developers to work on that, but I still need to maintain all of these tools and things that I've built that are running in older development systems and older languages. So you can't staff up for everything if you have to constantly move around. Whereas if you only had to have one person be able to build in this, one person be able to build in that, and they can build different components and put it together or

24:33 one team, I should say, an enterprise is gonna find that very useful. So I can definitely see the value there, especially if you're building on what is the de facto operation system, which is Kubernetes right now. So that makes perfect sense. We talked about a lot of the component stuff in terms of benefits it gives to developers. There are fun parts that you can do on the runtime side of things as well, and part of three point we actually released a feature we call selected deployments, means that you can define, so considering the scenarios, when you write a

24:37 Enterprise Benefits of WebAssembly

25:04 spin application that you can expose individual components, it's typically HTTP endpoints, right, because these are serverless function models, so you create an HTTP event, an HTTP handler. Within that handler you can take dependencies and other components that you bring in, but you can also split up the applications in multiple handlers. With selected deployments, what you can do is now if you go and deploy this into Kubernetes for instance, you can actually define which components you want to deploy on various node types or node pools inside of your Kubernetes cluster, even if there are some of

25:29 Component-Based Deployment in Kubernetes

25:34 them you don't want to deploy. So there are lots of benefits you can get on the runtime side once you have things broken out into components, one of those being this breaking up the application. Another thing we've done as experiments in other runtimes is de duplicating components. If you know Windows and dot net, there's a global assembly cache concept in dot net, I think it's actually dot net content, it must be outside of Windows as well. Anyways, I used to know about it from Windows back in the days. But basically at run time what you can do is, let's go back to

26:03 the example of the image transformation. Let's say 100 people deploys applications into your system that all makes use of that same image transformation component, we only need to host it one time and we actually unin the system and all of these applications and other components that make use of it will just run that. So there are lots of great things you can do there both in terms of less footprint at deployment time, but going back to your enterprise scenario, Laura, again, those things like how can you actually patch things in the system. But you can

26:35 just upgrade that one component if there's a security thing that needs to come in, now all the applications are using the updated, right? Even if it's in a distributed system and not necessarily on a single machine. That makes sense. Yeah. It's a good model. Yeah. Use the model. I'm just thinking in terms of massive enterprises with lots of things going on and just only having to fix it once and having to stay up once to do a deployment in the middle of the night is very nice. Yes. Instead of having to have four deployment windows

27:04 that I have to go deal with over the course of a week to handle a security vulnerability. Alright. Let's get away from the enterprise chat because we we we don't wanna offend the cloud native folks. And no. What I'm thinking is Don't they work in enterprises? Yeah. Small ones. Okay. Little ones. It's not that one. No. I don't know. Maybe it's just my cloudy judgment. But enterprises, I hear Java, Tomcat, scary stuff, virtual machines. Supposed like, bed work on here. Right? Maybe? What? Sorry? Java. I'm just kidding. David and just look horrified. I think she's trying to

27:36 convince you to build the web assembly Tomcat. No. Thank you. I'm good. I'm more just trying to horrify you, David. So, it's all good. Anyway, what was your question? No, I was thinking, I think we've said lots of nice things about WebAssembly. We're seeing momentum, there's pace, there's philosophy, all these wonderful things we want from a budding new ecosystem. The next wave of cloud computing, if you will, right? How are Fairmount approaching the idea of getting individual developers to say, okay, I want to write my next thing in WebAssembly? Because I imagine that is a challenge, right?

28:06 People are still setting their ways, we're ready to go and ship a container, second them onto Kubernetes. What does it look like? How I'm assuming you go to conferences, you speak to people, they have the moment, but they'll think, that seems really cool. How do you deliver that to the individual developer? Because then I'm sure they eventually go to an enterprise, but I don't care. But how do you put that smile on a developer's face? We showed them the thing, right? Hard to do in a podcast like this. I think one of our taglines like sixty

28:20 Developer Experience with Spin and WebAssembly

28:35 six seconds from blinking cursor to deploy the application. Like the light weight ness. I don't even know if that's a word, but it yeah, after the whole thing just to have been a I think it's enabled us to be able to create like one of the best developers experience I've been part of creating. To give you some of those examples, there's a simple CLI tool that you download, and by the way, we didn't talk about this yet, but both Spin SpinCube, the project to get things into Kubernetes, are becoming CNCF sandbox projects at the moment,

29:06 they're the process of onboarding, so this is now a CNCF based project. There are other CNCF projects around WebAssembly as well that people should go and check out. So it's been open source all along, but it's not a Fermi and owned thing anymore, it's now in the CNCF, which is super nice. You download a CLI and that's really all you have to do. You don't, and you need your programming language tool change and there are like heavy dependencies. I know container runtimes are probably almost everywhere again, so whether that's a heavy dependency or not, but you still need it if

29:39 you wanna run containers, And even if you wanna do Kubernetes stuff, you either run K3D or micro K8s, whatever you do locally and all of these things. None of this is needed here. So being able to go through that experience of having just a CLI, writing a simple function handler, running it locally where you could build in key value stores and other things that we can do again because of this whole WASI model, like we can plug in underlying data store implementation through those interfaces and being able to deploy that either into Kubernetes cluster and SpinCube or into a managed

30:11 service like Fermion Cloud, which is run these serverless functions at scale, That is sixty six seconds to have things in the cloud, which find it super, super hard to get to anywhere elsewhere. I know when people talk a lot about, typically when people talk about PaaS, they always end up referring back to Heroku as being sort of the golden standard of how you want to build a good developer platform. And I think we've actually come super, super close to that without having to lock people into particular programming languages or frameworks or other things that they can do because it's all

30:47 based of WebAssembly and the standards that are behind that. I hope some of those things are the things that would put developers smile on, which I thought was part of your question as well, David. Definitely SpinCube is one of those, like making it super, super easy to have a way, place to run these things, right? Starting to see some enterprises experimenting with lighting up SpinCube as part of their Kubernetes based platforms, really just gives developers the deployment endpoint that they need to start running these things. Yeah. I was really hoping that you went on the developer experience angle, and you totally did.

31:21 So that's fantastic because you mentioned Heroku there. And I'm old enough that I remember when Heroku deployed or launched, and I shut my first thing. And I didn't write a single config. I just did a get pushed to remote. It wasn't mine. It's the a Roku and all of a sudden, it knew what type of application I had. It put it into production and it's about a URL. And that was a moment. That was that's a eureka moment. That's wow. Like, deploying has never been as easy before. And I think for spend for me, and I can't remember

31:52 when this was or whatever, but it was when the spend add command was added and I was able to just add new multi language polyglot, whatever you wanna say, components to a single application where all the routing was handled for me and I could invoke each different thing easily. That was, oh, wow. This changes the game because it just gets rid of so many different challenges with RAIN applications. And that's why we look at Kubernetes and can you be successful with Kubernetes on its own? But really you need service meshes and you need server ability tools and you need

32:23 get ops and you need platform engineering and all this stuff. And then you get spend coming along and you just do spend deploy and spend build and spend up. And it doesn't matter how many components are. It just handles that for you. And it's like, show me a better developer experience, anyone. Like, that's an an open challenge. Like, I just don't think what it is. That's a bear with Okay. I feel like we're doing a nice journey here and we're getting close to wrapping up. But let's let's we'll put smiles on developer spaces. They see the magic. And now we're

32:51 talking about productionization. There was something that caught my eye. It was Ben v which was the OpenTelemetry integration. Yeah. Maybe you can share a little bit of light on as we move to pushing more WebAssembly into production, how important that is and what's coming next. Yeah, the main thing we did in Spin three point zero is actually to have the runtime being instrumenting the path to invoking your components. So think about it as a runtime, your app is like the guest running on top of the runtime, which means that out of the box, and there's actually a, we have column plugins to

33:23 the Spin CLI, the developer experience, so you could run a command called spin plugin install otel, and then when you do the local running of your spin application, which obviously is the command spin up, you do spin otel up, and if you do those commands, what you get is a local Jager instance that just immediately shows you the spans when you call into your WebAssembly components, and you can start imagining how you can see a span of the request came in, one component was loaded, that component called another component, may have called a third component, and

33:28 Open Telemetry Integration in Spin V3

33:53 when we get async, you can start seeing those things coming back and you just get all these spans and things out of the box. That also is translated into SpinCube, so when you deploy things into SpinCube, can either have a global or namespace scope or whatever your scope is, OTL configuration. So all the spin applications just start pushing traces and spans into your OTL instances. So I think the main thing there is just going where the ecosystem already are, right? Is where if you build a platform based on Kubernetes, there is a high likelihood that you have

34:25 some OTIF based monitoring system observability system already. So obviously these workloads just need to fit into that ecosystem as easy as possible. And again, taking it back to the developer experience is just take some of those concerns away because why? If we have a good enough solution that solves for the 80, if not even more use cases, why even make it your concern from the get go, right? You get stuff out of the box and obviously you could be able to start implementing your own stance and so on and so forth in the code that you write, but really

34:58 out of the box you get all these things where you can start just measuring the execution time off your component and so on and so forth and have that as you know, a thing you don't have to think about, but it's just there. Makes sense. Awesome. Yeah. All right, last question. What's next for SPIN? Main thing right now is actually the whole CNCF onboarding. It's quite a piece of work getting it in, and it will probably resolve in a four point zero, main reason being we have to do breaking changes of a bunch of namespaces and things in

35:29 there that were previously assigned with, or subject with Fermion as a company, which will now be, I think I have spinner spin framework, I don't know, think the GitHub is called spin framework now, where both spin and spin kupil land, as there's a whole bunch of work that we actually have to do to wrap all of that up. But obviously, Wasi three point zero is a little bit of a way out in terms of timeline for the specification, but our hope is that we'll be able to contribute a snapshot of Wasi three in the next release of Spin, and other than that,

35:50 Future of Spin and WebAssembly

36:01 I think we spend a lot of time on really improving the JavaScript experience. It would actually be more interesting to talk about the JavaScript SDK version three and the upcoming version four of JavaScript SDK, but that could maybe be another episode. But a lot have happened on the JavaScript side to make that a much more pleasant experience around Spin. Other than that, given it's a CNCF project now everyone is able to come and contribute to what the roadmap should look like and their ideas and what they would like to see from the framework. So I highly encourage everyone to seek that

36:30 out and be part of it. Good luck with that transition. Thank It's a good road to be on. It's a long road, but it's a good road. It definitely is. I mean, are we casting bets on when the Linux Foundation launches the WebAssembly Foundation? Because surely that's right around the corner. There's a DevRel Foundation now, so why not why not WebAssembly one? That makes more sense. That's fair. That's fair. Dora, I'll cut out. I'm not gonna mourn a bit on foundation on this. I could. Alright. Any last questions, Laura? No. It's just always good to hear

36:58 a little bit more about WebAssembly. And I know just itching David's, oh, shiny itch is always a good thing too. All right. Then we'll give Michael a chance to say goodbye. Do you have any parting words or Anthony you'd like to share with our audience? Oh, thanks. Thanks for having me here. Thanks for inviting me to come and talk about WebAssembly. It's always good to see you guys in person. Thank you for coming on. It's been good to Connor's right around the corner. Oh yeah, that's true. That's true. I will definitely be there. Also, there's

37:26 Wasserm.io just the week before, so if you rather go to Barcelona Thursday, Friday, and maybe stay over the weekend, I'll definitely recommend coming to Watson.io. There you go. There you go. Really good. Links in the show notes. I see you in London to everyone who listen. Thank you for joining us. Thanks. Thanks, folks. Thanks for joining us. If you wanna keep up with us, consider subscribing to the podcast on your favorite podcasting app or even go to CloudNativeCompass.fm. And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform.

37:40 Closing Remarks and Upcoming Events

38:02 Until next time when Exploring the Cloud Native Landscape on 3. On 3. 1, 2, 3. Don't forget your Don't forget your compass.