Use Cases for Wasm – Bailey Hayes, Cosmonic

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Bailey Hayes who's a director at cosmonic and also serves on the technical steering committee for the bite Alliance and we're talking about webassembly also known as was awesome and where we're headed from from here. Actually. Hey Billy, welcome the show.

Hey, thanks for having me. It's not clear to me that everybody really understands. What was them is but it appears to be a new format for building software.

Some people look at it as a new type of artifact. But what's your take on? What exactly is Blossom and what makes it unique?

Yeah, I usually tell people that wazam is easiest to think about as a compilation Target that's portable. Some people will repeat fur to it also as like maybe a new wave in Computing because this artifact is portable but it's also sandboxable. So it's really easy for host run times to take that artifact and run it on, you know, many different architectures without having to change the artifact and we also know the way that it works with the linear memory model and all of these different properties because it grew out of the web.

We know that it needs to be sandboxable right in the web you download arbitrary code from all over the world and you're running it on your local computer. You need to make sure that they can't do nasty things and Wasim has all of those same security properties built in while also being super tiny very fast. Download and all of that when you think about it means that it can work really well both in the web and also outside of it.

So I don't think many folks know who the bytecode alliance is either. So explain what their role in this is Sure, the bicot alliance was formed around 2019. I had several founding members across the software industry just a few would be like Intel and Microsoft and red hat fastly Mozilla.

So so lots of folks are involved and we are working to establish a software foundation for blossom what that kind of means is if you think about the standards that are growing outside of the w3c a lot of the SDK and ecosystem work that you need for any given if you think of wasima is like its own language, but really the sdks for making it really easy to build and work with Walzem debug and maybe have a registry all of those type of things are coming out of the bike hood Alliance the bike code Alliance also has two run times was some time and whammer wise sometime is a one that Works really great for server side wasm. It is in databases like in single store embedded. It is also run for serverless applications and fastly and many many many other places.

Whammer has support its it's written in C. It has lots of support for many different architectures including very tiny ones. And so it's a very interesting approach that they are pretty different from each other, but that's what's so great about supporting both of them and hosting both of them within the bike code Alliance.

Now within that Muslim kind of got it start on the browser and the client side and now it seems to be moving over to the server side. And in many ways this kind of feels like JavaScript doing the same thing where it started out on the client and then moved to the server side. So how mature is Wasim on the server side these days.

Wasim has been run on the server side since I would say around 2019 ish. So we've been working on it several years old now at this point. I got my start with Wasim actually technically I started with Asim JS, which was a project from Mozilla 2012 ish was was the timeframe for Asim JS and the work for Designing webassembly was in 2015.

And so my original foray into Asim was actually from making a data visualization application for browsers. That was really cool very useful. But even then and even in the language that we use we made sure when we were talking about what was being designed for wasm we were all very careful about calling it a portable virtual machine and none of the properties of JavaScript beyond the the principles of needing to be sandboxable and download fast and be able to execute arbitrary code inside browser.

Or nothing kind of leaked into it. So that meant that it was fairly, you know straightforward Beyond just needing a runtime to run it outside of a browser that was kind of the main requirement with JavaScript moving from the web and out. That story is a little bit different right because the runtime that people a lot of people use when we started seeing server side applications with JavaScript that was with no JS, which is based on V8, which is the runtime use inside Chrome.

So with Blossom, I would say some of the more popular runtimes are not necessarily spider monkey or V8. Although I do see those outside for running server side applications. So that part is kind of similar to JavaScript.

I'm seeing many many more different run times that are purpose-built for this specific use case. There's I would say at least 10 very very active laws and runtimes that are meant and I'm server side is one way of describing it but you know, some of them are iot devices and embedded devices and meant to run, you know, running user-defined functions inside a database like a lot of this allows us to be very specific about exactly what we need. And what are the constraints of the use case Is in your sense that this format will replace existing artifacts, whether it's a container or something of that elk or we're going to use it for specific types of use cases and it will fit in alongside everything else.

We already have it is definitely something that makes the ecosystem Better Together We With VMS. We never really saw The Disappearance of servers, right or server racks with containers containers now run in VMS. I expect with whasm I expected to run alongside with containers a container pulls in a lot of things like an entire operating system to be able to run processes and how all of that is managed usually even file system aspects and so a container has a lot of stuff in it those that type of stuff isn't necessarily available for awesome module as a module is is right just a single compilation Target is kind of how I want people to think about it and the things that it's allowed to you do to break outside of the sandbox like dude networking and access the file system and all that type of work that is granted to it by the host runtime.

