Welcome to Cloud Native Compass, a podcast to help you navigate the vast landscape of the cloud-native ecosystem.

We are your hosts. I'm David Flanagan, a technology magpie that can't stop playing with new shiny things.

I'm Laura Santamaria, 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 are chatting with Laszlo Fogas, a self-proclaimed WebAssembly skeptic. Laszlo responded to one of my tweets shilling 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 Fogas, I am based in Budapest and I'm running a small company, a small bootstrap startup called Gimlet.io. It's basically a GitHub space application delivery platform. Many teams are building platforms these days and it's the era that we are building platforms. That's what I was doing previously. I was a consultant building these platforms and now 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.

All right, thank you. So today's conversation came around because I was being lazy and looking to Twitter to review my abstracts for events that I was speaking at. And the abstract was around me trying to talk about, not in a click bait-y way, but what Cloud Native 2.0 is going to look 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'm 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 we've also got Laura, and I want to know where you land on the WebAssembly, I don't know, fence per se.

I am probably a little more cautiously optimistic just because 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 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, and that's when you have this moment of, 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 ...

All right, so I mean then that'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. I'm right in the middle. Well maybe a little more pro than con, but that's okay.

That's all right, you can be left leaning. I'll take it. But it means that as we have our conversation today, we can discuss the pros and cons, we can have balances, we can understand what's important to everyone here. And then hopefully we all leave with the understanding that I'm right. That's the ideal situation.

Or we just throw things at our screens and then lock everything up.

I do have my throwing device.

It's okay.

It's a pink carrot .

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 again?"

It's a pink carrot, and it's a squishy and I can't stop letting it go. So anyway, let's focus, let's not get derailed within the first five minutes of the episode. All we've done so far is introductions.

I'm very good at that though.

All right, so I guess let's talk about the abstract I posted to Twitter, I gave the talk two weeks ago in Glasgow. And I'm just going to give the quick 30-second overview of what I sent WebAssembly brings to the table in collaborative architectures. And then we'll start talking about the pros, the cons, and take a look at maybe where it's not a good fit. Because of course it's not a catch-all tool, right? It's not going to solve all the problems for everybody.
But if we take a look at container-based development today, and I'm going to focus on development and then we can talk about delivery as well. I don't think anyone enjoys building microservice applications with containers on their local machine. And there's a few main reasons 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 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 a standard, not even a larger standard Python or PHP web app can take a five second refresh and a change. And that's just not acceptable. 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 how many containers can you run in your machine before it blows up? It's probably not that many. So then the developer experience pushes us towards shared dev containers, like back in the '90s and early 2000s. And I like shared development environments. They're cool, but then 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 the whole workflow is a mess.
Now, I know there's someone listening right now who's going, "Just use Linux." I have used Linux day in and day out since 2001. And I can tell you that I like Linux, but I've never enjoyed using Linux, right? It's always something, like-

What did you just admit?

I mean, I was an arch Linux user, so no one liked me anyway, but compiling my I3 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 when you go on a Mac, things just work. The apps are nice, they look nice. You're not worried about a migration from X11 to Wayland.
And I don't want to completely segue this entire episode to be a 30 minute rant about Linux, because I like Linux. I'm just not going to use it as my desktop daily driver. However, I don't know if Laszlo's looking at me with that discontent because he's like, "I run Linux every single day."

I was going to say, I do think the most hilarious thing about this right now is that Laszlo is on Linux. David, you're on Mac. I'm on Windows right now because my personal dev machine is on Linux, but my work machine is all Windows. And so we 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 going to add one more thing to the frustration bucket and then I'm going to let yous both take it over from there. 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-platform container images? We should be these days, right? It's not just MD64, but we have to accept the RM64 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, and it's just painful. Especially again on my M1 Mac where I pull an image and it says, "We don't support ARM, sorry." And then you have to go and use Rosetta 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 people that are new to this that are on their Macs and they're like, they just want to get started. Imagine your first day in a job and you're like, you pull ... you've got a M1 Mac, you're so happy. It's like this 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 ARM64 container on site of an AMD64. An AMD64 container on an ARM64 machine. So difficult, right.

