Connor Hicks: Rather than focusing a lot of our efforts on building a Suborbital community, we put more effort into the Wasm Builders community, because it is more about educating folks about what WebAssembly can do, why it's exciting. And then all of the different open source projects and a bunch of the different startups in the space are all pooling our resources into this one community. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Today we're talking to Connor Hicks of Suborbital. Suborbital is a new open source project that allows developers to create WebAssembly projects embedded in other applications and other WebAssembly utilities. We talk with Connor, generally, about the history of WebAssembly, it's uses, and then the certain things that suborbital is tackling. It's quite fascinating. This feels in many ways, the future of some parts of software development, and Connor is right at the heart of it. I'm joined today by Connor Hicks to talk about Suborbital. Thanks for coming Connor. Connor Hicks: Yeah, thanks for having me. It's great to be here. Eric Anderson: So to kick things off, I'm excited about Suborbital. You are on the cutting edge of a lot of things. Tell our audience what Suborbital is all about. Connor Hicks: Of course. So Suborbital started out when I wanted to experiment with distributed computing projects, specifically. I wanted to build my own functions as a service system because I studied distributed computing in school and it wasn't a muscle I was able to flex at my day job. And so I wanted to build something interesting on my own. And when I started building this project, it was based on Containers, Docker, because that was just the default thing, I guess, that people reached for. And let's keep in mind that this was back in late 2018 going into 2019. And so I built the first version of this thing and the containers themselves ended up being the bottleneck. They ended up not being able to keep up with what I was trying to do because Containers take a little bit of time to start up. It's the cold start problem. And so I got frustrated enough with this even after some time trying to work around it, that I pretty much shelved the project because I was just annoyed. Eric Anderson: Yeah. Connor Hicks: And for a couple of months I didn't even work on it. But then I started seeing people talking and writing about WebAssembly outside of the web browser, because up until that point, that is the only context I had thought of it in. And we can go into all about what WebAssembly is. But at its base, it's a way to run code in a sandbox, which is really, really useful for web browsers because web browsers are very tightly sandboxed. But people started talking about WebAssembly in this, outside of the browser context, and it peaked my interest. And after reading more about it, I thought that the properties that made WebAssembly useful could also benefit this project that I had given up on. Connor Hicks: So I went and tore all of the docker out of this project and I started building it back up using WebAssembly, which, at the time, was really quite frustrating because WebAssembly itself was not mature. The tooling was not there. You could pretty much only use Rust or C++. But after a little while, I was able to get it to work and it was actually keeping up with the performance that I needed. And so I was like, okay, maybe there's something here. Maybe we can actually create a new kind of serverless, or functions as a service, based on this technology. So that's what led me to continuing down that path and start building real projects that could be released and used by other people. Eric Anderson: Got it. And maybe we should take a couple steps back on some of these topics. So let's go in on WebAssembly a bit for just a moment. So WebAssembly is this thing originally designed for browsers that allow people to run. I'm guessing it's mostly different languages, right? So you have JavaScript in the browsers today, but what if you want to run something else? Is that the original attempt? Connor Hicks: Yep. That's exactly right. So there've been a couple of efforts over the years to run languages other than JavaScript inside the browser. And they largely, I wouldn't say that they all failed, but they all ended up having some kind of flaw or some kind of trade off that was not worth it in the end. So there has been asm.js. There was something called Native Client. These were all projects out of various companies, Google, Mozilla, et cetera. And one of the desires behind these projects was hey, C++ and C are really fast. They can do a lot of performance-oriented things that JavaScript isn't well suited for. And so, after a couple of these attempts, didn't quite go the distance. Then a new effort sprung up to hey, let's create a generic sandbox. Let's create a generic, essentially it's a virtual machine. Connor Hicks: The distinction is not exactly the same. But let's essentially build a sandbox that we can use as a compilation target and take, theoretically, any language, compile it to this target, and then be able to run that in the web browser. And that's how WebAssembly came to be. And because the previous attempts at this were C/C++, that's where it started as well. So being able to use a tool called M Script to run C++ in the web browser using WebAssembly, that became well supported across all of the major web browsers. And so other programming languages started to add WebAssembly as a target. So Rust is the golden child of WebAssembly, because it baked in the functionality so deeply, but other languages have followed suit. You can now run Go and Python and JavaScript and Ruby and a bunch of other languages in WebAssembly as well. Connor Hicks: And because they all can now be compiled into this common target, a, they can all run in the web browser because the browsers support WebAssembly, but now they can also all be run in these external WebAssembly run times, which is what we take advantage of. But the common properties that make WebAssembly useful across all of these different environments are what we call the three tent poles of WebAssembly. And that is: portability, security, and performance. And we can dive into each of those individually if you want. But like the highest level is that WebAssembly allows you to run code in a very secure sandbox that can't affect the machine that it's running on. It's portable. So you don't have to recompile it for M1 Max versus Intel MAX versus Linux and all of that. And then the performance, you can achieve close to if not the same performance as a natively compiled program when running in WebAssembly. And so we get the benefit of the portability and security while not losing a significant amount of performance. And so by combining those three things, you get to a pretty compelling place. Eric Anderson: Got it. And remind me, was this a side project at the time? Were you doing this for work or what was the context and you were solo at the moment. Connor Hicks: Yeah, yeah. When it started, it was just me. I was working at 1Password. So by that time, I was leading a team called Product Discovery, which was essentially their Research and Development arm of 1Password. And like I said, I wanted to flex these distributed computing muscles, that I didn't really need to flex at 1Password because 1Password had actually a very simple system. It's rock solid and very well trusted. But it's not a huge distributed computing problem, which is what I was interested in playing with. So I did start working on this stuff on the weekends and in my spare time and it grew into something that I wanted to open source. Eric Anderson: Got it. And it started out on Docker and then you discovered WebAssembly. Is there a community or how do you learn about the inner workings of WebAssembly when you're in early adopter phase? Connor Hicks: Yes. And the answer to that back in 2018, 2019 is very different than the answer is today. Eric Anderson: Yeah. Connor Hicks: Back then, the main source of inspiration was just a random smattering of blog posts on various people's blogs around the internet. And there was a discord server for the development of the WebAssembly specification itself, which was created for the WebAssembly community group and the WebAssembly working group. Which are the standards bodies that are working on defining how WebAssembly works at its lowest levels. Now, since then, things have evolved pretty drastically. We've had several open source communities grow around WebAssembly. We've had Wasm Builders, which is a community site that launched earlier this year. It's based on Forum, which is the platform behind dev.to. And so we've got a similar community there, writing articles, showcasing what they're building, and creating tutorials and learning material for others. Connor Hicks: So it is quite a bit more approachable now than it was a couple of years ago. But yeah, it's really been quite fantastic to see how things have grown; not just from the technology perspective, because it has improved pretty drastically over the last few years, but also from the community and the amount of interest that we're seeing. And just, even if you just take a vanity metric like, how many people are tweeting about this? It has just skyrocketed in the past couple of years. So it's really great to see. Eric Anderson: I keep hearing about in context that I don't expect to hear. You mentioned it all started in the browser and now you're looking at distributed systems. I run into people doing data and analytics, sequel queries that they want to embed in some kind of function in a different language into query and they reach for Wasm. And so I keep, as you point out, finding it in new places. Connor Hicks: Yeah. There are some very interesting niches that I also didn't expect, like IOT. I didn't really think of WebAssembly in the IOT perspective until fairly recently. And then you look at things like data modeling, rendering, and all kinds of different high throughput use cases. One of the big benefits is that you can compile SQLite to WebAssembly, and that is a very, very common tool that the data community uses. And so you can get the powers of SQLite running in places that you probably couldn't have before. And you can also get Python running in places that it couldn't run before, like the web browser. So it sends of a huge amount of the data, and analytics communities use those kinds of tooling. It just opened up new avenues for them. And then you look at other spaces like Edge computing and even just Cloud computing as a whole, there have been a bunch of new places where it's popped up that we didn't always expect, but it has become quite multi-talented, I guess, you could say. Eric Anderson: Yeah. I keep wanting to get to more about your launch and the specifics on the product you've developed, but maybe if we keep noodling on this for just a minute on WebAssembly. Eventually you realized that this could be used to make Edge functions, if you want to call them that. Fast booting, Docker-like things. There are other efforts around trying to boot up VMs fast, Firecracker comes to mind. Are these related to WebAssembly? Are they alternatives? Connor Hicks: Totally. So we like to think of WebAssembly modules and containers as similar or competing. But that's not strictly true. People have asked me time and time again, is WebAssembly going to kill Docker or kill Containers? And I always say, "No," because I think there is a place for both. The way that I like to rationalize this or the metaphor that I like to use is a container is like an entire operating system, whereas a WebAssembly module is a single program. They are both needed and both useful, but they serve different purposes. And so when you look at Containers, it's trying to be an entire environment in which you can run software, right? So it's trying to play the part of the operating system. It's trying to include all of the packages and all of the shared libraries, all of the things that you would need to run your software in a single bundle image. Connor Hicks: And then you run your software within the container. Whereas the WebAssembly module, that is the software that you are running. So you can run it inside a container. There's nothing stopping ... and we do it all the time. It's one of the main ways that people use our open source software is by deploying it inside of a container. Because Kubernetes is so prevalent, right? It's one of the easiest ways to get people using anything is by saying yeah, you can deploy it on Kubernetes. No problem. So WebAssembly inside a container is not a ridiculous thing. Connor Hicks: And then you look at something like Firecracker, micro VMs, and I think they are an iteration on Containers. They are not something that compete with WebAssembly modules and they can also be used together. So we can also run WebAssembly modules inside of a Firecracker VM. I do think that micro VMs are actually very good iteration on Containers. And if you ask me, would micro VMs supplant containers one day? I might say yes. But will WebAssembly modules supplant them? No, I don't think so. Eric Anderson: Yeah. Got it. So you've now switched over to Wasm going back in time a bit, and your newly launched project, you're leaning on the forums. At some point, you think you're onto something and how does the project mature? You open source it at some point? When do others get involved? Tell us more about that. Connor Hicks: Yeah, absolutely. So I did open source the first project, which was a Go library for running WebAssembly functions. That was the first thing that got open sourced. It's a project called Reactor and it's still alive and well today. It's the underlying engine for all of our software. And when I published the first open source version of that, I wrote a blog post about what it took to get things working. I complained a little bit about the developer experience of building WebAssembly modules and blah, blah, blah. And that got a little bit of traction on Twitter and Reddit and a few other places, nothing major. Not a big deal. But it was enough that it gave me the juice to keep going. And so I wanted to tackle that developer experience problem a little bit. So I started working on a Command line tool to help me smooth out a lot of the bumps. Because at the time, you had to string together a bunch of different tools to get something building to WebAssembly in a relatively sane way. Connor Hicks: And that also includes a bunch of arcane compiler flags and just nonsense that nobody's ever going to remember, myself included. And so I built a Command line tool, which today is called Subo. And we like to think of it as a meta tool chain. So it is meant to take any of the languages we support and build them into WebAssembly without you needing to understand or care about the specifics of the different languages, tool chains and command-line tools and blah, blah, blah. And so the target I had for myself in my head with that was I want to go from nothing to a built WebAssembly module in under a minute for a new developer. And that involved being able to template new projects, being able to run tool chains in Docker containers. It involved bringing everything down into one command, which is Subo build. Connor Hicks: And it took quite a while for that to play out. Because there was a whole bunch of different components that I needed to build there. But once that did start working, once I could basically say Subo create and then Subo build and it was just working, that was pretty cool. Right? So I wrote more blog posts. I published the CLI on GitHub and that just drove more people to be interested. Partially because hey, it's not an annoying process to get started anymore. Just lowering the barrier of entry is a huge win for any community, any open source project. And then once that was possible, then I moved on to working on Atmo. Eric Anderson: You're still at 1Password and still solo. Is that right? Connor Hicks: Yep. Yep. That's right. If I remember correctly, we're into 2019 now. And once I had this command-line tool list developer experience, that was pretty nice to use. I thought to myself, okay, I'm a backend developer. I like to build web services. What would it look like to build a pure WebAssembly web service that didn't involve any library code? Because the thing I had released thus far, it was a library. It was something you could use to build services. But I wanted to say, what if we could just remove all the boiler plate, remove the wrapper, and just have a pure WebAssembly web service? And so that's where the Atmo project started. And it started out as a weekend thing. I hacked it together using Reactor, which is the lowest level scheduler. And then when you combine that with the CLI tool, I was able to create, build and run a web service with only WebAssembly, nothing else. Connor Hicks: And that got me really, really excited. And that's when I started publishing more blog posts. I put out alpha and then eventually beta releases of Atmo. That's when external folks started getting interested, started wanting to contribute. And that's when folks started reaching out to me as being like, hey, I see that you're doing cool stuff with WebAssembly. I want to learn about WebAssembly. And this kind of loop started where people would discover it. They would find suborbital just because I was blogging about it a lot. And then it started growing from there. Eric Anderson: Yeah. And this is probably a silly question, but we've always been able to use any language we want on the back end using containers, what have you. And so the advantage to what you're doing here is that I don't need, like you said, all the distributor system stuff. And now Reactor, you mentioned, is a scheduler and that's triggering in my head something like Kubernetes. Is that analogous or am I in the wrong place? Connor Hicks: Kubernetes is at a very small scale. Eric Anderson: Okay. Connor Hicks: So instead of scheduling many containers on many machines, it's just scheduling many web assembly modules onto a single machine. But once Atmo came into play, the obvious question is next, how do you scale up? Right? And so we started adding meshed networking. We started adding auto scaling integrations with Kubernetes and stuff like that. And so eventually what we got to was this system that you could deploy it onto Kubernetes and you could have a mixture of a bunch of different languages in the same project. You wouldn't have to worry about the communication between them because Atmo itself would handle that. You wouldn't have to worry about scaling because the integration with the autoscaler would handle that for you. And you could configure the security profile of the deployment down to a very, very granular level, thanks to the WebAssembly sandboxing. Connor Hicks: That's where things started to click. Once we had all these major pieces in place, people started understanding what the heck we were doing. And I think the fire really started roaring when we said, hey, you can do Java script now. Right? It took us a while. But a couple of months ago, we released the ability to run JavaScript inside of WebAssembly, which was a pretty different beast than all of the other languages that we supported. But once we were able to do that, folks were like, oh man, I'm already writing JavaScript for my front end application. If I can do the same thing on the back end and get a lot of the benefits of WebAssembly, but also be able to pull in Rust or be able to pull in Go when I need to, that's where it's a really promising idea. Eric Anderson: So earlier, you talked about how there wasn't much of a community or there was just this Wasm official one. And then you had discovered other communities along the way. And now as you're building these tools, you're garnering a bit of a following as people are discovering these things you're working on. At what point does this become a Suborbital community and how does that take shape and any stories about the original folks that you come across? Connor Hicks: Yeah. We have our own discord, but we try our best to funnel a lot of effort into the Wasm Builders community. Because one of our big ideas is that we won't succeed unless WebAssembly as a whole becomes accepted and becomes well understood within the industry at large. And so rather than focusing a lot of our efforts on building a suborbital community, which, don't get me wrong, we have one, we have a discord server. People come in and we chat with them and they ask questions, we help them out, all that kind of stuff. It's great. But we put more effort into the Wasm Builders community, which is just: wasm.builders. You can go and it's fully open and you can browse around. We put more effort into that because it is more about educating folks about what WebAssembly can do, why it's exciting. Connor Hicks: And then all of the different open source projects out there, they also do showcases. They show off what their open source projects can do. They do demos and they do tutorials and stuff like that. So it's like a bunch of the different open source projects and a bunch of the different startups in the space are all kind of pooling our resources into this one community. And that's just been a lot more successful. I think people have almost a little bit of community burnout because ... I'm part of 25 discord channel servers. I can't keep up with that. Right? So by having a single place where we can go and show everything off has been really effective. And it doesn't remove our ability to show off our projects because we can still do that. But it's in a place where people are already engaged. They're already interested in the technology. And so yeah, let's show them what is unique about Suborbital's projects. But everybody else can also do that, as well, and we all pull our efforts into one place. Eric Anderson: This is something I advise our portfolio companies to do. You can go start your own community, but you can also just go find your complimentary communities that exist already today. They're excited to get new content and you got latent demand for your tech there. So I think that's great. When does Suborbital become a company? I imagine it's more than you now. Connor Hicks: So around the end of 2020, by this point, the open source projects were in beta. I'd been blogging about them pretty consistently. We had external contributors and things were starting to pick up. This is when the thoughts of, could this be a business, could this be a company, started forming. And investors are always on the lookout for interesting new technologies and stuff. So a couple of them started reaching out to me. And after a few weeks and months of thinking about how can I apply the things that I've built with the open source team, how could we apply that to be a product? How could we apply that to be something that is unique and solves a real problem for businesses? I didn't want to just say, hey, this is Heroku for WebAssembly, because it could have gone that route. And I think one day that will absolutely be something that is valuable. Connor Hicks: Right now, creating a Heroku for WebAssembly, I think it a bit premature. Because again, it comes back to WebAssembly as a whole has not become a well accepted or fully mature technology yet. And so asking people to completely rebuild anything on top of WebAssembly, it's absolutely feasible, but most software teams are not going to do that. Right? It hasn't hit that level of, I must rewrite my whole stack in WebAssembly. It's not quite there yet. And so instead, we thought to ourselves, what is the unique thing that WebAssembly can do that nothing else can do? And that is the sandboxing properties. It is the ability to run untrusted code in a safe way. And so the ability to create plugins, the ability to create user defined functions and to create extensibility, that was the thing that I landed on as, here's how we could apply what we've built to solve a real problem. Connor Hicks: And so Suborbital, the company, formed around that idea of, okay, let's build something. We didn't know what it was at the time. But let's build something that allows SaaS applications or SaaS companies, software companies, to run their users code safely as part of the application itself. So one of the easiest examples is Figma. Figma, the design application, they allow you to write plug-ins that run inside of Figma and they use WebAssembly for that. And it is just an extremely easy way for a developer to add and extend Figma as a product. And we wanted to be able to do that for anybody. Right? And so we took that idea and that's what we formed the original pitch around. That's how we were able to raise a seed fund. And that's how the early team formed around that idea. Connor Hicks: And so we started out with a small team of four people. We worked for the majority of 2021 on building out the first version of this extensibility product. We launched it in November of 2021. It's called Suborbital Compute. And the team has grown now to 14 people. We've released several beta versions of that product. And we've got a whole bunch of customers who are onboarding and getting ready to launch their own features based on Suborbital Compute. But yeah, user defined functions, and this idea of building plugins, building extensibility, building developer platforms on top of other software is a very, very exciting use case for WebAssembly that I think still, even to this day, is the only thing in my mind that WebAssembly can do that nothing else can do. WebAssembly can do lots of things that other things can do, but it's the only thing that WebAssembly can do uniquely. And I think it's really well suited for these systems and we've gotten a lot of really good feedback to that effect. Eric Anderson: Super cool, Connor. And I agree with you. This is uncharted waters for folks. And I think we've all dreamed or imagined of something like this. But maybe you could help clarify our vision for what building a plugin would be like. Or may maybe we just go look at Figma as an example. I wasn't aware that they had that. But as an engineer, if I go build a plugin for a SaaS app ... I think we're familiar with using a rest API, but that's the service we have to go deploy and manage on our own. What does a plugin look like? Is there an API of source that we're building against when we build a plugin, you would imagine. Connor Hicks: Yeah, absolutely. So the way we've architected things is we want everything to stay within the product experience. So say you have an application called, I don't know, Donut Task Manager, whatever. Eric Anderson: Yeah. Connor Hicks: And you want to be able to extend it. And the traditional way to do that is with Webhooks. Right? So I, as the user of this tool, I stand up a server, that server receives Webhooks, and I can do custom processing. I can run my own tasks. I can reach out to external APIs, whatever. There's a couple of inherent problems with this model. And it's unfortunately become kind of the standard, but there are some inherent problems. One is that, that web hook, that data needs to travel over the public internet and that's insecure and it's slow, right? There's no real universally accepted security model for Webhooks. Different products will do it different ways. Connor Hicks: You can sign things, you can have secrets, you can do stuff, but there's nothing like OAuth for Webhooks. There's no standard. Eric Anderson: Yeah. Connor Hicks: And it's slow because you have to traverse probably 100 milliseconds or more of network between the application server and your own server. And so as soon as you want to do anything with sensitive data, as soon as you want to do anything with large amounts of data, you are screwed. Because the webhook model just breaks down immediately. So what if, instead of me deploying my own server, I could instead just give a little snippet of code to the product itself, to run on my behalf whenever one of those events would've previously triggered a webhook. And so what we do, what Suborbital Compute achieves is let's stick an editing environment right in the product itself. So we have a code editor that can be embedded directly into the product's dashboard or web UI or whatever. Connor Hicks: And you pop it open and you say, hey, when this event is triggered, I want you to run this code. And this code can be written in Rust, Go, JavaScript, whatever. And when you hit deploy, it's not deploying onto a server you own. It's deploying into the product itself. And it just becomes a part of the product's business logic. So you get the inverse of what the webhook sucks at. You get really good performance because it's running directly inside the application itself. You get really good security because that data's never leaving the private network and you completely lose all of the burden of having to run your own server, maintain it, and all that stuff. So like we talked about earlier, lowering the barrier of entry to making WebAssembly useful, we are now lowering the barrier of entry to make custom logic and extensions and integrations possible. Connor Hicks: And so if you are the product, what did I call it? Donut Task Manager. You no longer need to build bespoke integrations with Slack and Discord and Airtable and all these things. You can have this editing environment where developers can just build their own integrations. They can build their own customizations. And as the user, I can get all of that power with honing to run my own infrastructure. So it's a win-win on both sides. Connor Hicks: And WebAssembly is the thing that makes this possible at the end of the day, because running that logic inside of Donut Task Manager's servers is inherently unsafe because it is untrusted. It is something being submitted to you by a user. And so WebAssembly's sandboxing properties, the fact that nothing can leave the module, no network, no disc, no anything can be accessed from that module unless it is explicitly granted to that module means that we have a very tight control over the logic being executed in that user's module. And so we can give them the ability to run their own custom logic without sacrificing the security of our infrastructure, which yeah, is pretty good. Eric Anderson: No, it's amazing. You're right. You solve this isolation problem of what if it leaks into someone else's process? Not that you need to solve all these things, but I'm trying to imagine, do you consider what abuse scenarios could look? If someone tries to mine Bitcoin in my Donut application plugin, is that a problem? And as the Donut application owner, can I like limit the things that people might be able to run in their plugins? Connor Hicks: Yeah, absolutely. So one of the main features of the compute platform is that you have full control over the execution. So you have, you can limit things like CPU, memory, and amount of time that these functions can run for. And then you can go extremely granular and you can say, hey, you can access the network, but you can only access this one domain. Or you can only access this list of domains. You can access this file, but only Read Only and only at this location. Or you can say, hey, you can access a cash, but you can only access this sliver of the cash that is name spaced to you. And because any request, any external attempt to do anything, passes through the WebAssembly, what we call the foreign function interface, between the WebAssembly module and the host, we can intercept absolutely everything that goes over that boundary. Connor Hicks: We can filter it, we can block it, we can transform it. We can do whatever we want. And so Donut Task Manager, the operators of the system- Eric Anderson: Yeah. Connor Hicks: Can configure down to an extremely granular level what those modules are allowed to do. And so, hey, you want to mine Bitcoin? That sucks. You can't even access the network that would be needed to reach the Bitcoin network. You can't execute for more than one second at a time. There are a bunch of different protections that you can put in place. And we've thought pretty deeply about this, so we have a capabilities system that actually, to a very low level, configures that run time to be secure and only allow the actions that the operator wants to allow. Eric Anderson: That's awesome. What's the state of the product today? I can imagine folks listening to this and getting excited about trying it out. You mentioned Reactor, Subo, Atmo being open source? Connor Hicks: Yep. Suborbital Compute, the product, it is in open beta, has been since November. We actually just released the third major revision of Suborbital Compute recently. And it is something that you can deploy into your own Kubernetes cluster with one very easy deployment command. And we have APIs that let you integrate it into your product and the code editor that you can embed and all this kind of stuff. The compute product itself is closed source, but it runs on top of Atmo. So the actual execution engine, the thing that is running the WebAssembly functions, it is Atmo completely unchanged. It is the open source version of Atmo. That's what we call the data plane. The control plane, which is, it does all the boring stuff. It does the authentication and the storage and just all the stuff that just need to operate a product like this. Connor Hicks: Those parts are not open source because there's no real reason for them to be. But all of the fun stuff, which is executing WebAssembly, doing the security controls, doing the capabilities, that's all open source with our Atmo project. And so if you want to try it out, just go to our website, which I'm sure will be linked somewhere, to give that a try. And if you want to give the open source projects a try, if you want to try building applications from scratch with WebAssembly, or you want to integrate WebAssembly logic into your existing applications, then all of the open source repos at github.com/suborbital are there and waiting for you. Eric Anderson: Fantastic. Connor, anything you wanted to cover that we didn't today? Connor Hicks: One of the just general trends that I think is really interesting that intersects deeply with WebAssembly is Edge computing. So we haven't really touched on it yet because it's not directly applicable to our product yet. But the idea that WebAssembly can be used to significantly improve Edge computing, I think is a really important topic that I want people to just have in the back of their heads. So we have a relatively new open source project called Sat, which is short for satellite. It is a, we like to call it a teeny tiny WebAssembly function server. So it is designed to run WebAssembly in these small resource constrained environments. Whereas, Atmo is meant to run in central Cloud. It's meant to run in Kubernetes, these big powerful clusters. Sat, on the other hand, is meant to run on teeny tiny devices. Connor Hicks: It can run on a raspberry pie, it can run on a micro controller. It can run on the tiny little server rack at the base of a cell phone tower. And so I think it's going to be pretty impactful over the next couple of years. The fact that you can run this code so efficiently on these resource constrained devices. And I think it will really impact the Edge computing trend that we're seeing because you actually don't need containers. Right? I know I said that they can work together, but they don't need to. Because WebAssembly is already sandboxed and it's already safe by its own merits, you can cut out that middle layer. And so, something we'll be launching later this year when we release the hosted version of Suborbital Compute, it will be essentially running WebAssembly directly on bare metal in a globally distributed way. Connor Hicks: And because we don't have the overhead of Kubernetes containers and all of the extra stuff in the middle, we can actually pack a lot more stuff into the available hardware. And so at the end of the day, we and then, to an extent, the other folks who use this technology, they'll be able to pay less for their compute. They'll be able to use less power. They'll be able to use smaller machines and still get the same performance out of the resources available to them. And this is a consequence of WebAssembly just being an inherently more secure, but still as performant way of running code as a container is today. And I think that's going to be a really big time saver and just general architecture improvement that we haven't seen the benefits of yet, but we definitely will over the next couple years. Eric Anderson: So revisit the Edge for me. Because the edge is a broad term that could mean a small data center closer to me. It could be the device in my hand. It could be some gateway in between or a cell tower. Are all these potential Sat deployment spots? Connor Hicks: Yep. They are. So we're focusing our efforts right now on what we call Edge Cloud. Right? So I like to think of Edge. You have Edge devices, which are things plugged into your wall, the raspberry pie in my closet, the things that are closer to the person. And then you hit the Edge Cloud, which is something like what CloudFlare or Fastly does, where they have points of presence all around the world that try to be as close to you as possible. But it is still the Cloud. Eric Anderson: Right. Connor Hicks: We're not over into user land, so to speak, yet. Eric Anderson: Right. Connor Hicks: So we're focused on the Edge Cloud side of things. But yes, we do eventually want to extend all the way out into Edge devices and be able to run on, maybe you have, I don't know, a moisture sensor plugged into the basement of some factory or you have the computer of a tractor. There are, obviously, all these kinds of connected devices that we could eventually get into, as well. And we will, one day. But for now, we're focused on the Edge of the Cloud. Eric Anderson: And Suborbital Cloud using Sat at the Edge would, look like an abstracted Cloud platform that you could offer folks where I bring my Wasm module and you execute it for me. Connor Hicks: Yeah. So we're going to be doing that in the context of Suborbital Compute. We want to make it really easy for folks to run these plugins as close to their data centers as possible without needing to run it themselves. That's going to be our initial goal. But the building blocks that we have created to be able to do that, yes, they could be more widely applicable and we'll see what happens. Eric Anderson: Awesome. Connor, thanks for coming today. Super exciting stuff. And it takes Wasm to a lot of places. Turns the idea of how we've been running distributed compute on its head for a while. Connor Hicks: Yeah. There's definitely some possible paradigm shifts that will be possible because of WebAssembly. Eric Anderson: Thanks Connor. Connor Hicks: Yeah, my pleasure. Eric Anderson: You can subscribe to the podcast and check out our community slack and newsletter at: contributor.fyi. If you like the show, please leave a rating and review on Apple podcast, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson, and this has been Contributor.