Today on the show, Jonathan and Will talk with Connor Hicks, founder of Suborbital, a serverless platform powered by WebAssembly.  They discuss how WebAssembly works, running WASM on the “edge” network, Suborbital’s capabilities, and everything in-between.

Hello everybody and welcome to an exciting episode of Adventures in DevOps. I am your host, Jonathan Hall. Today in the virtual studio I have Will Button with me.

 

What's going on, everybody?

 

And we're really excited to have our special guest, Connor Hicks, welcome Connor.

 

Hi, thanks for having me.

 

Thanks for coming. Would you tell us a little bit about who you are, what you do, and why, maybe you know something about DevOps or tech and why you're here, yeah.

 

Yeah, absolutely. Yeah, so my name's Connor. I founded a company called Suborbital. We are working in the WebAssembly space, specifically using WebAssembly on the server to let you run. plugins and untrusted third party code inside your application. I've been working in cloud and DevOps for, oh, I don't know, five or six years now. And I feel like I've run the gamut of all the different things that there are to do out there, but are my latest fascination is, is running web assembly on the server, but specifically, you know, on an edge network and playing with things like Anycast and globally replicated compute. It's all very hip and fun right now and we are knee deep in it.

 

Awesome. You just mentioned a word that I think or a phrase I think would be really good to clarify. Because I mean I have I think I know what it means but I might be wrong and if I might be wrong I'm sure a lot of our audience don't know what it is. So can you explain the edge and edge computing? What is that?

 

Yeah, this is not a well-defined term by any means and people have been overloading it for a while now and

 

Yeah.

 

The way we think about edge is having kind of two parts so there is the Edge device category right edge devices are things that are

 

Thanks for

 

running

 

watching!

 

Inside of a warehouse or it's your phone in your pocket or it's a sensor on a tractor This is something that is physically in a location and it is generating or consuming data. And then the other half of Edge is what we call the Edge Cloud. And these are just servers that are very close to

 

Thanks for watching!

 

the things communicating with them. And so if you look at a company like Cloudflare, they run an Edge Cloud where they have, you know, 200 plus regions around the world so that whenever you're talking to Cloudflare, you're always talking to a server that's close by. This is... only half of the equation. It is the part of the equation that we, you know, deal with the most, but the other half is those, you know, edge and IOT devices that are actually running in a particular locale. And so we like to clarify it that way because you say edge and sometimes people say, oh, you're an IOT company. No, that's not what we're doing. We're doing the other half of it.

 

So does edge imply IoT? I mean, you're not doing the IoT part of it, but I mean, you're talking to IoT devices? Or is there another form of edge that has nothing to do with IoT also?

 

Yeah, so you can combine Edge devices with Edge Cloud, but they can either be two parts of the same system or they can be used for completely different things. And so, you know, in the Cloudflare case, they are. serving web traffic to humans using a laptop or a phone close

 

Right.

 

by. So there's no IOT part of that story. Um, but you know, if you look at the edge devices scenario, that's, that's where IOT comes in and you know, edge devices may or may not be combined with an edge compute network.

 

Okay. I think it's clear as mud now. How about you Will? You understand it perfectly?

 

Um, you know, when you asked him to explain a term that maybe not everyone knows, I thought you were going right for DevOps. And I was like, Oh, finally.

 

Oh.

 

If only someone could explain it to me.

 

Great.

 

I just wanted to stick to the easy questions to start with. Ha

 

No doubt.

 

ha ha.

 

So you're the third guest we had talking about WebAssembly from a DevOps context. And each week, I come away getting more and more excited. So can you? Can you give me like, what's the big fascination with running WebAssembly out on the Edge server network?

 

Yeah, totally. So we have a saying where, you know, WebAssembly has these three properties, security, performance, and portability. And these three aspects made it a really well-suited technology for web browsers, because that's where WebAssembly started. When you're running code in the web browser, it's always untrusted code. It's always code that you're just... pulling from some random URL, you have no idea what it may want to do, and you need a good protection. And so when engineers wanted ways to run... languages other than JavaScript in the browser. They tried a whole bunch of different wacky things, but we've ended up with WebAssembly because it is a sandboxed runtime for bytecode. And that bytecode can be generated from a whole bunch of different languages. So you can compile C code to it. You can compile Go code and Rust, whatever. And it will maintain those sandboxing properties that are really, really useful for web browsers. But we needed a way to do that without sacrificing performance, right? We wanted to be able to run C code without it, you know, being super sluggish because C is not supposed to be sluggish.

 

Yeah.

 

And so WebAssembly was the result of all of this work. And just because it was designed for Web browser doesn't mean that it's not useful in other places. And so taking those, you know, three really nice properties, some very smart folks started... developing WebAssembly runtimes that were decoupled from the web browser. So. We want to be able to take advantage of the speed, right? High performance code. We want to take advantage of the security, these really tight, sandboxing properties of web assembly. And we want to take advantage of portability, i.e. being able to run this piece of code that you've compiled absolutely anywhere without needing to worry about, oh, is it ARM? Is it x86? Is it Linux? Is it Windows? We wanted something universal. And so all of those properties also lend themselves really well to the server.

 