Well I'm definitely hearing you. I mean, I'm on Linux so that's better, but I occasionally have to be on those cross-platform images and ARM has been an issue and I'm doing go and sometimes I'm getting some linker issues, which is 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 in their loop kind of setup that people develop inside containers. Now I'm doing containers since 2016 and developing applications and helping people and everything, and this inner loop, I never understood how can people bear developing in a container? It's just not productive enough. It's like it's not made for that. And I know there are tools and there are telepresence and other tools which you can use and all that, but I have this component, that component, all the boxes and the arrows between them. I just rewire things in my head and I just run my processes on my laptop so 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 put this problem into a box and never open it.

I think you're right. I think the local developer experience just should be native tools as much as possible. I know 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, but then it doesn't really matter, as long as the tests pass and you ship a container that's the same on every production node. Yeah, 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? What's your experience there?

Yeah, so microservices, I typically work on just a single service, so not developing 10 at a time and I need to recompile all of them all the time. So yes, occasionally I start up a stack of 10 applications that are my immediate dependencies and I use those as a static dependency, which 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 likes. But to me in general, if you're going to 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 going to miss this little bit or that little bit if you're running a system that is not the same. It maybe a weird networking error or some kind of load concern going across whatever system you're running.
So I don't know, I can kind of see the ... 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 and you have no idea what's going on and you have to wait for some engineer to come and work with you, which is really, really disconcerting as a beginner. So I can see that point.

Or they could write WebAssembly applications.

Or they could do that, but I don't know. 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, the language support is almost ubiquitous at this point in time. And for Go and Rust, it's 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 an OCI registry. You're not throwing away all the good things that containers in that ecosystem has brought to the developer experience. I still like the Docker push, the Docker bill model, why not use it for more stuff? In fact, we already do.
So I don't know. I don't think WebAssembly fits everything, and we can get into that. But I think the developer experience is solved. We don't need virtual machines, we don't need containers. Here's another thing, we talk about microservices, if everything was WebAssembly, and I don't think there's really ever a situation where that's going to be true yet, or maybe even in the next 10 years. But web assemblies' binaries are super lightweight. The startup time from a WASM runtime to running your bytecode is under a microsecond or under a millisecond, it's measured on microseconds.
Whereas for a container, you're probably what? At a best case scenario, container startup is like 300 milliseconds, 400 milliseconds. So it's not like for a microservice architecture you need to run every single container. Well you would, but in WebAssembly, you would just have little pointers to WebAssembly [inaudible] 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 how much attention y'all were paying in like, 2017, 2018, but the concept of unikernels was pretty big. And in fact, Docker bought the Oxford-based Unikernel company and now we've never seen unikernels. I don't know if there's a correlation there, and they wanted everyone just to use containers, but the promise was 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 you onto one of your sentences? When you said if you want to compile for WebAssembly, it is just a compiler target and you have your application, you compile it's the WebAssembly bytecode, binary, whatever, and then it just runs. And that feels like a very amazing scenario. So all the things that you said, it just sounds amazing, but my question is can I 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?

Okay, good question. Can you take an existing application and compile it to WebAssembly? No, it's not going to happen. Will it ever happen? I don't think so. The way that 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 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 this stuff that we expect from standard posits, right? And because of that, anything that's built without any of those requirements probably could be compiled to WebAssembly and go run in your browser. People have actually compiled get to a WebAssembly module and they hook out to the FET API and the browser to get the repository and do other stuff.
However, very cool. But we need to, if we wanted do server set WebAssembly, we need these things. We need sockets, we need file systems, we need to speak to databases, we need caching, we don't want to throw away service mesh and stuff. We want retry logic. We don't want to build this into 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. And it's like, okay, we're going to give you a sandbox to run your WebAssembly, but we're going to expose things on the outside via these APIs. So you have the ability to call open on a failed descriptor or close or read or write. You have the ability to open ... right now you can't open sockets, but you can say, go make an ATP request or a Reddit request or a Postgres request. Which means that if you want to compile existing applications to be server-side WebAssembly on these run times, the way that they communicate with Reddit and HTTP and Postgres and MongoDB and 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 going to be a side effect here, and I haven't seen anything to confirm this yet, but 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 think they'll provide a substrate for all future application development where we don't need to have people building bespoke performing MongoDB APIs and stuff. I don't know how much of architecture geeks you are, but there's hexagonal architectures, ports and adapter architecture, there's onion architectures, there's clean architectures.
They're all the same thing with different names that people have just tried to promote over the last 10 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 in 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 kind of an SDK that I have an API that I can call to do important stuff.

