Gearset’s David Rant Breaks Down Wasm Adoption Challenges

This is Textron tv. Hey guys, thanks for the throw. We're here with David Rand, who is engineering lead for Gear Set, and we're talking about was otherwise known as web assembly, and what is it gonna take for this to become more of a mainstream development platform, environment format, whatever you want to call it these days.

David, welcome to show. Hi Mike. It's lovely to be here.

Thanks for having me. Where do you think we are right now? It seems to me we're still at the phase where, um, was is being used more, but not pervasively, some people have a better understanding of it than others.

What's your sense of where are we on the journey right now? I think there's been a really great adoption of web assembly in the browser. There's, there's been some really positive, strong moves from big players in that space.

Um, I can speak, um, personally mostly to the Microsoft stack because, um, at Gear Set, that's, that's what we use primarily. Um, and with the initial efforts by Steve Sanderson, um, and that evolving into the Blazer framework, there's been some kind of real innovative stuff going on there. Um, as a T net developer, we can now pretty easily run C code in the browser as an alternative to JavaScripts.

I guess the next domain that, um, lots of engineers wanna see happen is the ability to run your code within a web assembly module, but outside of the browser. And I think that's gonna be the real, um, story that gets told over 2024. So that more server side deployment of Wasm kind of mirrors some of the things we saw with JavaScript early on where it ran in the browser and is now in the server.

But what are the challenges in making that happen right now? What is the level of maturity? So a lot of stuff is still in preview.

Um, there is a huge effort by the Bike Code Alliance and the open community to, uh, push towards, um, firming up a whole bunch of standards that mean we can have various vendors and, um, community efforts that work towards implementing those standards in a variety of ways. The big one over 2023 has been, um, something called wie Preview two. So, um, to unbox a bit of terminology, wie is the web assembly systems interface, which, um, was, uh, kind of tweeted about a while ago by some of the guys at Docker suggesting that, uh, if WebAssembly and Wie was available, um, years and years ago, then maybe containers, uh, wouldn't be where they are today because it has such potential.

Um, but Wie is fundamentally the, um, the component or the, the piece of the puzzle that will let web assembly run outside of the browser, um, kind of in a standard and generic way, um, across, across various systems. Um, and preview two, which has been kind of the focus of wie this year, um, has kind of had a few different prongs to it. I guess there are, there are kind of three, three main parts to it that, that have been focused on this year.

Um, and then we can briefly talk about, uh, where that might be going next year and, and preview three for wie as well. So, um, the, the kind of the big things for, for Wie preview two have been, um, the web assembly component model, which we can talk about, um, in more depth. That's probably the biggest and most exciting thing happening in, in web assembly at the minute.

It, it changes some of the, the fundamental ways that we as software engineers can think about composing packaging, uh, and shipping our applications. Um, but it kind of has, uh, bigger ramifications than that as well. Um, it can reduce duplication of effort across different programming languages.

It's, it's a really interesting and, and promising, um, evolution of web assembly. Um, we also have, um, newer features coming into web assembly core itself. So, uh, the ability to, uh, kind of start and control threads, um, is something that has been asked for a lot by the developer community.

Um, and also, uh, garbage collection as part of web assembly itself. So, um, garbage collection's an interesting one because certainly for, uh, net developers, Java developers, where our code compiles into an intermediate by code format and is then run within, um, a virtual machine. So with Java, it's running the JVM.

Um, the JVM brings its own, uh, garbage collector, as does the T net runtime. Um, so we kind of, we have garbage collection to an extent in web assembly already, but what we have to do is we have to compile the runtime with the garbage collector into a web assembly format itself, and then we can ship our application code with that compiled garbage collector. Whereas what we're seeing now is that part of the web assembly, uh, standard will be, it provides a garbage collector that we can hook into and that has some interesting possibilities for, or improvements around memory usage and debugging stories.

So there's some really interesting stuff going on there as well. Uh, and then I guess the, um, the, the third bit that's really interesting about, uh, preview two of wie is, uh, what the component model enables. Um, and that is this idea that we can, um, we can define subsets of APIs or, or, or, um, uh, APIs, um, which in the component model are being referred to as worlds.

