0:00 Introduction

0:00 Welcome to Cloud Native Compass, a podcast to help you navigate the vast landscape of the cloud native ecosystem. We're your hosts. I'm David Flanagan, a technology magpie that can't stop playing with new shiny things. I'm Laura Santa Maria, a forever learner who is constantly breaking production. If you want to learn about how the cloud native and container developer experience is broken and how WebAssembly can bring substantial improvements to your day to day, then this is the episode for you. Today, we're chatting with Laszlo Fugas, a self proclaimed WebAssembly skeptic. Laszlo responded to one of my tweets shelling

0:37 WebAssembly, and we decided to get together and share our opinions. Let's get to it. So, Laszlo, could you please tell us a little bit about you? Yeah. Of course, David. First of all, thank you for having me. And it's good to see you guys, Laura and David. So I am Laszlo Fogosh. I am based in Budapest, and I'm running a small company, a small bootstrapped startup called Gimlet. It's basically a GitHub space application delivery platform. You know, many teams are building platforms these days, and it's it's the era that we are building platforms. And that's what that's what

1:08 what I was doing previously. I was a consultant building these platforms and now I we put, all the knowledge and all the best practices into this tool called Gimlet. We have a SaaS and it's open source and you can go and check it out. And, yeah, that's about me probably. Alright. Thank you. So today's conversation came around because I was being lazy and looking to Twitter for to review my abstracts for events that I was speaking at. And the abstract was around me trying to talk about not in a clickbait way, but, like, what cloud native two point o is gonna look

1:26 Setting the Stage: The Conversation Origin

1:44 like because I don't think that it's entirely container based. And I've been doing a lot with WebAssembly. And you responded to my tweet and you called yourself a self professed WebAssembly skeptic. Yes. And I thought, you know what? That's a really balanced conversation where I am not bullish on WebAssembly, but I'm definitely leaning that way. And I thought it'd be good just to have those two points of view. And, you know, we've also got a lot of others and I wanna know where you used to land on the WebAssembly. I don't know, fence per se.

2:14 I am probably a little more cautiously optimistic just because I I've I've seen a lot. I've heard a lot about it. I do feel like there's a hype train going on, just a little bit. And I think I know who's driving said hype train. David. But, you know, that's that's okay. However, I do think that there is definitely a need for what it's doing. Unfortunately, with the world of manifests and all kinds of chaos and different things that Docker really brought to our whole world. And you think about just how much YAML we write on a daily basis.

2:52 And that's when you have this moment of, like, please someone save me from YAML and pages and pages and pages of it. Maybe that's just me, skeptical old sysadmin that I can be. So Alright. So, I mean, then it's perfect. We've got the left. We've got the right. We've got the center. So we're all Right in the middle. Right in the middle. Well, maybe a little more pro than con, but that's okay. It's alright. You can be less leading. I'll take it. But it means that as we have our conversation today, we can discuss the pros and

3:20 cons. We can have balances. We can understand what's important to everyone here. And then, hopefully, you know, we all leave with the understanding that I'm right. That's that's the ideal situation. Or we just, you know, throw things at our screens and then lock everything up. I do have my throwing device. It's okay. It's a a pink planet. In this visual medium that is a podcast. It'll be on YouTube too. People can definitely see what you're doing. I know. I know. But someone's listening on audio and wondering, what is he about to throw at and this is squishy, and I can't

3:52 stop letting it go. So, anyway, let let's let's focus. Let's not get derailed within the first five minutes of the episode. Right? All we've done so far is introductions. I'm very good, Seth, though. Alright. So I guess let's talk, actually, the abstract type of postage of Twitter. I gave the talk two weeks ago in Glasgow. And I'm just gonna get, like, the quick thirty second overview of what I think WebAssembly brings to the table in creative architectures, and then we'll start talking about the pros, the cons, and, you know, take a look at maybe where it's not a good fit.

4:04 Container Developer Experience Pain Points

4:20 Because, of course, it's not a catch all tool. Right? It's it's not gonna solve all the problems for everybody. But if we take a look at container based development today, and I'm gonna focus on development and then we can talk about delivery as well. I don't think anyone enjoys building micro service applications with containers on their local machine. And there's a few main reasons that that really just sucks. Right? Is that containers are not that lightweight. We're probably using Macs or Windows, and those have to run a virtual machine, which then my containers run-in. For interpreted languages, we have to sync loads

4:53 of code into that virtual machine, which is a slow and painful process regardless of which modern driver we're using and other virtualization features. To the point where, like, a a standard, not even a larger standard Python or PHP web app can take, like, a five second refresh and a change, and that's just not acceptable. Right? It's not a good experience. And that's assuming you've got one container, but if you've got microservices, so you're trying to run that entire thing locally. And, like, how many containers can you run-in your machine before it blows up? That's probably not that many. So then the developer