Yeah. So if we take a WASM runtime just now, like WASM time, WASM R, WASM Cloud, WASM Edge, there's a whole bunch of them now. You basically can just run a WebAssembly file without 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, HTTP APIs, et cetera, then you just add on the components as part of the bootstrap.
So every WebAssembly module that you run, you kind of remove that ambient privilege, right? Because I'm a posits 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 in the sandbox, you have to be very explicit and say, "Actually you can only speak HTTP and we only use it to speak to these domains and you can only speak to Postgres, but you can only speak to these tables or these databases [inaudible]."
And this all becomes infrastructure platform stuff. Your application developers don't care, it's just, "Do it. Can I speak to this table? That's all I really want. Can I get rows from it? Can I pull down whatismyip.com?" Whatever. I think that's a strong distinction between where we are to say, with [inaudible] development. It's very different, but I think it's very powerful.

Gotcha. So let me just explain my background. Why am I the world's biggest WebAssembly skeptic, which I am proudly wearing this badge, but not because I know much about WebAssembly, but more like when you are on Twitter and when you're reading news, there are many things come at you and then you have to put them into little buckets. This is important, this could be important, this is absolutely not important. You know, you put crypto in certain boxes as well.
And then here comes WebAssembly. And as a person who is invested into in containers and in platform engineering and Kubernetes and all that, obviously you have to be on the lookout of what's coming and what's going to change this ecosystem. And the WebAssembly is something I should focus on very much, or it will be handled for me by the tools I have already.
And that's sort of the question I'm trying to gauge here. And also a very similar situation. I was in five, six years ago, 2017, '18, when Amazon Lambda came out and there was a huge push. Everything is going to be a function, everything is going to be Lambda and your containers are already deprecated even though you haven't really used them in production. And then you have to put this news somewhere. And then I put Lambda into the, yeah, well could be useful for certain things kind of box, but not for me, kind of box.
And I'm just following the WebAssembly news from a certain distance and then when I'm hearing news, I try to match against my previous assumption. Does it change something? Does it reassure me? And I'm picking up some news here and there. And the thing that you said as well, that WebAssembly is more like an SDK, so it won't be a general purpose application modernization platform. It's more like a really cool tool that allows you to do amazing things, like, much less hassle than with containers. And then overall you can have a much better experience than all the container people, but you have to be in a privileged position to actually use these technologies or you are getting where I'm trying to go with this, right?

Yeah.

Yeah. I don't imagine it's an easy sale. 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."

Just everybody's going to look at me like I grew three heads. I mean, the fact that I'm looking at is ... so there's a couple of things. One, every time somebody comes up with something that's going to 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, absolutely. But 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 kind of like the XKCD except backwards. 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 always a little worried about that, because to me it's more about we're abstracting away so many layers as we move into containerization and things like that. As we have moved into containerization, we attempted to abstract away networking. Well, we added virtual networking, good luck remembering both. 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 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 going to be DNS in the end? 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 going to run it? How am I going to maintain it? What infrastructure do I need to be on top of? How does this affect that infrastructure? What am I going to 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? Maybe I'm just going down the rabbit hole here, but I'll ask this to both of you because both of you're talking about platforms like they're the best thing ever. And my response is, why? So 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 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 earth to Laura, you've just went complete full skeptic on me, so ...

I am playing the devil's advocate here. Let's hear it.