Right on. Whenever you do this, are you, you know, we were talking about IoT things earlier. From the server side of this equation, though, what are the resource constraints? Can you configure as much CPU and memory resources as you need in disk space? Or are you kind of operating in a tighter environment?

 

Yeah, so this is something that's evolving all the time. And so there are some memory constraints on WebAssembly, but they are quickly being removed. The wonderful thing about WebAssembly and the sandbox that it runs in is that you do get very fine grain control over all those things. What disk is it able to use? How much CPU bandwidth is it allowed to have? And how much virtual memory are you allowed to use? And... because you're not directly running a program, you know, on just a bare CPU and letting it run rampant, we have a lot of these controls. And so that's one of the features that makes it really good for edge computing because, you know, we're orienting our use of WebAssembly, for the most part, around smaller ephemeral pieces of compute, like what is traditionally known as a cloud function. And so these things are spinning up and, you know, being torn down. potentially thousands of times a second. And so it's really useful for us to be able to say, hey, we wanna have the capacity to run, you know, 10,000 of these things concurrently on this one box. Let's make sure we limit each individual one to this slice of memory and computing power that it's allowed to have and be very sure that, you know. one module won't suck up all the air in the room and make it hard for the other modules on the system to get their time.

 

Right on. So that sounds very much along the lines of my experience in implementing DevOps, is defining the operating environment and what resources it has available to it. What tools exist to support this? Is this something you can build with Terraform? Or do I see to control?

 

Yeah, so we haven't really come onto a Agreed-upon paradigm, I guess for running

 

Yeah.

 

WebAssembly in the cloud yet What is interesting is that And I don't know if this is a coincidence or if this is intentional But a lot of the folks who are interested in WebAssembly on the server Also seem really interested in things that are not kubernetes And You

 

In

 

know,

 

other

 

it's...

 

words,

 

In other

 

they

 

words,

 

have

 

they

 

Kubernetes

 

have

 

experience.

 

Kubernetes experience. That's

 

Ha ha.

 

exactly right. And I think one of the big reasons for that is it's not even that Kubernetes is bad or that Kubernetes is too much or any of those things. It's just that WebAssembly and containers just are operationally quite different, right? WebAssembly, it's not an operating system. It is not really resembling a container. except from a really like 10,000 foot view. A WebAssembly module is not. you know, a micro VM and it's not something that looks like a virtual machine or a container. It is more like just a single program. So, you know, whereas in a container you might have a curl binary and a wget binary, you know, the WebAssembly module is more akin to just one of those executables inside of a container. So you can combine WebAssembly with a container. You can run WebAssembly outside of a container because of the way it's sandboxed. You do have a lot of flexibility there, but I think there's a general... you know, sentiment that we don't necessarily need Kubernetes in order to take advantage of WebAssembly on the server. And so the thing that people seem to be very interested in right now for running WebAssembly on the server is HashiCorp Nomad. So we're using it. I believe our friends at Fermion and Cosmonic are also using it pretty heavily.

 

Yeah.

 

And I think it lends itself pretty well to what we're trying to do here.

 

Right on.

 

So I'm curious to dig in a little bit more to a topic. You already started to talk about it, but you mentioned that the three, I don't remember what they all were, but the three characteristics of WebAssembly, one of those you mentioned was security.

 

Mm-hmm.

 

How is it the WebAssembly is inherently secure, or is it, or what do you mean by that? Like why would WebAssembly be more secure than running Ruby or JavaScript or whatever other random language I might choose?

 

Yeah, totally. So WebAssembly is designed to be inherently secure, and that is by way of a deny by default capability system. So if you look at any old program, that program is making syscalls, right? It is asking the operating system for stuff, whether it's access to a file or a socket or whatever. Every program is making system calls to get access to resources. And in the WebAssembly world, you don't just get free for all access to those system calls. You can't just ask the operating system for a file handle and just be given it by default. The WebAssembly runtime actually gives you access to nothing. So by default, if you haven't explicitly granted the access to a particular file or are completely blocked from accessing that resource. So when you're configuring the WebAssembly runtime, you have to go in and say, okay, I'm gonna run this module and I'm gonna give it access to this directory. I'm gonna give it access to this port. And when it uses that port, it's allowed to access these things and you have to be very explicit about it. And because of this, it really stops malicious code from being able to do much of anything. without your explicit permission. So if I download a WebAssembly module and it has a crypto mining feature to it, call it a feature, call it a bug, whatever,

 

Cut. Ha

 

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

ha ha.

 

if I haven't explicitly given that module access to whatever blockchain it needs to talk to, it won't be able to do its job. And so I can protect my infrastructure or I can protect my computer from those kinds of malicious attempts at doing something nefarious and still allowing my code to do what I intended that code to do, which is maybe talk to a specific API or connect to a specific database or read a specific set of files, while being very, very sure that it can't go outside the bounds of what I've allowed.

 

So it sounds like this is really a feature of the runtime more than like the language spec itself. Is that a fair distinction?

 