5:23 experience pushes us towards, like, shared dev containers, like, back in the nineties and the early two thousands. And I like shared development environments. So cool. But then this they have to sync the files even further or I have to build a container and push it to a private registry and deploy that. And, like, the whole workflow is a mess. Now I know there's someone listening right now who's good, just use Linux. I have used Linux day in and day out since 02/2001. And I can tell you that I like Linux, but I've never enjoyed using Linux. Right?

5:57 It's always something. Like What did you just admit? I mean, I was an Rk Linux user, so no one liked me anyway. But, you know, compiling my I three used to be the highlight of my week and tweaking my configs, but I was never really getting anything done. I spent more time nursing and playing and tweaking the config in the box than actually doing anything that was useful to my life or career. And, you know, when you go to Mac, things just work. The apps are nice. They look nice. You're not worried about a migration from x

6:24 11 to Weyland. And I don't wanna, like, completely segue this entire episode to be a certain minute rant about Linux because I like Linux. I'm just not gonna use it as my desktop daily driver. However, I don't know if Lazlo's looking at me with that discontent because he's like, I run Linux every single day. I was gonna say I do think the most hilarious thing about this right now is that Lazlo's on Linux. David, you're on Mac. I'm on Windows right now because my purse my personal dev machine is on Linux, but my work machine is on Windows. And so we

6:54 can have a lovely conversation about containerization across three different operating systems and how much of a pain that is to deal with, especially when you're on lockdown corporate hardware. I'm gonna add one more thing to the frustration bucket, and then I'm gonna let you both take it over from there. Right. So let's move past the fact that developing microservices on containers on a virtual machine on a Mac or Windows desktop environment that isn't Linux can be quite painful. Even if you get past that and you do run Linux, there's still challenges. One is that what if you want to build multi

7:26 platform container images? Like, we should be these days. Right? It's not just AMD sixty four, but we have to accept ARM sixty four Graviton processors, and AWS. Right? These are now becoming more commonplace. So you have to change your entire build pipeline. As much as Docker wants you to think that it's just a Docker build, it is not. There are tweaks and things that you need to do. It's just painful, especially again on my m one Mac where I pull an image and it says, we don't support Arm. Sorry. And then you have to go and use

7:53 Rosette or or some other crazy workaround. So yeah. I just don't think the experience is great. And I have a lot of sympathy and empathy for, like, people that are new to this that are on their Macs, and they're like, they just wanna get started. And they're like, imagine your first day in a job, and you're like, you pull you you're I'm on Mac. You're so happy. It's, like, amazing computer this company's given you. It's your first day as a developer. And then you see a warning message about not being able to run an ARM 64 container on side

8:17 of an AMD an AMD sixty four AMD sixty four container on an ARM 64 machine. So difficult. Right? Well, I'm definitely hearing you. I mean, I'm on Linux, so that that that's that's better. But I I occasionally have to be on those cross platform images and ARM has been an issue and I'm I'm doing go and sometimes I'm getting some linker issues, which is like a pain to debug, especially that I'm not on Mac. So I definitely hear you, and I do believe that there is a problem there. You mentioned the developer inner inner loop kind

8:27 Guest Perspective: Developing with Containers

8:51 of setup that people develop inside containers. Now, I'm doing containers since 02/2016 and, you know, developing applications and helping people and everything. And this inner loop, I never understood how can people, like, bear, like, developing in a container. It's just not productive enough. It's like it's it's it's not made for that. And I know there are tools and there are, telepresence and other tools which which you can use and all that. But I just I just wire my you know, I have this component, that component, all the boxes and the arrows between them. I just

9:29 rewire things in my head, and I just run my processes on my laptop. So I I don't develop inside a container. So, that's why perhaps my, appreciation of containers a little bit higher than yours that I just I just put this problem into a box and never open it. I think you're right. Like, I think the local developer experience just should be native tools as much as possible. I know we we try to get away from that because you don't want someone running node 16 and someone running node 18 and someone running node 20 across the team and all getting different outcomes.

9:59 But then it doesn't really matter. Right? As long as the test pass and you ship a container, that's the same on every production node. Yeah. Like, develop locally. I think that's great. But what about and if you get your microservices right, you can do that in isolation for a single microservice. But is there ever a cause, ever a need where you need to build that, run integration test against multiple services? Do you solely rely on automation for that? Do you try to do it locally? Like, what's your experience there? Yeah. So so microservices, I typically, like, work on just a single

10:27 service. So I'm not, like, developing 10 at a time, and I need to recompile all of them all the time. So, yes, occasionally, I start up a stack, you know, of of 10 applications that are my immediate dependencies. And I and I use those as like a static dependency, you know, could run on my laptop or on a remote machine. So it doesn't really matter. Yeah. I mean, I've dealt with enough pipelines and running pipelines and mostly so I've done the Docker within Docker thing way back when, which was hell on three legs. But to me, in general, like, if you're gonna