So let's address all of these things, is there time? I'm going to do my best. So Laszlo measures serverless, right? I think you were right to be skeptical about serverless. Serverless was such was really promising when Lambda launched, the idea that we could take JavaScript code, run it in a VA isolate, super fast, performant, do loads of really good things, it was amazing. However, people wanted to do more in Lambda and now Lambdas are essentially ... they started doing container layer stuff where you could pull layers from containers and bootstrapping them in so you could run other commands, use other languages. Now they're all running firecracker virtual 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 kind of go all in on AWS. And that means paying for other managed services, using their VPCs, using their managed databases, using their everythings, right?
I'm not a big fan of that approach. I think that's probably held serverless back. Now, we do have open source things, but they're all container-based. And again, we can't fix a code start time with the containers. I mean, speak to Alex Ellis. He's been trying to fix this for OpenFaaS for what, seven years? The problem is, you 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 around 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 and 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, keep on trucking. I think we still need containers. I'm never going to run a WebAssembly database. I don't think so, at least anyway. I mean I'm always going to use Postgres, and that's going to be a long run in container-based application that does Linux file system stuff. I want that to be performant. That means hooking into the kernel, and doing a whole bunch of other things. Same with stream processing, Kafkas, Red Pandas, all this other stuff.
And if I'm [inaudible], I probably would just want it to be in the container. But I think user facing stuff, your synchronous stuff, reactive, event-driven stuff, probably can and hopefully will be at some point built on WebAssembly's [inaudible]. But that's from the cloud native point of view. I'm going to loop it right back again to speak about Gimlet in a weird way.
It's like you're kind of 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, I'm going to use Gimlet and do this thing, but to change the behavior, extend the functionality, build in different source transformations to the entire Gimlet's pipeline, whatever. You don't want to [inaudible] and bring in more containers, it's very bloaty.
But you could provide a WebAssembly module with a certain interface and say, "I'm going to call this function in your module. I'm going to pass you in a string of bytes, which is all the YAML. You can do your transformations in this [inaudible]." And we're seeing this with desktop applications will VS code be WebAssembly extension point at some point in the future? Yes. Helix, one of the terminal editors has a WebAssembly module. There's Zelex, which is a terminal multiplexer, Retina Rust, that has a WebAssembly extension point. 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 [inaudible] wrapper and a [inaudible] it's just their native components.
So I think the versatility of it pushes it beyond what we've seen with Lambda and 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 compilation target and build every application in the world, but I think WebAssembly gets you pretty close.

Yeah, I do like the idea that someone who has learned a language and learned it well, not just taking a bootcamp but learned it really, really well, will be able to actually build something without having to know all about virtualization and containers and this and that and the other, or how AWS works, how to find your way through all of the AWS mess and just deploy some kind of serverless thing. I do like that idea. That is the one thing that I was going to 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 people wanting to work. 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 language. I'm just trying to pick something. Ah, I'm trying to help you here, dude. But going through and saying if the two of us want to 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 kind of nice.

Yeah, definitely. I have written a lot of Go code, just for the record. I'm not saying anything bad about Go. I do like writing-

It's mostly because when David and I worked together, it was one of these things, whenever my go broke, I went to David went, "Help me. It's not working."

Well. Yeah, I'm in an unfortunate position that I work with so many languages that I'm terrible all of them. I don't really feel that I'm good at any language anymore. 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 Pascal, and I'm just like, "I can't remember how to do anything in any language at all."

So what happens when you try to write Python?

I mean, that's when I just ask you for help. I can't even keep up with Python. I was told that [inaudible] is no longer relevant. I should be using Poetry. Black's being replaced by something called Ref, and I'm just like, "What? The tool chains have changed in 12 months?"

Yeah, miracles. Anyway. Sorry, Laszlo-

See, I told you, once we start talking, it's not even going to be about WebAssembly anymore. We're just going to go off in some random tangent. All right. I mean, 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 mean, I hope it's had a positive impact on where we're going to sit.

Like me? Laszlo?

Yeah.

Yeah. Okay, sure. So I like where this conversation is going. Containers are not going to be replaced with WebAssembly. That's a good outcome for me. Plus I think you confirmed to me that there are these WebAssembly primitives and then you build the castle from those primitives. And I actually liked the interoperability kind of use case that you described.
I'd also like to bring in another use case with containers and Kubernetes and platforms. We are all want to build the next Heroku, or at least for some time we were trying. And maybe it's not going to happen for Kubernetes, but it's going to happen for WebAssembly. I can more easily see that because it's a limited problem space to solve. There are these primitives and so on, lot less ground to cover. So perhaps maybe the next Heroku is going to be WebAssembly and I'm going to be totally there.