So what's inside the lesson module is really the code, so it's not it's not a lot right? So Applications that maybe were are currently distributed with a container like a very simple go microservice. That would be a great Target to move to Wasim, but there are so many others that I think would be best just sitting alongside in a container next to as a module and there are many different projects for being able to run like just within Docker.

Actually, they they have a container D shim. So you could have say one Docker compose file that loads containers and also knows the load a whasm module with a specific whasm runtime there are a lot of advantages to doing it that way in that one while some runtime can run many many wasmodels you're able to do very smart bin packing that way versus container will pull in a lot more but that's why it's kind of advantageous to be able to support. Both and so you're seeing that happen both from the docker perspective and kubernetes.

There are many different approaches there. There's kawasm. There's the containerd yee stem work using wazzy node pools.

I've seen a lot of work coming from the Azure team in that regards for AKs on findings really smart ways to do this. So it seems that the path that across the industry is to make it better together including for serverless spaces. I I see a lot that's like, okay.

Well, here's a JavaScript approach and here's alazama approach. Although in the bike code Alliance Community stream that we ran this week a couple days ago guy Bedford demoed being able to take JavaScript code and componentize it. We should talk about the component model at some point, but he componentized it and made it made it was a module that embedded the spider monkey runtime, which is the JavaScript engine in Mozilla about in missoul Firefox.

And so he basically made a waza module that had JavaScript code in it. So now you have something that was extremely fast. I could run both in a browser but also outside of a JavaScript runtime.

So there's the answer is it's gonna be something that runs alongside sometimes maybe is a better use case for certain certain use cases, but it's yeah, it's it's pretty exciting to see where was them is getting plugged into the stack. It feels like it's an every little nook and cranny. Now if you squint hard enough we're using whasm if if we're using anything to stream this like anybody that's watching.

This is almost definitely loading in their browser. I recommend them looking Network tab how will we make laws and more accessible to developers because some of the conversation is that it's You know a little challenging to kind of warm up to initially and why you're on that subject. Maybe you want to dive into that component model.

Yeah sure thing. So, you know, one of the first things that a lot of people discuss is how the debugging story isn't as great for wasm as it is for JavaScript. There are approaches using dwarf and being able to generate essentially Source Maps.

There's there's been a lot of work there but it's not quite the same. I think a lot of that comes down to being a compilation Target that is targeting a portable virtual machine really and so there's there's a lot more we need to do for building out the SDK in tooling that is in the purview of the bike code Alliance and it's and we have a special interest group that just spun up for for improving the debug ability story. There are other sides which is we have lots of different.

Libraries and and all the various language ecosystems that assume a lot of things they assume that they can start threads and that they basically are existing in a posix like environment. But when you assume that you lose capability-based security and So within the w3c there's a working group for building out the webassembly systems interface. The systems interface you could think of as giving a lot of the capabilities that people expect out of say live C.

But it also provides high level apis that can granularly provide capabilities. An example capability could be how to communicate over each or how to access a key value store so it can be both pretty high level, but it can also be pretty low level. Building out that is what we'll start to see in common.

Basically in the rest terminology crates so the common libraries within the rest ecosystem but will also see it and header files for C and c++, basically, I I kind of expect us to start by building out that basic flywheel getting some of the most common libraries that various language ecosystems depend on get those running with a capability-based security model and and then kind of grow out from there. That's a lot of the work that we're doing within the bike hood Alliance something else that's sort of related to wazzy and and is something that is sort of part of that same working group within the w3c is this new proposal that we're working on and it's called the component model and we've been working on various aspects of this for the past two years. And and now we're starting to see some real demos kind of into end of using the component model.

And it's the idea that we can assemble like Lego bricks basically various components and it allow for language interoperability. Allow for virtualizability across different types of environments. So that's that's probably a lot of different computer sciencey things.

Let's break that down. Let's say that I want to be able to use the best library for the job right now if I'm writing and go using having to build my code with seago AKA pulling in say A C library or something that's got ffi bindings from some other language. That's almost like lava.