It is a very tight concert between the WebAssembly bytecode and the runtime. The difference between WebAssembly as a specification and a WebAssembly runtime is very blurry. And the nice thing is that... the specification actually covers all of it. So the way that virtual memory is handled, the way that handles are given to code to access things outside of the sandbox, all of these things are very well documented and anybody can go and implement the specification. So there are multiple different WebAssembly runtime implementations that you can choose from, both in the browser and outside of the browser. And so

 

Thanks for watching!

 

that's really nice for us because it means that well-documented set of guarantees about how these programs are supposed to behave and it is really a just a nice collaboration between the WebAssembly bytecode of the actual module itself and then the runtime that it's being executed in. They work together to ensure we have these security guarantees.

 

So I suppose that's different from like jails or any other sort of virtualized sandbox or whatever, where you maybe block file system access or you block network access. Just in that it's, there's no surprises for one thing, because

 

That's right.

 

you expect that those boundaries will be there unless they're removed, rather than the reverse where you expect no boundaries. You expect a CH mod to work and the owner doesn't. Like what? So that would be one difference. And I suppose the other difference, maybe I'm wrong on this, but I would imagine that the API is just simpler and more straightforward in WebAssembly than it is on any random operating system where

 

Yeah.

 

you have access to everything and even hardware interrupts and everything like that.

 

Yeah, that's right. There are parts of WebAssembly and WASI, which is the WebAssembly system interface, that were modeled after POSIX, but it's not directly tracking how POSIX works because there is a lot of legacy baggage in POSIX and all those designs. And so they wanted to emulate the good parts of POSIX while still bringing in some, you know, new simplicity and some new explicit characteristics that POSIX never had.

 

So POSIX, the good parts book to complement the JavaScript, the good parts book

 

That's right.

 

coming soon

 

Yeah,

 

from

 

right.

 

O'Reilly, I hope.

 

Somebody should definitely write that. It should be entitled WebAssembly the good parts of POSIX.

 

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Hahaha!

 

So you work specifically with edge computing. When should somebody consider you? The question I always ask is when should somebody use this? Whatever

 

Mm-hmm.

 

this is. In this case, let's say it's WebAssembly for edge. Did you call it the edge cloud? Is that the right ordering

 

Yeah,

 

of phrases?

 

yeah, yeah, you can call it edge compute, you can call it edge cloud. I think all of those aren't changeable.

 

So maybe before I ask that question, what alternatives are there? What other things are people doing that you're suggesting this is a better solution?

 

Yeah, so there's two answers to that question because we do run an edge network, but we are using that edge network specifically for running plugins. And so there's the, what are the alternatives for the plugins answer? And then there's what are the alternatives for the WebAssembly on the Edge answer.

 

Okay.

 

I'll probably focus on the WebAssembly on the Edge part because this is a DevOps podcast. So the biggest alternative right now is JavaScript isolates. big names of like CloudFlare and Deno are using JavaScript isolates to accomplish a similar task as WebAssembly would serve. So when you are using CloudFlare workers or when you're using Deno deploy, they are spinning up essentially a tiny little fraction of the V8 JavaScript engine and they are executing your code within that little isolate or you can think of it like a jail or something like that. And that is currently the most popular way to run an edge network. And part of the reason there is, is a lot of the same

 

Thanks for

 

properties

 

watching!

 

that make web assembly good, you know, have also been exhibited in V8 because V8 is probably one of the best tested and most trusted pieces of code out there, uh,

 

Mm-hmm.

 

because it runs Chrome, right? All of the JavaScript, uh, that is executed in Chrome is executed in V8. And so, um, You know, Cloudflare just open sourced their implementation of V8 called workerd and it is the thing that allows them to run untrusted JavaScript. However, if you look at the workerd, you know, GitHub repo, you'll see that they, they note that just running workerd by itself, just running a V8 isolate by itself is not sufficient. to ensure you can't have any malicious code, you know, wreaking havoc in your infrastructure. They also, in their infrastructure, when they run it in the Cloudflare Workers Cloud, they have to add additional layers on top. And that's not part of the open source project, that's out of scope and that's, you know, obviously very understandable. But it just goes to show that, you know, JavaScript by itself and a JavaScript engine by itself is not enough to satisfy the security requirements of running untrusted code. Whereas WebAssembly has a better starting point for that problem. And so it's much easier to take a WebAssembly runtime and use it for that purpose. There are a bunch of different concerns when you're comparing these two. So performance, language support, all these kinds of things. they differ and it really depends on the problem you're trying to solve, right? So Cloudflare has done a great job of being able to, you know, serve edge requests for web apps. And a lot of web developers are JavaScript developers. And therefore, you know, running an edge function written in JavaScript that's connected to your web application that's also written in JavaScript makes perfect sense. And that's why it's become so popular. But when you look at what we're trying to do with plugins, you know, not everybody who writes backend systems is a JavaScript developer. There are a lot of Go, Rust, and Python developers, etc. And so we think that WebAssembly has a better overall support for a wider variety of languages, while still giving us those security and performance guarantees. And that's why we decided to build our platform on top of WebAssembly.

 