Yeah, I think it would be a lot easier to build the next Heroku from WebAssembly. I mean, if we look at all the people trying to build platforms today based on containers, I mean, it sounds easy, right? People give you your codes as a container and you just run it somewhere and the job's done. But actually there's a whole lot more to it. Let's take a look at running an application in Kubernetes today, right? In 2023. Yes. Can you write 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 set comp profiles. If you have SE Linux, App Armor, anything running on a host, you have to satisfy those constraints too. You've got to run your container not as a root user. Then it consumes persistent volume claims, you've then got to juggle the permissions to make sure that you've got right access to it if you need it.
I mean that's just ... you've then your service mission, your retry logic for network requests, and I think WebAssembly, a lot of those disappear, because the sandbox isn't is it's not posits, it's not the Linux kernel, it's not a Linux Elf binary. It's its own thing. Different characteristics, it's 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 Docker ... I mean let's, in fact we've even addressed that, right? Who invented containers? Docker. What has every Docker feature request including in the last 12 ... well, okay, who made containers accessible? Okay, who made containers accessible?

Okay, okay. I was going to say, hold on a second. There was more to containers before Docker came along, but Docker did make it accessible.

Yeah, yeah, [inaudible] before, blah, blah, blah. Nobody was using them except Google, come on. So Docker sort of put it in people's hands. And if we look at the last 12 months of Docker releases, they're all WebAssembly based. It's all about bringing in WebAssembly support to Docker Desktop, to Docker Compose, to the Docker Hub, shipping images with Docker Bill [inaudible] 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 better longevity to it. Something that a company like Docker is investing in, they see the promise of containers and WebAssembly side by side and that's, yeah, like I said, a big tick. I think that just affirms everything that I need to know about my joy of working and promoting WebAssembly too.

And just maybe a final thought, that actually I'm picking up that news as well because of course I have to hedge my bet. I'm in containers and I'm building platforms for companies and stuff, and I know containers. Should I learn the WebAssembly world? And I'm hearing this news that, hey, actually maybe today I have no idea that I could run a WebAssembly container on Container D or maybe even in Kubernetes. It's probably not true. So please tell me what's the state of this, but if things converge like this, that's actually very good for both the old and the new world. So I'm pretty pleased with this direction.

So the good news that you can run your WebAssembly, side by side with containers and Docker or Kubernetes using the container D shim called Run WASI. The way that this works is it runs a container with a long running process, which is the WASM runtime. So that'll be WASM Edge, WASM Cloud, WASMR, WASM Time, whatever one you choose to use. And it then will spin up the WebAssembly modules and response to requests coming in. Actually not dissimilar to what OpenFaaS does with their HTTP proxy that opens and runs functions.
So it's 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 running process and hook up networking and handle all the permissions and the services and all that boring stuff, the plumbing. But your WebAssembly module, just this tiny little thing that sits inside of it and gets executed every time a new request comes in.
And it works really well. There's a little bit of a faff right now. So the Container D shim shims out to the host to run the WebAssembly, WASMR, WASM Time, et cetera, 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. It runs as a demon set and every time a new node comes into your cluster, it literally just downloads all the binaries and sticks them into the user local bin for you. It 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 kind of can, and you know what? It's nice, like the OCI image that your WebAssembly module is kind of 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 WebAssembly and pushed it. I mean, if we compare that to a container image, it's rare that they're less than what, 50, 60 meg. And 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. You do from Ubuntu, have to install everything in the world that I need, compile this thing and then execute at tiny little binary at the end.
You then have to go learn, oh, multi-stage builds, and I can chain commands together to remove the cache, and they can do all these weird things. You've been in a container space long enough, you've done all of this. You have to learn it the hard way. Whereas with WebAssembly, it is just build a tiny little module, off you go. Which is quite nice.
So I'm curious, based on everything we've said and the fact that Laszlo, you're building Gimlet, it's a GitHubs platform, is there anything in your head that's thinking WebAssembly could be a value add here and net positive? Could I extend Gimlet in a way with this? Same, you have to write the first plugin, but I'm curious, what do you think WebAssembly could bring to it?