We're good developer. They want to avoid that at all costs. If you look at that and the JavaScript ecosystem exact same thing.

They really need something that is runnable in a JavaScript runtime. And so what's happened is that we've built up all of these language silos across the entire industry and with something like the component model and we believe it will be the component model we can use all of these different basically the right tool for the job. I can write and go And pull in say a JavaScript library where I could write in Python and pull in a rust Library things that we've really never been able to do before easily or idiomatically but with the component model I could pull those in by knowing what basically my interfaces are and knowing how to link those together.

And so the component model gives me the ability to compose different components if you could think of components as different libraries, but they can also be you know, they could also have a main function and and be your Runner within the context of lazy one of the the standards that we've developed is called a world and a world is you could think of it as all of the sets of interfaces that need to be provided either basically buy the host and if I compile targeting a world, so let's say you live in a world where you are a CLI module On in that world. I am able to do things like file system access and file I/O and maybe I, you know want to be able to print to standard out and standard in like that's kind of what you expect out of CLI module and So within Yazzie and being able to produce a component targeting that world that that is sort of some of the new terminology when we compile now instead of saying we're compiling for a lazin module. We actually have a different ABI and that is a component ABI and so when you do that we call that, you know, taking your code in componentizing it once you've componentized your code.

It means that you've basically provided a Lego brick that other people can build on top. And they can pull it into just about any other language. We're seeing so many start adding support and and adding support usually means starting with guest language bindings.

And that is in a project called whitbygen. Inside that project there are a number of different languages started with rust C++ JavaScript. I'm I've seen you projects spinning up right now for Ruby Python, and I believe ago and actually was just merged.

So starting with being able to communicate between that inner that interoperability layer. That's really what what we call language bindings. You have that piece once you're able to produce something.

That is the component ABI then a runtime like quasim time that supports that component ABI can load it in in a symbol of these components and a really smart way and it's all based back around that capability security driven model. cool to that end. What will be the impact on devops workflows?

Do you think as we kind of shift to that because the folks who support all those developers to help deploy all that code do they need to rethink some of the workflows or what do you think will happen Downstream? Yeah, I imagine that devops practitioners Are Gonna Love it or at least that's what I hope right? I work on I'm a director at cosmonic.

And so we're building a platform that makes it so that it's really easy to a for developers to provide and and build and distribute components but also for platform engineers and devops practitioners to be able to at runtime swap out the capabilities that are granted to those components. So at runtime we can say actually you get a different level of access to the sequel database and we we use what's called a link definition and that is how we grant that basically information that that component needs whether it's connection information or if it's specific capabilities, like getting a different type of system clock and being able to like restrict that because these are now a simple more Like pieces that I don't have to rebuild the entire world when one dependency shifts, so I also have worked more on the platform engineering side providing middleware for authentication and authorization and all the HTTP middleware and so often those that's the area that you frequently have to rev right now and it's often a rebuild the world type of problem. If there's ever a CD in those spaces and of course HTTP server and all of those are usually, you know, the frequent targets and when that happened it meant that I had to help rebuild and this was while working at a company called SAS, we had to basically rebuild all of our containers first, we had to rebuild all of our applications and we had to rebuild all of our containers and then reship them and so turning that software crank is like very expensive and asking folks to to make that update across many different organizations can be a lot of pain and I know that The only one that had this problem, I I've heard it across the industry and so being able to update just a single capability without having to modify and recompile any code is except for the code that that's broken that that's that power and the industry's been trying to Grapple with this with a lot of different approaches Cloud native build packs is one approach and kind of I can't container driven world where maybe you only change out that file layer that's changed.

But if it is in the application binary or it's a library that's linked to it. It has the whole thing has to basically rebuild at least the entire application from The Source going back out to being redistributed. And so this is one of those things that will really help solve that problem.

There are a lot of different courses. There's a Linux Foundation course for for learning about lazim intro so that that's a another good way to help devops practitioners kind of get familiar, but I would say that but the new design the new paradigm should mean less work and more control for folks that are trying to provide a safe and secure platform. All right, folks.

You heard it here. There's a new animal in the application development Zoo. It's small sleek and fast and it's probably going to change a lot more than you can possibly imagine just yet.

Hey Bailey. Thanks for being on the show. Hey, thank you, Mike.

Back to you guys in the studio.