Nice. So yeah, then to the question that led to that one, when does it make sense for somebody to consider WebAssembly for their own problem, whatever they're trying to solve, especially if they're in this edge computing space? And you've already touched on some of the answers related to security and so on. But just a little more specifically, what litmus test maybe would you use if you're debating WebAssembly versus something else?

 

Yeah, so I think the litmus test is, do I have a security need that trumps my ability to just run something in a Kubernetes cluster, right? That is the biggest reason why you would use WebAssembly. If you are scared to run something because you're worried about the effect it could have on your system, you should probably run it in a WebAssembly container. instead of running it in a regular container.

 

Okay.

 

And third party code is the best example of this, running explicitly, like accepting third party code from any random person, and then running it in your cluster is terrifying. And I would never just Python start a... random third-party script inside of my own kubernetes cluster i would never do that so that is the number one thing that would push you over to web assembly now i think over the next couple of years what we'll see is that

 

you

 

the performance story will also start making a lot of sense so if you need to run you know a ton of parallel ephemeral functions you know lambda style serverless compute WebAssembly is going to become the most attractive option because it is going to be a standardized runtime across a bunch of different languages that let you run these very fast. Like maybe they're only alive for a millisecond or 10 milliseconds but you need to run thousands of them or hundreds of thousands or millions of them all at the same time. WebAssembly is going to start looking really really attractive because you have so much less overhead compared to using a container or a micro VM where those things take you know tens or hundreds of milliseconds just to start up whereas a WebAssembly module can be run and done. in one millisecond.

 

So you got me thinking about running untrusted code. Since so many other languages can compile down to WebAssembly, does it help if you want to run untrusted code written in another language? Maybe you have, let's say JavaScript, because that's a simple, it's a common thing. A lot of tools have some sort of way to create JavaScript plugins or snippets or whatever. I imagine that running compiling the JavaScript WebAssembly and then executing it in WebAssembly is safer than running it in V8.

 

Yep.

 

What are the implications of all of that?

 

Yeah, totally. So we have started to see a... a surge in people running JavaScript inside WebAssembly. And it sounds kind of counterintuitive, because in the browser, you run WebAssembly inside JavaScript.

 

Yeah.

 

So it seems a little backwards. But what we're able to do is we're able to take the entire JavaScript runtime, compile that to WebAssembly, and then give it some

 

Mm-hmm.

 

JavaScript code to run. So there are two main interpreters that are currently being used inside of WebAssembly. There's QuickJS, and then there's SpiderMonkey. SpiderMonkey is the Firefox version of V8. adding this extra layer of sandboxing you can basically take this untrusted JavaScript and just throw it into the sandbox and let it try to do whatever it wants to do but only allow it to do the things you wanted to allow it to do

 

Mm-hmm.

 

and so this is awesome and you get some really good you know security properties from that but you know there are some performance concerns to be had there because you know with these with these JavaScript engines we are doing you know just-in-time compilation we're doing all sorts of different optimizations to make sure that that JavaScript is running fast. And those are the kinds of code generation problems that don't currently work 100% as well inside of WebAssembly as it does outside of WebAssembly.

 

Mm-hmm.

 

That is getting, you know, infinitely better because there's a lot of WebAssembly spec improvements that have come through in the past year or two that are making those types of things much more efficient. So Fastly, for example, their compute at edge product runs SpiderMonkey inside of WebAssembly on their edge network. they are able to do a lot of the same things that CloudFlare can do with V8, except they have this additional layer of security around everything. And so while CloudFlare has probably spent millions of dollars hiring a huge security engineering team to make sure that they're locking down the V8 engine, Fastly is having a bit of an easier time with it because they have the security guarantees of WebAssembly wrapped around their JavaScript engine from the start.

 

Nice. So you can run WebAssembly and JavaScript, and JavaScript and WebAssembly.

 

Mm-hmm.

 

And after Will completes his promise from last week's episode, we'll be able to run Kubernetes in the browser with WebAssembly. This looks like a great stack of house of cards we're building

 

Yeah,

 

here.

 

yeah, somebody recently was able to run WordPress in the browser using WebAssembly, which is an absolute feat. I used to

 

Hahaha

 

work for WordPress and so I know what behemoth that ends up being. But yeah, there's all sorts of different crazy use cases that you can enable when you have this secure sandbox that can just pretty much run anything.

 

It's almost as if we're working on machines that are like able to emulate each other. We need a

 

Yeah.

 

term for this. Like maybe we could name it after Alan Turing who invented

 

Right.

 

this sword of light concept.

 

Yeah, but like you say that, but like WebAssembly is almost like a virtual CPU, right? It is

 

Right.

 

an instruction set. that you can target that is completely agnostic to any of the hardware platforms out there, which is just an incredibly useful tool to have at your disposal because I can build a WebAssembly module and then without recompiling it, I can run it on ARM, I can run it in the browser, I can run it on an x86, I can run it in a container. It's just a very flexible thing to be able to do.

 

WebAssembly

 

soon.

 

reminds me, oh, go ahead, go ahead Will, you go first.

 