11:06 be building any kind of containerization and any kind of microservices system, you have to be running some kind of pipeline to test everything and put it all together on the machines you're expecting it to run on Just because there's so much different things going on that you're not you're gonna miss, like, this little bit or that little bit if you're running a system that is not the same. Like, maybe a weird networking error or some kind of load concern going across whatever system you're running. So I don't know. Like, I can kind of see the

11:39 we're trying to get everybody to run everything locally and make it look nice before it even ends up on your automation pipelines and your testing and everything like that. But if you don't have that pipeline, I feel like you're completely missing out when you're dealing with containerization because there has to be some kind of testing going on in there, and there has to be some kind of good work going on in there if you expect your containers to run. And, yes, if you are a brand new dev, it's complete chaos, you have no idea what's

12:08 going on. And you have to wait for some engineer to come and work with you, which is really, really disconcerting as a beginner. Or I can see that point. They could write WebAssembly applications. Or they could do that. But, you know, I don't know. Like, how much chaos is that bringing in? Well, I mean, when you write a WebAssembly application, there's there's no containers, there's no virtual machine. You work natively with your own tool chain, whether that be Rust or Go, Python, you know, the language support is almost ubiquitous at this point in time. And, you know, for go and Rust, it's

12:28 WebAssembly Advantages and Potential

12:42 just a compilation target. You just say compile for Wasm and it's done. That's it. You don't really need to worry about anything else. You get some bytecode that you ship and then OCI registry. You don't we know you're not throwing away all the good things that containers and that ecosystem has brought to the developer experience. I still like the docker push, the docker build model. Why not use it for more stuff? In fact, we already do it. So I don't know. It's like I don't think WebAssembly fits everything. I mean, get into that. But I think the developer experience is

13:13 solved. We don't need virtual machines. We don't need containers. The here's another thing. We talk about microservices. If everything was WebAssembly I don't think there's really ever a situation where that's gonna be true yet or maybe even in the next ten years. But WebAssembly's are binaries are super lightweight. Like, the startup time from a Wasm runtime to running your bytecode is under a microsecond or under a millisecond. This measures the microseconds. Whereas for a container, you're probably And the best case scenario, container startup is, like, three hundred milliseconds, four hundred milliseconds. So it's not like for a micro service

13:49 architecture, you need to run every single container or you would. But in WebAssembly, you would just have little pointers to WebAssembly batteries that could be spun up on demand as requests flow through your architecture. And I think that's really powerful. I think it opens up new patterns that we probably haven't been able to take advantage or seen before. Now there was promise. I don't know if how much attention y'all were paying in, like, 2017, '20 '18, but the concept of Unicarnals was pretty big. And in fact, Docker bought, like, the Oxford based Unicarnal company. And now we've never seen unique kernels. I

14:24 don't know if there's a correlation there, and they wanted everyone just to use containers. But the the promise is nice. Like, every HTTP request that comes in, you get a micro VM that spun up, answered it, and shut back down. And that model works quite well. Can I latch onto one of your sentences when you said, like, if you want to, you know, compile for WebAssembly, it's just a compiler target? And, you know, you have your application. You compile it. It's the WebAssembly bytecode, binary, whatever and then it just runs. And that feels like a very amazing scenario. So all the

14:39 Skeptic Question: Can Existing Apps be Recompiled?

14:58 things that you said, it just sounds amazing. But my question is: can just recompile all my application to WebAssembly today? Or if not today, is it really the goal and will we reach this point in time where we can just recompile everything and be in this wonderful place that you described? Yeah. Good question. Can you take an existing application and compare it to WebAssembly? No. It's not gonna happen. Will it ever happen? I don't think so. The way the server side WebAssembly works at least is that there's a whole bunch of abstractions via the component model. So let me talk about WebAssembly

15:20 Understanding the WebAssembly Component Model

15:39 a little bit. WebAssembly is a very constrained sandbox that runs in your browser. It can run-in other places that doesn't have access to fail systems and networking sockets, any of the stuff that we have to spec from standard POSIX. Right? Because of that, anything that's built without any of those requirements probably could be compelled to WebAssembly and go run-in your browser. People have actually compelled Git to a WebAssembly module, and they hook out to the fetch API and the browser to get the repository and do other stuff. However, very cool. But we need to if we wanted

16:12 to service the WebAssembly, we we need these things. We need sockets. We need file systems. We need speak to databases. We need caching. We need you know, we don't wanna throw away service mesh and a good stuff there. We wanna retry logic. We don't wanna build a center applications because the WebAssembly should be small and lightweight and compact and all these other good things. And that's where the component model comes in. It's like, okay. We're gonna give you a sandbox to run your WebAssembly, but we're gonna expose things on the outside via these APIs. So you have the ability to call open