And those are basically groups of interfaces and contracts that you may commonly want to make use of as part of your, uh, your web assembly programs. And I think that's gonna, once that starts to kind of really cement up, then people are gonna be able to see that, hey, I can actually go and use web assembly, um, with all the requirements I currently have running in virtual machines or, or containers. People can start to see how they can, um, meet those requirements.

In the web assembly world too. A lot of the focus initially at least has been we're gonna fulfill the promise of the Java runtime and enable people to run applications anywhere, but are there other capabilities in Watson that I can't get somewhere else? What is it that is gonna drive developers to embrace this?

Because, well, it's new in developers don't always wanna necessarily change. Yeah, so I think, uh, a lot of conversation around WebAssembly on the server side has been this evolution of, uh, uh, kind of cloud infrastructure and how we ship our code, how we run our code, um, and there's been a lot of conversation going on about how web assembly may, it will be the third wave of that. So the first wave being virtual machines.

Um, and there was some great tooling around that, like HashiCorp's packer that let us kind of, uh, build machine images and ship our code, um, in an automated way. And then Docker came along and really made containerization super easy, uh, to use for, for all developers. Um, and I think Web Assembly's gonna kind of be that third shift.

Um, and I think there's some important differences between web assembly and what we currently have with containerization. Um, it's not gonna replace containers, um, it's gonna compliment them, I think, um, in a variety of ways. So the real benefits to web assembly, um, that are kind of often quoted are, um, that it runs in this sandbox model, um, where you have to, uh, explicitly give, uh, web assembly applications, permissions, um, to do certain activities, read and write from a file system or, uh, make HT P calls, things like that.

Whereas, um, with a lot of other programming languages, um, T net and T Net's virtual machine or Java and the JVM, um, those permissions are kind of there already for the code that is running within the JVM. So actually the, the security model is slightly flipped on its head in that you have to explicitly give permission to your application. Um, so that's a really nice security story that can be told.

Um, another side of it is that web assembly itself is incredibly fast to, uh, startup. So we're talking sub millisecond startup times, um, containers. If you really work hard at them, you can get 'em to start in maybe a couple of hundred milliseconds maybe.

Um, but most containers will start sort of in the, in the order of magnitude of seconds. Um, and this lends itself really nicely to serverless workloads, and serverless has kind of been this architectural paradigm that the development community has really embraced. But I think web assembly is going to be, uh, kind of the next evolution of serverless architectures that we see.

The way that kind of a component model is, is, is, is firming up in terms of standards. It's gonna mean that as a software engineer, when I've got problems to solve for my customers, I can really, with WebAssembly and the component model, I can really focus on getting straight into my business logic to solve my customer's problems. Um, rather than, uh, you know, with, with some of the existing tooling we've got, there's inherently a bunch of boilerplate or vendor lock-in that we have to go with before we get round to solving, uh, kind of our customer's problems.

And so I'm really excited by the thought that web assembly, which is, um, uh, uh, fundamentally a a bunch of functions and data types, um, that I can, I can just start to write a function that solves my customer's business problems without needing to worry too much about kind of the, the, uh, underlying infrastructure. Because so much work is being done upfront about the abstractions between my code and where it's running and how it's running. So I think there's some, there's some really exciting stuff to happen in the serverless world.

Um, the payload size of WebAssembly, um, is also, uh, a real benefit and we can look at that both from kind of that startup time perspective, um, but also for edge compute as well. Um, and embedded devices too. So, uh, embedded devices may want to, you know, pull updates from, from some central place, and they may be doing that over a very low bandwidth connection.

Um, the fact that web assembly payloads, uh, can be, uh, very compact means that it's kind of ideally suited for delivering applications to, to the edge, whether that's kind of, um, low power embedded devices, um, or it's kind of, you know, sort of edge compute network edge compute, um, such as kind of CloudFlare workers or, or, or fastly offerings and things like that. What is gonna be the relationship between wasm and containers? 'cause I think some folks think that they might not need containers going forward.