So I learned a lot. So I was the world's biggest skeptic, not because I knew stuff, 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 full scale of, 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 going to put on this lens as well and I'm going to try to entertain the thought a little bit more.
And honestly I learned a ton. So it was definitely moving my WebAssembly appreciation to the right direction, to the David direction. It's still on that side of the spectrum, but it's a step.

Ah, I'll take it. How about 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 touch, spend some time with it, I think is when I'm going to start seeing a lot of the benefits that you're talking about.
But for now, you can still put me in the cautiously optimistic camp because my skeptical ops brain is still kind of like, "What am I missing here?" Because it can't be all rainbows and unicorns the way you want to paint it.

Well, what we could do, we'll stick something in a calendar for 12 months from today where we get back together and we see where we are, right? I mean, I am very optimistic.

There's your remind me.

Exactly, right. It'll be in my calendar at any moment now. But yeah, I think it'd be fun just to see what was right, what was wrong? Are we seeing adoption of WebAssembly side by side with 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.

Yeah, there's definitely some stuff there. And it will be interesting to see. I think in a hybrid cloud world, to be brutally honest, I'm seeing a lot of hybrid cloud world and private cloud discussions and repatriation of workloads, especially in enterprises. And I'm really curious to see if this might change some things, maybe get some people off of Java and Spring where they've been living for decades.

Probably not.

I can dream, please let dream that I don't have to do any more Java.

So the good news is you learned Java 20 year and 15 years ago-

I know.

You learned Spring, like, 10 years ago. And you can use that knowledge 10 years from now.

I mean, it's kind of like still knowing FORTRAN, right? I can always find a job knowing FORTRAN, even 50 years from now, who knows? David, here's my statement. When they make FORTRAN on WebAssembly, then we know it has reached the big time or jumped the shark. I'm not sure which one.

It exists. There you go.

No, no!

Sorry to burst that bubble so quickly, but now that's it, you're converted. Yeah, I mean the language support is ridiculous. If you just Google for WebAssembly supported languages, like the slide I had at my talk two weeks ago, I had 40 languages on it and that was me just picking the best ones and the worst ones. The fact that Brainfuck can be compiled to WebAssembly, it tells you everything that you need to know.

It does tell me actually a lot that I need to know. Okay. Actually that really does.

All right.

Low code? Rockstar? Anyway.

I don't think Rockstar does. I think that's been done.

Okay.

But I'm sure we can ping Dylan Beattie tell him to get all over that.

There we go.

All right, awesome. Thank you both for entertaining my ... I don't know, not rants, but WebAssembly admiration, adonation, whatever the word may be. I'm not entirely sure. I

I want to put little stickers on your video of little fan signs.

Hey, if you want to edit, you can feel free. I'm happy to give that up. So Laszlo, do you want to share any links to your projects, your Twitters, your GitHubs, your LinkedIn, anything like that before we wrap up today? This is the shameless plug moment, so take it away.

Yeah, sure.

Shameless plug. Do it.

So I only have Twitter and I'm so sorry about that. So that's LaszloCPH. And I know 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 judge me. [inaudible]-

I say don't, because I wanted to ... Sorry, I wanted to take advantage of the more than 10 minutes, 1080P video. Because I thought, "Oh, I could push load the video through Twitter," and then I canceled it because now it's like, "This is shit." And Elon Musk is doing really stupid things with the platform and 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 every, I don't know, forever. Anyway, so it's LaszloCPH on Twitter and gimletio on the interwebs. So please check this out. And yeah.

There we go.

Yeah. Thank you for having me and teaching us WebAssembly-

All right.

... appreciation.

Yeah. Thanks for coming on.

Thank you Laura.

Thanks for joining us.

If you want to 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 landscape on three-

On three.

One, two, three. Don't forget your compass.

Don't forget your compass.