16:36 on a failed scripture or close or read or write. You have the ability to open right now, you can't open sockets because they go make an HTTP request or a Redis request or a Postgres request, means that if you want to compile existing applications to be server side WebAssembly on these runtimes, the way that they communicate with Redis and HTTP and Postgres and MongoDB, all these other good stuff would have to be conformant to the APIs and abstractions provided by the component model. And what I think is gonna be a side effect here, and I haven't

17:04 seen anything to confirm this yet, but I I really hope is that these interfaces we have in the component model will probably filter through to container based applications at some point. I I think they'll they'll provide, like, a substrate for all future application development where we don't need to have, you know, people build and bespoke performing MongoDB APIs and stuff. We can you know, if I don't know how much of architecture geeks you are. Right? But there's hexagonal architectures, ports and adapter architectures, that's onion architectures, there's clean architectures. They're all the same thing with different names that people have just

17:35 signed to promote over the last ten years. And the component model really resembles that. It's the ability to write a small piece of code that says go and write something on a database and write this file and speak to this HTTP endpoint. And those components can be swapped out with any other implementation whenever you want because they're all little LEGO bricks. And I think that is really neat from the WebAssembly component model stuff, and hopefully, it does leak over. Did that answer your question? It did. So it's it's kind of an SDK that I have an API that I

18:07 can call to do, like, you know, important stuff. Yeah. So if we take, like, a Wasm runtime just now, like Wasm time, WasmR, WasmCloud, WasmEdge, there's a whole bunch of them. Right? Right? You basically can just run a WebAssembly file. We're doing Wasm or Wasm time file, and it runs. Right? If it doesn't use any components, it's fine. Now if you want to enrich or augment that runtime with new functionality, like, say, I want to provide the ability for them to call Postgres APIs, issue the APIs, etcetera, then you just add on the components as

18:38 part of the bootstrap. So every WebAssembly module that you run, you get you you kind of remove that ambient privilege. Right? Because I'm a POSIX container Linux based process, I can speak to every network in the world. I can speak to all the file systems. I can read memory and all that stuff. But the sandbox, you have to be very explicit and say, actually, you can only speak HTTP. And we only used to speak to these domains, and you can only speak to Postgres, but you can only speak to these tables or these databases as issues or this all

19:05 becomes infrastructure platform stuff. Your application developers don't care. It's just do can I can I speak to this table? That's all I really want. Can I get rows from it? Can I can I pull down what is my IP.com? Whatever. Right? I I think that's a a strong distinction between where we are to see with the service development. It's very different, but I think it's very powerful. Gotcha. So so let me just just explain, like, my background. Why am I the world the biggest WebAssembly skeptic, which, you know, like, like, I I I am proudly wearing this badge, but not because

19:26 Laszlo's Skepticism & Serverless Comparison

19:38 I know much about WebAssembly, but more like, you know, when you are on Twitter and when you're reading news, there are many things come come come at you. And then you have to sort of put them into little buckets. This is important. This could be important. This is absolutely not important. Like, you know, you put crypto in certain boxes as well. And then here comes WebAssembly and and then I and, you know, as as a person who is like vested into in in in containers and in in platform engineering and Kubernetes and all that, obviously, you have to be on the lookout

20:09 of what's coming and and and what's gonna change this this ecosystem and and whether WebAssembly is something I should, like, focus on, like, very much or it will be handled for me by the tools I have already. And that's sort of the question I'm I'm trying to gauge here. And also, like, a very similar situation I was in, like, six five, six years ago, 02/1718, then Lambda, Amazon Lambda came out and there was a huge push. Like, everything everything is gonna be a function. Everything is gonna be Lambda and your containers are already, deprecated even though you haven't really used them

20:44 in production. And then, you know, you you have to sort of put these news somewhere, and, and then I put Lambda into the, yeah. Well, could be useful for certain things kind of box, but, but not for me, kind of box. And and I'm just following the the the WebAssembly news from a certain distance. And then when I'm hearing, you know, like news, I try to sort of, like, match against my previous assumption. Does it change something? Does it, like, reassure me? And and and I'm picking up some some news here and there. And and the

21:17 thing that you said as well, that WebAssembly is more like an SDK. So it's it won't be like a general purpose application modernization platform. It's more like a a really cool tool that allows you to do amazing things like much less hassle than with containers. And overall, you can have a much better experience than all the container people. But it's you have to be sort of in a in a privileged position to actually use these technologies or you're you're you're you're getting where I'm I'm I'm trying to go with this. Right? Yeah. Don't imagine it's an easy sale.