Yeah, I just wanted to check and see what's the learning curve of this security model look like. Because we have a lot of tools that have powerful security built into them. But in terms of practical application, a lot of people can't find the documentation, or the instructions, or the advice that they need to set the security model up right. So they just end up giving. root permissions to everyone because I can't get it to work otherwise. So what's that world look like in WebAssembly?

 

Totally. So that I think is where WASI comes in. So WASI is the Web Assembly System Interface and it is a set of these bindings, right? It is a set of these host capabilities that are being standardized in the W3C. And what WASI allows us to do is essentially have a commonly agreed upon set of guardrails. that you can enable on the WebAssembly runtime. So you can think about it like layers, the WebAssembly runtime is at the bottom, by default it has no permissions. When you enable Wazzy on the runtime, it opens up these well-defined and well-tested capabilities such as accessing files, such as accessing the network. And it gives relatively easy to understand knobs that you can twist and turn to control how those capabilities behave. Now, You can go further than that. You can add capabilities beyond what Wazzy enables. And that's what we do in our platform is we do Wazzy++. So Wazzy plus additional capabilities. But by default, if you're just compiling Rust code to WebAssembly and then executing it, just by enabling Wazzy, you can get a lot of useful things like being able to access randomness or the system clock. These are all things that are included in the Wazzy specification where you can turn them

 

Mm-hmm.

 

on you know that they've been well tested and you know that they are implemented correctly. And so you can get probably 90% of the useful system calls that you need while still having, you know, the knobs and levers to play with, such as only granting file access to particular directories or particular files. but you don't have to implement all of those host calls yourself because they've been pre-implemented in the Waze libraries. And so that's the great starting point for everybody. And I find that it is really helping with the learning curve. But if you want to go beyond that, like what we've done by adding additional things on top of Waze, that's where the learning curve does start to spike pretty heavily. And I think that will improve with something called the component model that is being worked on right now. And that is the ability to essentially declaratively define what a module needs to import in order to operate and what it exports in terms of the methods and functions available in the module. And

 

you

 

so when this component model is done and we're getting pretty close to that, you will be able to look at a WebAssembly module and say, hey, this thing needs access to these files, it needs access to this network capability, it needs access to something that provides randomness and crypto. capabilities and so I'm going to explicitly enable those few things that this module needs and I know that this module provides to me these five or six functions that I can call from it and so this is going to be a standardized way for anybody to understand what a module imports and what it exports and that's going to make things a lot easier

 

When you say we, are you referring to suborbital or like the WSI open source committee?

 

the collective we, I think the entire WebAssembly community.

 

Cool. And where's the starting point for that community? Is there like a website or?

 

Yeah, so there's two main things that I would point people towards. There is a WebAssembly Discord server where a lot of the standards folks and the working groups hang out. And then there's also Wasm Builders, which is a community for people to show off what they've built with WebAssembly, learn about how it works and all these kinds of things. So if you go to wasm.builders, that is a really great resource for folks who are just learning.

 

So that's the place to drop in your Kubernetes that runs inside of WebAssembly.

 

That's exactly right.

 

Nice.

 

You know where to

 

Now

 

put it

 

we

 

now

 

s-

 

Will, when you have it done.

 

Right?

 

Yeah, I'm starting a countdown timer. We'll see how long it takes for that to show up.

 

So I'm curious, how does WebAssembly work with cryptographically secure random number generators? I mean, not all hardware necessarily supports that. Does Wasm give you an exception if it can't generate proper randomness?

 

Yeah, exactly. So this is a really great way to describe how the WebAssembly host-guest relationship works.

 

Okay.

 

So if I am writing a program, that program needs access to randomness. There are syscalls across most operating systems that let you, you know, like arc for random or something like that where

 

Mm-hmm.

 

the the operating system Will essentially use some hardware voodoo under the hood to generate Something close to true randomness and then just give that back to you in WebAssembly You know that is just like everything else a host call that can or cannot be mounted To the runtime when you start it up And so if I go and run that program post implementation of randomness, yeah, it will throw an exception and it will not work at all because that is the deny by default nature of WebAssembly. But if you do provide that host call, it can come from a variety of different places, right? So if I'm running that WebAssembly module in the browser, the browser APIs could be used to supply that randomness, right? There are crypto primitives inside of Chrome and Firefox and whatever that can be plugged into that host call to provide randomness but then if I run that same WebAssembly module in WasmTime on a Linux machine, WasmTime can plug in the standard Linux syscall implementation of randomness to supply the same thing. And to the guest code, to the code inside the WebAssembly module... doesn't care, it doesn't know what's going on, it doesn't know where that source is coming from, it's just calling, asking for some randomness and getting back something. So you could theoretically, and I don't recommend that you do this, but you could theoretically, you know, provide a host implementation of that random function that just returns four every single

 

Hahaha!

 

time, and you could screw up a lot of people's day. But this is where WSI is really helpful, right, because it is a set of, you know, really well-defined and well-tested implementation for these kinds of things.

 

Four seems pretty random to me, I don't see the problem here.

 

Hehehehe

 

I mean it's much more random than 42 so

 

Hehehehe

 