Others argue Wasm is gonna be encapsulated. So what's your sense of what is the relationship here? So I think web assembly is gonna be the go-to, for a lot of application workloads as this stuff kind of starts to land next year.

Um, the component model is really important for a lot of application developers because we need to take our dependencies with us into that web assembly world. And the component model is fundamentally gonna be the way that we do that. Um, the way that web assembly components work is that, uh, a component will define what it needs through the form of imports and what it offers in the form of exports, and all of that is defined by an intermediate language called, uh, web assembly, uh, interface types, Witt.

Um, now that's really important for us as application programmers because, uh, we regularly make use of third party code, third party dependencies, um, and we need to be able to, as I say, take those with us into the web assembly world. Um, and lots of those dependencies may not be written, um, uh, completely in the same language that we are running in. net or many other languages.

Um, pythons, another classic example. You may have native implementations of certain libraries, uh, mpi for example. Um, uh, you have, uh, native implementations in, in the language like c um, and you need to take those with you into the web assembly world.

Um, I think the other thing to call out as well is that, um, containers aren't gonna be going anywhere. Um, they're still gonna solve a whole bunch of problems that, um, either web assembly initially won't be able to solve or just aren't best suited for web assembly. So you are gonna be, um, uh, looking, uh, to use containers to port applications where you don't want to necessarily have to recompile them into a different target like WebAssembly.

Um, containers are a great fit for applications where you just wanna port them into a slightly more, uh, uh, portable format, but you don't wanna necessarily change like your compilation targets, and you don't necessarily wanna change a whole bunch of your other tool chain, let's say, if you're migrating from either bare metal or, or virtual machines, things like that. So I think WebAssembly is gonna take some of the slice of, uh, customers for containers, but I don't think it's gonna replace it at all. I think it's just we're gonna see them working in tandem.

And for companies like Docker, we've seen them make active inroads into, um, kind of, uh, making it very easy for developers to use both of these tools and technologies in complimentary ways. So Docker desktop itself has, um, uh, kind of experimental support for, for web assembly, um, and we are seeing companies like Microsoft make deep investments into, um, running web assembly, uh, within container orchestration platforms as well. So a lot of these companies, you can see the direction they're going in.

They think that containers and WebAssembly are gonna sit side by side, and they're just gonna serve two kind of complimentary, but different, um, purposes within our, within our development tool chain. How accessible are we making was today? Because I think one of the things you've heard or I've heard from developers is they find it a little difficult to work with in its purest format.

So do we need higher levels of abstraction to get to that or, you know, what comes next? Yeah, I think that's a great question. Um, web assembly fundamentally is if you wanna work with it at a low level, it's quite scary and for a lot of developers pretty inaccessible.

So I think that's, that's definitely, uh, a fair comment that, uh, there's work to be done in terms of making it easier for, for broader software engineering to, to adopt at scale. Um, and I think we're gonna see a whole bunch of tooling, uh, evolve. We've seen a whole bunch of tooling come out recently.

Um, so companies are doing great stuff like fermion with their spin framework, uh, Cosmo with, uh, Cosmo, um, and these companies are really working hard to improve that developer experience, um, not just in that, that kind of inner loop. So that build, uh, that dev test build cycle, but also kind of in the, in the operations and monitoring space as well. Um, it's no doubt that we're gonna need to, um, see that tooling kind of, uh, increase its language support and we're gonna need to see better integration with, uh, development environments.

Um, but there's a lot of work from various companies going on that will really help improve that developer experience. When working with Web Assembly, um, we started to see, um, or, or, or we continue to see a lot of effort in making, uh, working with containers as seamless as possible. Um, recently we've seen, uh, dotnet support, um, containerization actually at the T net CLI level.

So Docker files are now, um, not even needed to, to use T net within, um, containers. And I think we're gonna see similar efforts, um, from various programming language communities, so that running your code and compiling it and deploying it in web assembly is going to become an implementation detail rather than, uh, kind of this, this big scary upfront thing that you need to learn how to do. I think that's gonna be, um, a result of huge community effort over next year, um, to kind of make it as easy as possible to pick up and, and experiment with and run with.