21:50 Like, I can imagine Laura going back into the office tomorrow and going, I just had this amazing conversation about WebAssembly, and we should just rewrite everything now. Like, it's just Everybody's gonna look at me like I grew three heads. I mean, like, the the fact that I'm looking at is so there's a couple things. One, every time somebody comes up with something that's gonna revolutionize the system, my question always is, why are we making another tool versus dealing with some of the underlying problems? Now in this case, it does feel like it's dealing with some of the underlying problems,

22:01 Laura's Skepticism: New Tools vs. Fixing Problems

22:22 absolutely. But I'm I'm always a little skeptical when somebody says, here, just use this tool, and it fixes your problem. Always skeptical of that because to me, you're just creating more problems. It's kinda like the x k c d except backwards. You know, how many standards do we have? Oh, we have another standard. Well, it's how many problems do we have? Oh, we can make it so it's only one problem. No. Now we just added another problem to it. So I'm I'm always a little worried about that because to me, it's more about we're abstracting

22:52 away so many layers as we as we move into containerization and things like that. As we've as we have moved into containerization, we attempted to abstract away networking. Well, we added virtual networking. Good luck remembering both. We, you know, we try to do all of these different things. So when I hear that, okay. Well, we're now taking all these things and breaking them out into modules that now you can, like, plug and play and change all this. I'm like, okay. So we have regular networking, virtual networking. Now do we have another version of networking? Is it always gonna be DNS in

23:22 the end? Like, that's always my question when I see these, especially thinking through all of the different layers beyond just I'm developing my application to how am I gonna run it? How am I gonna maintain it? What infrastructure do I need to be on top of? How does this affect that infrastructure? What am I gonna do here? So that's my question to you is why are we making another tool, and do we really need a platform for any of this? Like, maybe I'm just going down the rabbit hole here, but I'll ask this to both of you because both of you are

23:52 talking about platforms like they're the best thing ever, and my response is, why? So, you know, when it comes to WebAssembly, that's part of where my skepticism comes in. And that's why I'm in the neutral zone of, like, cautiously optimistic that maybe it'll fix some things, but what new problems is it actually introducing to me? Yeah. You were in a neutral zone, but now it's like, et to Laura. You've just went complete build skeptic on me. So I am playing the devil's advocate here. Let's hear it. So let's let's address all of these things at the same time. I'm gonna do my

24:21 Addressing Critiques & WebAssembly Use Cases

24:25 best. So, Lasse mentioned serverless. Right? I think you were right to be skeptical about serverless. The idea like, serverless was was really promising when Lambda launched. The idea is that we could take JavaScript codes, run it in a VA isolate, super fast performance, do lots of really good things. It's amazing. However, people wanted to do more in Lambda. And now Lambdas are essentially they started doing, like, container layer stuff where you could, like, pull layers from containers and bootstrapping them, and so you could run other commands, use other languages. Now they're all running in, like, Firecracker virtual

24:58 machines. And it's really just got to the point where you could do some really powerful stuff with it, but you then have to kinda go all in on AWS. And that means paying for other managed services using their VPCs, using their managed databases, using their everything. Is it right? I'm not a big fan of that approach. I think that's probably helped several of us back. Now we do have open source things, but they're all container based. And again, we can't fix the code start time with the containers. Mean, speak to Alex Ellis. He's been trying to fix this for open

25:26 fast for, like, what, seven years. The problem is they have to start using proxies in the containers to then keep your containers long running and scaling them on demand based on traffic. And there's a whole bunch of complexity there in that too. And if we just use WebAssembly, people can write in their own languages, compile to common target, be in retro components, and you get a lot of the benefits. However, I don't think applications should be full serverless. I don't think applications should be full WebAssembly either, which does resemble the serverless model. Right? Request and spin it up, shut it down,

25:57 keep on trucking. I think we still need containers. I still I'm never gonna run a WebAssembly database. I don't think so at least anyway. I mean, I'm always gonna use post credits and that's gonna be a long running container based application that does Linux file system stuff. I want that to be performing. That means hooking into the kernel and doing all bunch of other things. Same stream processing, you know, Kafka's red pandas, all this other stuff. And if it was state, I probably would just want it to be in the container. But I think user facing stuff, asynchronous stuff,

26:25 reactive event driven stuff, probably can and hopefully will be at some point built on WebAssembly's parameters. But that's from the cloud native point of view. I'm gonna loop it right back again to, like, speak about Gimlet in a weird way. It's like you're kinda talking about WebAssembly skepticism. But WebAssembly doesn't need to just be like serverless functions. It can actually be used to extend applications. Like, imagine being able to run your Gimlet container inside of your Kubernetes cluster and you want to allow people like me who, you know, I'm gonna use Gimlet and do this

26:56 thing. But to change the behavior, extend the functionality, build in different source transformations to the the entire GitHub's pipeline, whatever. You don't wanna just say cars and bring in more containers. It's just over very bloated. But you could provide a WebAssembly module with a certain interface and say, I'm gonna call this function in your module. I'm gonna pass you on a string of bytes, which is all the YAML. You can do your transformations and then spit it back out. And we're seeing this with desktop applications. Will Versus code be WebAssembly extension point at some point in the future? Yes.