Yeah, I mean, I thought you were going to say 42, but then you said 4. Like, totally random. ..

 

I'm pretty

 

right?

 

sure I'm quoting an XKCD.

 

So back on suborbital, you talk about hosting functions, like untrusted functions. And I'm

 

Mm-hmm.

 

trying to think of specific examples of that to just relate it, because I'm pretty slow to grasp concepts. So I look for things I can relate to. I'm thinking everything I write sends logs to, you know. my logging facility, whether that's Data Dog or Splunk or whatever, or I send metrics to Grafana. Would you consider those log and metric collection services to be good things to implement and deploy? Assuming that I had things all over the world that were just shooting info to my logging facility to deploy that as a function out on the cloud edge, or edge

 

Yeah,

 

cloud?

 

yeah, that's definitely something you could use it for. So what we strive to do is just give you plugin points in the logic of whatever it is you're building. And so in the logging and metrics use case, you could implement the actual logging and metrics systems itself in WebAssembly, you could definitely do that. But what we're more focused on is allowing the end user of one of those systems to modify and customize how it behaves in the first place. So if I have something like OpenTelemetry, for example, it is sucking in metrics from potentially thousands or millions of different places around the world, and it is storing them and it's making them queryable. And what I could do is I could add a plugin to that system where anytime I receive my user count metric, I could go in and I could tweak that, I could run it through. you know, a check against a separate system to make sure that the numbers are accurate or I could augment that with, you know, you're telling me how many users I have, okay, how many, how many, you know, functions have that user deployed or something like that. Like you can run custom logic in that chain so we could actually, right inside of an open telemetry service, you could add a plugin so that the user of that system could define custom logic that happens as those metrics are being ingested, for example. And so one way to think about it is a much faster webhook, right? So

 

Right.

 

today, when you have a SaaS application and you want to do something custom, usually what you're doing is you're deploying a server that receives a webhook

 

Mm-hmm.

 

and you're entering a random URL, like a Lambda URL into that SaaS app, and it's just throwing post requests over the fence. and you have to handle it on your deployed code somewhere. So the prospect of WebAssembly plugins is that instead of that whole dance, let's allow the user to just give us a little snippet of code. We'll compile it to WebAssembly and we'll run it inside the SaaS application itself so that we don't need to send traffic over the public internet. We don't incur that huge latency. We don't have the security problems that go along with it, but the user can still insert their own custom logic. And that's what I find is the best way to describe what we're doing here.

 

Right on.

 

Cool. So I wanted to get back to the comment I started to make a minute ago. Correct me if I'm wrong.

 

You

 

Is it

 

are.

 

fair to say that WebAssembly... Alright, I'm wrong.

 

Hahaha

 

No point in finishing the question. Just assume I'm wrong. No. To me, every time I hear about WebAssembly, I'm reminded of Donald Knuth's book, The Art of Computer Programming, where he invents a... I think it's called MIX. It's an assembly language that is, it's hyper simple. It's designed for the purpose of educating people about how computers work. It's not designed for real hardware, but neither is WebAssembly, right? Of course, the difference is the WebAssembly is designed to actually be executed and it's designed to be useful and fast. But from a conceptual standpoint, it's quite similar, I think. You know, it's, we have some registers here and we have a block of memory and here's the instructions you can use to... to operate on it. And of course, with this mixed language, there are emulators that you can use for the purpose of education. But with WebAssembly, you know, people do real things with it, not just learning how to write assembly. Is that a fair comparison?

 

Yeah, yeah, it's like WebAssembly, as you say, it has a set of instructions, like it's a stack-based VM, it manages virtual memory, it has all the things that you need to run code. And the fact that, you know, that code is originating from a Rust code base or a Go code base is almost irrelevant, right? Because at the end of the day, we have this common format now

 

Mm-hmm.

 

where we can just know for a fact that... the instructions and the way that memory is manipulated is going to conform to this standard and if it doesn't, we'll basically just kick it out.

 

seems reasonable.

 

What other questions should we be asking? What's your favorite topic that we haven't touched on yet?

 

I think you've covered your bases pretty well. Why would I use it? What is it useful for? Some people like to delve into language support because there's some interesting things there, but.

 

Yeah, I mean, I have a sense that lots and lots of like, like any mainstream language has WebAssembly support, but maybe I'll be surprised. What can you tell me about that?

 

Yeah, so there are a whole spectrum of different language support types, I think I would call them.

 

Mm-hmm.

 

There are the languages that essentially... build it in as a first class citizen, right? So there's Rust. Rust from the beginning has had a really well supported first tier WebAssembly target. And then you have languages like Python and Ruby where they're just now getting around to adding officially supported distributions for WebAssembly. So I think in the next release of CPython or maybe the one that just happened, they added WebAssembly as an officially supported platform in CPython. And so we can now say for, you know, pretty certain that Python is gonna support this thing for the foreseeable future. And it's not just some person's random fork of the Python interpreter that

 

Mm-hmm.

 