And as I say, companies like Ferion and cosson are doing really great stuff in, they're providing good documentation. Um, they're, they're really pushing the boundaries of, of what we as developers, uh, can do with, with commercial tooling. Um, and I'm really excited to see kind of where that, where that goes next, next year.

And Then what impact is that gonna have on the DevOps engineers and the software engineers and all the folks that are putting together all this application code for deployment in production environments. Largely, it means that I, I don't think there's gonna be too much that fundamentally changes. Um, I think we're gonna see requirements for DevOps engineers, platform engineers, SREs, um, to have web assembly workloads as part of their toolkit.

I don't necessarily think that, uh, we are gonna see, um, a whole reinvention of, uh, orchestration. Um, so a lot of, uh, there was a lot of speculation that if Web Assembly does become the defacto way of, um, building and running application server side, uh, what does that mean for Kubernetes? Well, because we've talked about the fact that containers, I don't think containers are really gonna go anywhere.

I think we'll just see a complimentary shift of some workloads over to Web assembly. Um, we, we've seen significant efforts in running those workload web assemblies within the existing tooling that we currently have. So, um, an initial effort was, um, uh, a tool called Crust Lit, which replaced, um, the, uh, culet runtime component on nodes within a Kubernetes cluster, and that was able to specifically handle web assembly workloads.

But recently we've, we've seen a, a pivot towards, um, writing what are called shims for container D, which is, uh, the container runtime used by Kubernetes. Um, and we've seen efforts both from, um, companies like Fermion with spin, um, and also, uh, run wie, which, uh, I think initially was contributed by Microsoft. But we're starting to see these, these approaches where you can run web assembly workloads, um, in parallel to container workloads, um, using the existing tooling we already have.

What may be interesting is that we might see a bit of a resurgence for, uh, other orchestration technologies that are, um, less container specific. So a great example is HashiCorp's Nomad, um, where it's not designed only as a container orchestration platform. Um, it can also be for virtual machines and extended to web assembly as well.

So we may see a, an uptick in, in kind of less container focused orchestration platforms, but I don't think we're gonna see, um, a huge disruptive change in terms of, uh, what DevOps engineers, uh, will, will need to be doing to get their changes into production. Um, fairly recently there was, um, uh, a proposal, uh, for how we actually share web assembly modules and components. Um, this is the idea that, uh, with containers, we need a registry where we can push and pull our, our application code.

Um, so when we deploy it into clusters, we can just pull a container from a registry and have 50, a hundred copies of it, uh, running wherever we like. And a while ago there was a proposal that that ended up, um, not, not kind of making it through preview, uh, for these container registries to also be the same reg be registries for web assembly modules, um, however kind of that, that didn't work out. And now the BI Code Alliance, um, and the community, um, is starting to get behind, um, a proposal called wag and WAG is potentially gonna be the, the way that we push and pull, uh, web assembly artifacts.

And it's gonna be pretty analogous to how we do it with containers as well. Um, it's just gonna be, um, web assembly workloads instead of, instead of containerized workloads. There'll be a bit of a change as well, I think maybe with how we operate and monitor.

So it is hard to tell at the minute whether we're gonna see kind of existing vendors, um, uh, adapt their tooling to be web assembly, um, capable as well. I mean, I'm sure we will. There's like, there's no speculation on that.

Um, but it'll be interesting to see whether we start to, whether we start to see, um, new vendors come into the space who specialize in the, in the operation and monitoring of web assembly workloads as their primary, uh, primary specialization I guess, um, that we, we may see. But, um, I don't think there's gonna be this, this huge shift shift for DevOps engineers. I think that's, that's the real positive story.

Uh, it's gonna be, they already have many of the, the tools and, and we we're still gonna be operating in a cloud native world. Um, it's just that a lot of the existing tooling I think is gonna adapt towards web assembly as a workload on top of containers. All right, folks.

Well, you heard it here was and miss way comes in. Some level of change will be required. It's all just gonna be an issue with how we go about managing it from here.

David, thanks for being on the show. Thanks, Mike. All right.

And back to you guys in the.