27:26 Helix, one of the terminal editors has a WebAssembly in potential. There's Zellage, which is a terminal multiplexer retina rust that has a WebAssembly extension point. I think it's just a really because that runtime is so ubiquitous, it doesn't rely on Linux or architectures or anything like that. We can stick it anywhere and everywhere. Like, your iOS and your Android phones could all be running WebAssembly at some point under the hood with a send wrapper and a thread that's just the native components. So I think the versatility of it pushes it beyond what we've seen with Lambda and

27:56 serverless. It could still provide that style of functionality and execution, but the promise is much more vast and I think that will appeal to developers. Not that you can ever learn, a single language and a single completion target and build every application of the world, but I think WebAssembly gets you pretty close. Yeah. I I do I do like the idea that someone who has learned a language and learned it well, not like just, you know, taking a boot camp, but learned it really, really well, will be able to actually build something without having to know all about virtualization and

28:27 containers and this and that and the other, or how AWS works, how to find your way through all the AWS mess and just deploy some kind of serverless thing. I do like that idea. That is the one thing that I was gonna say is probably the biggest benefit to WebAssembly to me is that it removes a lot of roadblocks from people trying to get something out the door or, like, people wanting to work. Like, I'm a I'm a Python person. David's a Go person. I'm not a Go person. Mostly. You take that back. Okay. Fine. Pick a

28:55 language. I'm just trying to pick something. I'm trying to help you here, dude. But going through and saying, like, if the two of us wanna build a application together, I can work in my language because I know it very well. David can work in his language because he knows it very well, and we can compile something together. I do like that without having to know about containers and how to make everything work in between. That's kinda nice. Yeah. Definitely. I have written a lot of Go code just for the record. I'm not saying that for bad about Go. I know. I I

29:23 do like writing It's mostly because when David and I worked together, it was one of these things. Like, whenever my Go broke, I went to David and went, help me. It's not working. Well, yeah, I'm not in the unfortunate position that I work with so many languages that I'm terrible at all of them. Like, I I don't really feel that I'm good at any language anymore. I I every time I write Rust, I put Go in there. Every time I write Go, there's some Rust in there. And every time I write some PHP, there's some Haskell.

29:43 And I'm just like, can't remember how to do anything in any language at all. But that So what happens when you try to write Python? I I mean, that's when I just asked you for help. I can't even keep up with Python. Like, I was told that is no longer relevant. I should be using poetry. Black's been replaced by something called ref, and I'm just like, what? Like, the tool chains have changed in twelve months. Yep. So Yeah. Miracles. Anyway, sorry. Let's look at told you. Once we start talking, we're it's we're not it's not

30:12 even gonna be about WebAssembly anymore. We're just gonna go off in some random tangent. Alright. I mean, we're how how are we feeling about WebAssembly right now? I know I've kind of rambled a lot and tried to hopefully distill some of the good things about WebAssembly. I I mean, I hope it's had a positive impact in where we're gonna sit. Like me, Laszlo? Yeah. Yeah. Okay. Sure. So I I like where this conversation is going. Containers are not gonna be replaced with WebAssembly. That's that's a good good outcome for me. Plus, I think you conferred to me that

30:16 Reflecting on WebAssembly's Role

30:43 that there are these WebAssembly primitives and then you build the castle from from those primitives. And and I actually liked the interoperability kind of use case that you that you described. I also like to bring in another use case like with containers and and Kubernetes and platforms. We are all want to build the next Heroku or at least for for some time, we were trying. Yeah. And maybe it's not gonna happen for Kubernetes, but it's gonna happen for Web Assembly. I I can more easily see that because it's a it's a it's a limited problem space

31:17 to solve. There are these primitives and so on, a lot less ground to cover. So perhaps maybe the next Heroku is gonna be WebAssembly. And I'm gonna be cool with that. Yeah. I think it would be a lot easier to build the next Rawkode on WebAssembly. I mean, if we look at all the people trying to build platforms today based on containers, I mean, there's a I mean, it's it's not easy. Right? Like, people give you your code as a container and you just run it somewhere and the job's done. But, actually, there's a whole lot

31:27 Comparing WebAssembly Simplicity to Kubernetes Complexity

31:43 more to it. Like, let's take a look at running an application in Kubernetes today, right, in 2023. Yes. Can you rate a deployment YAML with an image tag and just run it? Sure. Why not? Is that a good idea? Probably not. You need network policies. You need seccomp profiles. If you have SE Linux, AppArmor, Evan running on a host, you have to satisfy those constraints too. You gotta run your container not as a root user. If you then consumes persistent volume claims, you've then got to juggle the permissions to make sure that you've got great access