will need to be used. And so there's a bunch of different stories like that. And the same thing applies to JavaScript, right? We now have officially supported builds of SpiderMonkey that are intended to be. you know, distributed as WebAssembly. And so as we move forward, we're gonna see more and more support for WebAssembly, both from the compiled languages like Go and REST, but also from the interpreted languages like Python and Ruby. And then you have this kind of third category, I guess, of languages that were specifically built for WebAssembly and they don't support anything else. So, you know, Grain. is a great example of this. Assembly script is another example where these languages were designed around the spec and the constraints of WebAssembly to begin with. And it's entirely possible that we will see use cases and design paradigms built around these languages because they are specifically targeting this new way of running code.

 

Interesting. Now, some traditionally interpreted languages, I think, will give you the option to be compiled. Like I used to be a Perl developer. I know that they had some options to, or experimental

 

Mm-hmm.

 

probably, to compile your Perl into something that might be faster. Of course, you have some downsides with that, or maybe upsides, depending on your perspective. You know, you can't necessarily just like, have your program rewrite itself like you can in an interpreted language. You can't just do an eval and expect it to do something meaningful. Um,

 

Mm-hmm.

 

but I imagine you have the exact same trade-offs when you're taking a language like Python or Perl or JavaScript and executing it in. Web assembly, you can either just interpret it with a web assembly, uh, you know, an interpreter running in web assembly, like you said, a spider monkey, or you could try to compile it to something compiled with the normal caveat. Or is there some new nuance when you're using WebAssembly?

 

Yeah, so there are some very interesting use cases where people are compiling code to WebAssembly and then compiling that WebAssembly back to native code. So there is a, there's actually some components of Firefox, I believe, where they wrote the original code in Rust, they compiled that Rust to WebAssembly, and then for each distribution of Firefox, they would compile it back to x86 or whatever bytecode. and then

 

Mm-hmm.

 

include that as a static library in the Firefox distribution. And I forget the exact details of what they were doing with it, but it was essentially because they wanted to add that extra layer of sandboxing. Because when you take WebAssembly by code and you transpile it to a platform native format, you still have all of the same memory guarantees. You still have all of the same. properties of WebAssembly, but you have essentially converted it into some platform native assembly. And so there are some pretty wacky things going on like that. I don't know if that's going to become the norm, right? Maybe we just use, you know, maybe we see a world in which WebAssembly uses intermediate stage to just add a layer of security onto native binaries. That's possible. I don't think that's where things are going. But there is definitely a use case for it. I think the norm will be, you know, web is the WebAssembly binary itself is the artifact that I'm deploying. And then the runtime that it, you know, eventually ends up inside is just able to run it natively. I don't know if I answered your question, but

 

I think so,

 

there's

 

yeah.

 

some there's some cool stuff going on there.

 

I'm curious about WebAssembly runtimes built into operating systems. Like, I could easily see, maybe it's

 

Mm-hmm.

 

already happened, I could easily see the Linux kernel having a WASM runtime built in so it can just execute WebAssembly as close to the bare metal as possible. Is that something that you see happening or coming?

 

Um, so I think what you're describing is eBPF, right? Um,

 

Okay.

 

eBPF was effectively a sandbox, um, designed specifically for the purposes of running inside of a kernel. I think I've seen somebody

 

and somebody

 

get WebAssembly

 

get WebAssembly

 

running inside

 

running inside

 

of eBPF,

 

of

 

which

 

BPPM,

 

is

 

which

 

just

 

is

 

a,

 

just

 

you know,

 

a,

 

a,

 

you know.

 

another layer that breaks the brain a little bit, but, um, yeah, for something like the kernel where you are. very tightly constrained and you have a very, very, very strict set of things that you can and absolutely world-endingly cannot do.

 

Mm-hmm.

 

I think having a specific virtualization technology for that does make some sense, which is why eBPF exists. I think WebAssembly is a little bit too generic to be in the kernel itself. Now if you're saying, you know... future Linux distributions will ship with a WebAssembly runtime just as part of a standard distro like you know you get curl and you get a WebAssembly runtime

 

Right, right.

 

as part of a standard toolkit that I could absolutely see happening but WebAssembly in the kernel itself I don't know.

 

Time for pics?

 

I think so. I mean, I'm...

 

Sounds good.

 

Yeah.

 

Cool, let's do some pics. Do you have any ready for us Will?

 

I do. I've got... I had to reach over and grab it. It'll be a show and tell for you too, but it's an audio pick for our listeners because this is a podcast.

 

Yeah.

 

So this week, I've got it's a wallet called Steel Wallet. So I've got my seed phrases for my crypto wallets that are written down on a piece of paper and stored in a supposedly fireproof safe in my house. But then it dawned on me, while the safe may be fireproof, it doesn't mean it's not going to get really hot in there. And either way, in the event of flooding, well, they didn't make any promises about flooding. They said fireproof. And so I was kind of worried about those seed phrases. Not that I have a ton of crypto, but I would be a little bummed to lose what I do have.

 

Hehehe.

 

So I ended up buying this thing, the Steel Wallet. It's got support for two wallets on it. these steel little trays. And it comes with a whole bunch of letters that are already pre-stamped. Some of these steel type wallets, they send you some letters and a little hammer, and you have to stamp your own letters. And I was like, ah, yeah, how about no? So I got this one. The letters are pre-stamped. And then you slide them into the little tray here. And then the tray locks shut so that the letters don't fall out whenever you. move it around or carry it. And then I thought this was a really cool feature that I wasn't expecting. It's got these little security stickers, so once you put your phrase in there and you close the lever, you put this little sticker over it and it's one of those stickers that once you peel it off, it completely screws up the sticker so you can tell that it's been tampered with. It was kind of pricey, it was $75 US for that, but the quality seems pretty good and I'm pretty excited about it. So that's my pick of the week.

 

That's Steel Wallet, that's the brand name, or that's

 

That

 

the,

 

is the

 

the,

 

brand name.

 

S-T-E-A-L, right? Like you're stealing my wallet.

 

No,

 

Hehehehehehe

 

no, that's the other part of crypto. That's next week's pick.

 

Oh, right.

 

hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahah

 

Steel wallet ST E now ST

 

There you go.

 

EEL wallet

 

I got it.

 

Not even gonna try to spell wallet now

 

Q you.

 

Hehehehehe

 

Right? Is this a

 

Whoa.

 

sobriety test?

 

We would fail that every week.

 

This is not how I saw my intervention going down.

 

No.

 

Hahaha.

 

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

All right, I have two picks. The first one actually I picked last week and I'm gonna pick it again. It's some shameless self-promotion. My new YouTube channel Boldly Go is boldly going and I'm having fun with it. So I just uploaded another video this afternoon.

 

Nice.

 

Go tutorials and stuff like that. So if you're learning Go or want to learn Go, check out Boldly Go on YouTube. My other pick, it's kind of related. I bought a used 21 inch monitor about a year and a half ago. It's a 16 by nine monitor that I use when I'm making my tutorial videos. So I can easily capture the proper 16 by nine aspect ratio on the screen. Cause before that I was using, I have a double wide monitor and it's really, really hard to get a window exactly the right size so that it captures correctly. But I had this problem that this 21 inch monitor was way too big for that purpose. Not because I couldn't see it, I could see really small text that when gets transcribed into a YouTube video, especially on a phone, that text is super tiny.

 

Yeah.

 

So I did some shopping and I found a nice little 14 inch IPS full HD monitor. It's called, the brand is ZFTVNIE. I don't know if you're supposed to pronounce that or what. Honestly, I don't think the brand matters that much. I found about three or four different options. They're about between a hundred and 120 bucks. So not so bad. There are some really expensive ones. You get touchscreen options and stuff like that. Some are as much as three or four or $500. But I really like it. It's super crisp image. It's a 1920 by 1080 resolution, which is what I wanted. You can

 

Yeah.

 

also get cheaper ones if you want lower resolution, but I wanted full HD for my videos. So that's my second pick. Again, the brand isn't so important, but. just having a 14 inch monitor, it sits right above my monitor. And so it's next to my webcam. So I can basically, it looks like, almost looks like I'm looking at my webcam when I'm looking at the monitor, so.

 

Kind of like a teleprompter.

 

Kind of, yeah. I mean, it would be a little bit nicer if it was directly in front of the cam for that purpose, but it's close enough for government work here.

 

Okay.

 

Yeah, I think my pick, something that I've been very enamored with lately is Google Cloud recently released their ARM VMs based on the Ampere platform. And I know they're like an early beta, but they've been super, super rock solid for us. We want to run everything on ARM because the price, you know, price performance ratio you get there is so good. And you know arm has become so ubiquitous especially with you know Macbooks and all that stuff in the last couple of years that you know We've we've basically been developing arm first, which is kind of a crazy thing to think about but yeah until recently You know the the arm offerings were fairly sparse and we are not an AWS shop And so while the graviton line is very very cool It was not something available to us because we're just not on the AWS bandwagon And so having ARM machines available in Google Cloud has been super awesome. And they're 100% compatible with all the things we need to do. We're terraforming them. We're doing all sorts of automation, and they've been really, really good.

 

Sweet.

 

Nice.

 

I'm still waiting for those virtual Commodore 64s to come to Google.

 

Hahaha

 

What? So one last question. We had Matt and Taylor on the show. We're trying to get both of them back to an in-person show with folding chairs and arena-style event to see whose Wasm platform reigns supreme.

 

Hehehe

 

Are you in to make this a three-way match?

 

so in. Sounds fun.

 

Sweet.

 

Ha ha.

 

Right on. Right on. start picking out your lucha libre mask

 

Did

 

Ha!

 

I just sign up for a cage match?

 

maybe

 

I think so. I think you did. And it's been recorded. You can't back out now.

 

Yeah.

 

That's

 

Ha

 

right.

 

ha. Awesome.

 

Very good.

 

Well, I think that's a wrap. It's been a

 

Yep.

 

lot of fun. Thanks for coming on.

 

Appreciate it.

 

Hope to talk to you again soon at our cage match.

 

Hehehehe

 

Thanks everyone for listening.

 

Yeah.

 

We'll talk to you next week.

 

That's

 

Right

 

fun.

 

on. See you guys.

 

Have a good one.