32:17 to it if you need it. There's I mean, that's just you think that your service machine, your retry logic for network requests. I think WebAssembly, a lot of those disappear because the sandbox isn't is, you know, is is not politics. It's not the Linux kernel. It's not a Linux elf binary. It's its own thing. Different characteristics is built with sandboxing in mind. It's really difficult to do hard things in it, which could be a stumbling block too, but that's another thing. But I do like where, you know, Docker I mean, let's in fact, we didn't even address

32:45 Docker's Investment: A Sign of Longevity?

32:49 that. Right? Who invented containers? Docker. What has every Docker feature request included in the last 12 well, okay. Who made containers acceptable? Wait. Who made containers accessible? Okay. Okay. I was gonna say, hold on a second. There was more to containers before Docker came along, but Docker didn't make it as a whole. Before. Blah blah blah. Nobody was using them as a Google. Come on. So Docker's what put it in people's hands. And, you know, if we look at the last twelve months of Docker releases, they're all WebAssembly based. Right? It's all about bringing in

33:21 WebAssembly support to Docker desktop, to Docker Compose, to the Docker Hub, shipping images with Docker build build and push and pull. The fact that they are so heavily invested in containers, they need containers for them to be a profitable successful company, which they've struggled with. And they're now investing all this effort into WebAssembly. It's just that little tick for me that this is something that has a bit of longevity to it, something that a company like Docker is investing in. They see the promise of containers and WebAssembly set by site. And that's yeah. Like, it's a big tech. I

33:51 think that just affirms everything that I need to know about my joy of working and promoting WebAssembly too. And and just maybe maybe a final thought that actually I'm I'm picking up that news as well because, of course, I'm I have to, like, hedge my bet. Like, I'm in containers and, you know, I'm building platforms for companies and stuff and I know containers. Should I, like, learn the WebAssembly world? And and I'm hearing this news that, hey, I actually, maybe today, I have no idea that I could run a WebAssembly container on, you know, on on container d or maybe even in

33:59 Integrating WebAssembly with Container Runtimes (runwasi)

34:24 Kubernetes. It's probably not true. So please tell me what's the state of this. But if if things converge like this, that's actually very good for, you know, both the old and the new world. So I'm I'm pretty pleased with this direction. So the good news is that you can run your WebAssembly side by side with containers and Docker or Kubernetes using the container called run Wazee. And the way that this works is it runs a container with a long running process, which is the Wasm run time. So that'll be Wasm Edge, Wasm Cloud, Wasm or Wasm

34:55 Time, whatever one you choose to use. And at the event, spin up the WebAssembly modules and response to request coming in. Actually, not dissimilar to what, like, OpenFuzz does with their Well, it should be proxy that opens and runs functions. So it's the kind of the best of both. I mean, you still need the concept of container for container d. It still needs to run a long run-in process and hook up networking and handle all the permissions and the services and all that all that boring stuff. Right? The plumbing. But your WebAssembly module just has taken a

35:29 little thing that's inside of it and gets executed every time when you request something. And it works really well. There's a little bit of a faff right now. So the container, the shim shims out to the host to run the WebAssembly, WasmR, WasmTime, etcetera, runtime. So you have to make sure that your nodes have those binaries available right now. There is a project called k Wasm. It's available at kWasm.sh from the liquid reply people in Germany. Runs as a daemon set, and every time a new node comes into your cluster, it literally just downloads all the binaries and sticks

35:58 them into the user local bin for you. Shouldn't need to exist, and they hope to deprecate it at some point. But for now, it's the easiest way to get started. So, yeah, you you kinda can. And you know what? It's nice. Like, the OCI image that your WebAssembly module is kinda pushed with is teeny. It's, like, five meg to eight meg depending on the complexity of your application. At least that's what I've seen when I've taken my real world Web Assembly and pushed it. I mean, if we compare that to a container image, it's rare that they're less than what? Fifty,

36:27 sixty meg. And then in the worst case, I've seen images with gigs gigs and gigs and gigs inside of them. Just because, again, optimizing container images is not something that you do by default. Right? You do from Ubuntu, apt install, everything in the world that I need, compel this thing, and then execute a tiny little banner at the end. You then have to go learn, oh, multistage builds and I can chain commands together to remove the cache and I can do all these weird things. Right? You've been in a container space long enough. You've done all of this. You

36:56 have to learn it the hard way. Whereas the WebAssembly is just build, take a little module, off you go. It's quite nice. So I'm curious based on everything we've said and the fact that, Laszlo, you're you're building Gimlet, it's a GitOps platform. Like, do you is there anything in your head that's thinking WebAssembly could be a value add here and that positive? Could I extend Gimlet in a way with this? Like, same me up to write the first plugin, but I'm curious. What do you think WebAssembly could could bring to it? So so I learned a lot. So so I

37:05 WebAssembly for Extending Applications

37:29 I was the world's biggest skeptic not because I knew stuff, but but because I'm just picking up some news and it's still in the same bucket. But you are mentioning some use cases, which I don't fully see the, the full scale of, like like what can be achieved and stuff and how can it be utilized. So you definitely, put something in my mind. And when I'm hearing news, I'm gonna put on this lens as well. And I'm gonna try to to entertain the thought a little bit more. So that's and and honestly, I I learned

38:00 a ton. So it was definitely moving my WebAssembly appreciation to the right direction, like to the David direction. It's still on on that that side of the spectrum, but, you know, it's a it's a step. I'll take it. Over you, Laura. There you go. I'm still cautiously optimistic, mostly because I haven't had a chance to really play with it yet. I think once I get a chance to really get a really tough spend some time with it, I think is when I'm gonna start seeing a lot of the benefits that you're talking about. But for now, you can you

38:33 can still put me in the cautiously optimistic camp because my skeptical ops brain is still kinda like, what am I missing here? Because it can't be all rainbows and unicorns the way he wanna paint it. Well, what we could do We'll see. Is take something in the calendar for twelve months from today where we get back together and we see where we are. Right? Alright. I mean, I I am very open. There's your remind me. Exactly. Right. It'll be in my calendar any moment now. But, yeah, I think it'd be fun just to see what was ready, what was wrong.

39:07 Are we seeing adoption of WebAssembly, it's safe by saying containers and Kubernetes? I mean, I really hope so. I think there's a lot of benefits to people adopting this pattern. So we'll see. There's definitely some stuff there, and it will be interesting to see. I think in a hybrid cloud world, like, to be brutally honest, like, I'm seeing a lot of hybrid cloud world and private cloud discussions and repatriation of workloads, especially in enterprises. And I'm just really curious to see if this might, change some things, maybe get some people off of Java in Spring where they've been living

39:40 for decades. Probably not. I can dream. Please let me dream that I don't have to do any more Java. So so the good news is you you learned Java twenty year or fifteen years ago. You learned Spring Spring Boot, like, ten years ago, and and you can use that knowledge ten years from now. Mean, it's it's kinda like still knowing Fortran. Right? I can always find a job knowing Fortran even fifty years from now. Who knows? David, here here's my statement. When they make Fortran a WebAssembly, then we know it has reached the big time or jumped the shark.

40:17 I'm not sure which one. It exists. There you go. No. No. Sorry to burst that bubble so quickly, but now you're that's it. You're you're converted. Yeah. I mean, the language support is ridiculous. If you just Google for WebAssembly supported languages. Like, the slide I had up, I talked two weeks ago, I had 40 languages on it, and that was me just picking the the best ones and the worst ones. Like, the fact that brain fuck can be compelled to WebAssembly tells you everything that you need to know. So It does tell me actually a lot that

40:53 I need to know. Okay. Actually, that really does. Alright. Loll code? Rockstar? Anyway. I don't think Rawkstar does. I I think that's been done. Okay. But I'm sure we can hang down and tell him to get all over that. So There we go. Alright. Awesome. Thank you both for entertaining my I don't know. Not rants, but, you know, WebAssembly, admiration, adoration, whatever the word may be. I'm not entirely sure. I wanna put little stickers on your video of, like, little fan, like, signs. Yeah. If you if you wanna edit, you can feel free. I I'm happy to give

41:08 Conclusion & Final Remarks (Including Plugs & Outlook)

41:28 that up. So, Laszlo, do you wanna do you wanna share any links to your projects, your Twitters, your GitHub, your LinkedIn, anything like that before we wrap up today? This is the shameless plug moment, so take take it away. Yeah. Sure. Shameless plug. Do it. So I I only have Twitter, and I'm so sorry about that. So that's Laslow CPH. And I know there are there are these other platforms. And I'm also a Twitter Blue, which I don't know how to get rid of. So please don't don't judge me. I said, like, I did that through. I said,

41:57 don't because I wanted to do it. I wanted to sorry. I I wanted to take advantage of, like, the more than ten minutes, ten eighty p video because I thought, oh, I could push all the video through Twitter. And then I canceled it because I was like, this is shit. And Elon Musk is well doing really stupid things with the platform. And it it didn't go away. It stuck with me. I stopped paying, and I had it for, like, three months. Exactly. Exactly. It's there. It's there. It's like they're reviewing, like, every, I don't know, forever.

42:21 Anyway, so it's Lasso CPH on Twitter and Gimlet.io on the InterVabs. So, please check this out. And, yeah. There we go. Thank you for, for having me and, teaching us WebAssembly. Alright. Appreciate you. Thanks for coming on. Thank you, Laura. 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. Until next time when exploring the cloud native

42:56 landscape on 3. On 3. 1, 2, 3. Don't forget your compass. Forget your compass.