Episode 11: WebAssembly All The Things with Connor Hicks
Committing to Cloud Native
English - May 27, 2021 04:00 - 44 minutes - 61.4 MB - ★★★★★ - 3 ratingsTechnology cloud native microservices devops security cloud computing cloud gitops Homepage Download Apple Podcasts Google Podcasts Overcast Castro Pocket Casts RSS feed
Sponsored by Reblaze, creators of Curiefense
Panelists
Justin Dorfman | Tzury Bar Yochay
Guest
Connor Hicks
Show Notes
Hello and welcome to Committing to Cloud Native Podcast! It’s the podcast by Reblaze where we talk about open source maintainers, contributors, sustainers, and their experiences in the Cloud Native space. Today as our guest, we have Connor Hicks, Maintainer of Suborbital and Staff Software Developer, Product Discovery Lead at 1Password. We will learn all about Suborbital and how it’s going to make Cloud Native better, and the three projects that he refers to as the building blocks. We also find out more about 1Password, how they are using 1Password with Cloud Native with their projects, and their most recent launch of 1Password Secrets Automation. Connor talks about his partnership with HashiCorp, and we hear his thoughts on the complexity in the Cloud Native world. Go ahead and download this episode now because there is so much more we talk about with Connor!
[00:01:41 (https://podcast.curiefense.io/11?t=101)] Connor explains what Suborbital is and how it’s going to make Cloud Native better.
[00:03:04 (https://podcast.curiefense.io/11?t=184)] Microsoft, Google, Intel, and Mozilla want to move WebAssembly beyond the browser, and Conner explains what this means.
[00:05:00 (https://podcast.curiefense.io/11?t=300)] Connor tells us a little bit about himself and how he got into computers and software, and why he decided iOS development was not for him.
[00:09:46 (https://podcast.curiefense.io/11?t=586)] We find out more about how many front-end applications there are today using WebAssembly, and he mentions Figma and Internet Archive.
[00:10:33 (https://podcast.curiefense.io/11?t=633)] Connor explains two ways you can take advantage of Suborbitals projects. He explains the three projects that he refers as the building blocks: Graph, Reactr, and Vectr, which together form Atmo.
[00:14:28 (https://podcast.curiefense.io/11?t=868)] Justin wonders since Connor is not looking for sponsors, donations, or patrons, how is he sustaining this and what’s the plan. Also, Justin wonders if he’s considered submitting any of his projects to the CNCF.
[00:15:25 (https://podcast.curiefense.io/11?t=925)] Tzury asks Connor if he’s doing all this work by himself or if he’s collaborating with others, and Justin asks how he’s managing his community. Connor talks about their recent launch of 1Password Secrets Automation, and how they’re now also offering Cloud Native software to their customers to run, which are the 1Password Connect Server, 1Password SCIM bridge, and 1Password command-line tool.
[00:19:35 (https://podcast.curiefense.io/11?t=1175)] Connor tells us about his partnership with HashiCorp.
[00:20:23 (https://podcast.curiefense.io/11?t=1223)] We find out how Connor feels about the complexity in the Cloud Native world.
[00:25:05 (https://podcast.curiefense.io/11?t=1505)] Tzury asks Connor if Atmo is used to replace obligation from development or if it used to empower existing ones, and if it’s extendable and pluggable. Connor also tells us about using programming languages that they support such as Rust, Go, Swift, and AssemblyScript. Connor mentions using Unicorn Platform in helping him design his website.
[00:29:05 (https://podcast.curiefense.io/11?t=1745)] Find out why Connor recommends not using Atmo for production use yet.
[00:30:14 (https://podcast.curiefense.io/11?t=1814)] We learn what the available server-side technologies are to plugin and to integrate with WebAssembly modules or WebAssembly code.
[00:34:09 (https://podcast.curiefense.io/11?t=2049)] Connor tells us where the 1Password name came from and where he came up with the name Suborbital and Atmo.
[00:40:28 (https://podcast.curiefense.io/11?t=2428)] Connor tells us how he would like Atmo to replace Lambda in some ways. He tells us he would love to get feedback on the Suborbital projects so you can join the Suborbital discord, file issues in the GitHub repos, or join the GitHub discussions in their Meta Repo and reach out to Connor.
Quotes
[00:01:51 (https://podcast.curiefense.io/11?t=111)] “It’s a family of open source projects and each of them individually may not stream WebAssembly, but that is actually the main theme, enabling WebAssembly specifically on the server side.”
[00:10:53 (https://podcast.curiefense.io/11?t=653)] “And that’s because the projects are organized to be a set of building blocks and then a platform built on those building blocks. So, the three projects that I refer to as the building blocks are Grav, Reactr, and Vectr.”
[00:14:43 (https://podcast.curiefense.io/11?t=883)] “It’s something that I just love doing.”
[00:15:14 (https://podcast.curiefense.io/11?t=914)] “Once WebAssembly as a whole kind of builds up a bit more steam and once the user base grows a little bit, it’s definitely something that I want to think about doing.”
[00:17:22 (https://podcast.curiefense.io/11?t=1042)] ”Yeah, there’s a little bit of use of some of the Suborbital building blocks.”
[00:17:52 (https://podcast.curiefense.io/11?t=1072)] “And so, we’ve built up quite a lot of experience running Cloud Native at 1Password.”
[00:18:37 (https://podcast.curiefense.io/11?t=1117)] “There’s been a bunch of lessons learned, because not only are we running Cloud Native software to power 1Password, but we’re now also offering Cloud Native software to our customers to run.”
[00:19:41 (https://podcast.curiefense.io/11?t=1181)] “So what you can do now is you can actually, there’s a plugin for HashiCorp vaults with 1Password Secrets Automation so you can actually make your 1Password data available through HashiCorp vault using their backend system.”
[00:20:33 (https://podcast.curiefense.io/11?t=1233)] “So, I definitely have thoughts here and that’s one of the main drivers when I’m building Suborbital.”
[00:22:36 (https://podcast.curiefense.io/11?t=1356)] “But you can imagine where a system that can intelligently decide where to run the different pieces of compute that comprise your application, and that’s something that I’ve been calling decomposed computing.”
[00:23:54 (https://podcast.curiefense.io/11?t=1434)] “Absorbing complexity where it makes sense is always the right call.”
[00:26:08 (https://podcast.curiefense.io/11?t=1568)] “And I won’t go off on too much of a tangent, but I do believe “Go” is the best thing to be using for Cloud Native right now.”
[00:42:40 (https://podcast.curiefense.io/11?t=2560)] “And if there’s one kind of idea that I could leave off with is that I’m hoping a couple of years from now, WebAssembly will just be an implementation detail. I don’t want WebAssembly to be the headline feature on my website in three years, I want it to be a footnote.”
Links
Curiefense (https://www.curiefense.io/)
Curiefense Twitter (https://twitter.com/curiefense?lang=en)
Cloud Native Community Groups-Curifense (https://community.cncf.io/curiefense/)
[email protected] (mailto:[email protected])
Reblaze (https://www.reblaze.com/)
Justin Dorfman Twitter (https://twitter.com/jdorfman?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor)
Richard Littauer Twitter (https://twitter.com/richlitt?lang=en)
Tzury Bar Yochay Twitter (https://twitter.com/tzury?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor)
Connor Hicks Twitter (https://twitter.com/cohix)
Connor Hicks Linkedin (https://www.linkedin.com/in/connor-hicks-05044166/)
Suborbital (https://suborbital.dev/)
WebAssembly (https://webassembly.org/)
1Password (https://1password.com/)
1Password Secrets Automation (https://1password.com/secrets/)
1Password SCIM bridge (https://blog.1password.com/scim-bridge-release/)
1Password command-line tool (https://1password.com/downloads/command-line/)
HashiCorp (https://www.hashicorp.com/)
Go (https://golang.org/)
“Microsoft, Google, Intel and Mozilla want to move WebAssembly beyond the browser”-ZDNet (https://www.zdnet.com/article/microsoft-google-back-bytecode-alliance-to-move-webassembly-beyond-the-browser/)
Unicorn Platform (https://unicornplatform.com/)
WebAssembly Summit 2021 (https://webassembly-summit.org/)
WebAssembly Live! (https://www.webassembly.live/)
Cloud Native Wasm Day 2021 (https://cloudnativewasmeu21.sched.com/)
KubeCon/CloudNativeCon 2021 (https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)
Suborbital Meta-GitHub (https://github.com/suborbital/meta)
Suborbital Discord (https://discord.com/invite/dyTQJhwqgW)
Suborbital-GitHub (https://github.com/suborbital)
Credits
Executive Produced by Tzury Bar Yochay (https://twitter.com/tzury)
Produced by Justin Dorfman (https://www.justindorfman.com/)
Edited by Paul M. Bahr at Peachtree Sound (https://www.peachtreesound.com/)
Show notes by DeAnn Bahr at Peachtree Sound (https://www.peachtreesound.com/)
Transcript by Layten Pryce (https://www.fiverr.com/misstranscript)
Transcript
Connor: 00:02 The number of layers that you need to be thinking about constantly is crazy. Orchestration, networking. Do I add a service mesh? How do I run my database? What are the differences between the cloud providers, Kubernetes distributions. What's this K3S thing thing over here. There's just so much to think about. It used to be so simple. You would throw up a VM, you would auto scale it and you would run your monolith. I don't think we should go back to that by any means, but I think there's a new generation on the horizon that gives us some of the best of both.
Announcer: 00:39 Hello and welcome to Committing to Cloud Native, the podcast where we talk about the interface between open source and cloud native. We're super excited about our guest today. Can't wait to introduce him. Our panelists today are Justin Dorfman and Tzury [inaudible 00:54] and they're going to have an awesome conversation. I really enjoyed listening to it and I really hope you enjoy this conversation.
Justin: 01:03 Hey Connor, how are you?
Connor: 01:04 Hey, doing well. How are you?
Justin: 01:06 Great, good to see you in the flesh. Sometimes it's weird because when you meet someone on Twitter, it's like you got the static image and now like you're alive, full color and everything. Yeah. I saw you host something. This thing called suborbital. Before we go into that, I want Tzury to say hello. Tzury, say what's up.
Tzury: 01:29 Hey Connor, how are you?
Connor: 01:30 Doing great. How are you?
Tzury: 01:32 Thank you for coming on the podcast.
Connor: 01:34 Yeah. It's my pleasure.
Justin: 01:36 I got questions for days, but we only have 40 minutes. Let's get started. What is, suborbital tell the folks listening to this, what it is, why we need it, how it is going to make cloud native better.
Connor: 01:52 It's a family of open-source projects and each of them individually may not scream Web Assembly but that is actually the main theme, is enabling WebAssembly specifically on the server side. It's split up into a couple of different modules. There's vector graph, reactor, Atmo. These are all different projects that when you put them together, they allow you to do some interesting things, when building server side technology.
Justin: 02:25 Got it. Ever since I went into the cloud native space, all I hear about is WebAssembly. I think what's interesting actually, ZD net did a story about it, the byte code alliance. Are you part of the byte code alliance? There is this project part of it?
Connor: 02:44 I meet with them regularly, but I am not personally a member just yet. I think they actually just opened up for new members like this week. I've been looking into doing that, but most of the members are companies and suborbital is not a company, it's an open-source project. I've been talking with them quite a lot though. I really love what they're doing.
Justin: 03:04 Microsoft, Google, Intel, Mozilla. They want to move WebAssembly beyond the browser. What does that mean?
Connor: 03:11 It was originally kind of designed as a technology to enable compiled languages other than JavaScript to be used in the web browser. That was honestly still what most people associated with. But in fact, WebAssembly is not specific to the web browser in any way. It was just the first thing that it was adopted in. WebAssembly at its core is a way of representing byte code, compiled code and where you run that, it's up to you. I mean, you can absolutely embed it in the browser and you can run it to power web applications, but there's a ton of other use cases for it.
The ones that I work with are made for developing cloud native services software, but there's others such as IOT devices, embedded applications, there's non cloud native, non-browser things like desktop applications. It's really whatever you can think of. There's probably some way of incorporating WebAssembly into it.
Tzury: 04:13 We could spend a day talking about WebAssembly, it's greatness. I hope we're going to do a lot with Web Assembling this conversation. I mean, just mentioning the facts, talking about just shortly type language, you can buy into any runtime application without recompiling takes a week, consider nearly impossible or really hard to get done in previous to study compiled languages.
We can talk about V8 role in these revolutionary in JavaScript [inaudible 04:43] and WebAssembly falling after that. I would love if you can Connor to take us through the history and the evolution and the revolution of these technology in the recent, I would say, what 10 years is it around, a decade around us, more or less. But before we get to Connor, I'd like myself and our audience to know you a little better. If you can step back a little bit, tell us about your history. How did you get into computers, software, etc?
Connor: 05:15 Yeah, for sure. I did a computer science degree in university and I don't think that's so uncommon, but definitely not by any means needed anymore. That's just the way that I went. During school I did a couple of internships. I worked for Airbus in their defense and space division. I worked for WordPress in their VIP division. Then my last year of school, I got an internship at 1password. I was actually in the iOS team that was building their iOS app.
After I graduated, I decided that iOS development wasn't for me. I wanted to try something else. Just so happened that there was a prototype sitting in a get repo somewhere of a command line tool for 1password. I asked if I could pick that up and work with that. They thankfully said I could. That kind of took my transition out of the mobile development space and into more of the automation and tooling space. Then from there, I started working more on the systems and back-end side of things. I built a team around integrations and now I lead a team called product discovery there, which is all about research and development and trying out new ideas.
Then for the last year and a half or two years or so, I've been working on this idea of suborbital and it started out as a functions as a service system for Docker. It was nice, but there was nothing truly special about it. There was nothing that Kubernetes, Docker, OpenFAST couldn't already do. That's when I kind of took a pause and ask myself, what could I build in the space? Because it was a very interesting space to me, distributed computing, job processing, all that kind of stuff. I love thinking about those problems. I was like, what can I build that would be unique and differentiate itself from everything else out there.
That's where WebAssembly kind of came onto the scene. I will say, like I actually built server side WebAssembly before I ever even built WebAssembly that runs in the browser, which I think is strange, but I never even bothered running WebAssembly in the browser. I just went right to the service. That's how my brain works these days. I think in terms of distributed systems.
Tzury: 07:31 Well, don't get me wrong. I mean, the world will benefit more from you doing cloud native than mobile native apps. But as you mentioned that you decided iOS development is not for you, I wonder, what was it in iOS development, I mean, I never experienced, I never even tried developing iOS application. I did so many all sorts of development platforms, but never did this one. What was in the process in the technology, in the tooling or that move you away from it?
Connor: 08:08 It's none of those things actually believe it or not. I think Apple has some of the best software design and tooling available. I mean, X code has a little bit to be desired. At least it did when I was using it. I've heard it's gotten a little better since I last touched it, but it's none of those things that made me want to switch. It was actually the fact that I just had no desire to build user interfaces. That was the thing that wasn't working well for me. It just became, something that I lost interest in. Even to this day, like building web applications, like front end development, web application, it still doesn't really vibe with me. It's not something that I enjoy doing. It's very cool and it takes a lot of skill and it's something I respect highly, but it's definitely not my cup of tea.
Tzury: 08:55 So you would rather developers will use your API application programming interface rather than users using your interface.
Connor: 09:09 Yeah. I love having developers as my users and my customers.
Tzury: 09:13 That's interesting the transition that language that was mainly design and mainly targeting browser makes its way eventually to the server side. I would say even more far more popular, more common than actually in the browser. I'm sure there's applications that we know is an end user to actually make use of WebAssembly. But every existing server platform. Every LLVM language will have it's WebAssembly. Is that the case?
Connor: 09:47 You'll actually be surprised at how many front-end applications there are out there today using WebAssembly. It's definitely not totally saturated yet. There hasn't been a massive wave of people using it, but it's more than I think you would expect. Some recent ones that have come up is for example, Figma the very popular design application. They use that to help rendering. One of my favorites as the internet archive, using it to emulate flash, to be able to preserve old flash.
A bunch of gaming applications as well that have come up in the last little while. But it's one of those things that you have no idea that you're interfacing with it, right? When it's running in the web browser, you have no idea that it's being used. But it's more popular than you might think.
Tzury: 10:34 Where is the suborbital come into play when it comes to cloud native and service side that should protect applications in WebAssembly?
Connor: 10:43 There's two different ways that you can take advantage of suborbitals projects. There's what I call it, the do it yourself way or there's what I call the batteries included way. That's because the projects are organized to be a set of building blocks and then a platform built on those building blocks. The three projects that I refer to as the building blocks are graph, reactor and vector.
Graph is what I call a distributed messaging mesh. It's actually an obstruction over messaging protocols and discovery protocols that allow you to really easily write asynchronous code for communicating on the network. Then vector is an HTTP framework for go, not exactly consequential to WebAssembly, but it integrates really well with the rest of the suborbital ecosystem. It's one of my like passion projects. It's not for everyone. It's very opinionated, but I think it's great.
Then there's reactor, which is the core WebAssembly runtime. It's a function scheduler or a job scheduler that allows you to run either Go or WebAssembly workloads, either one they're completely interchangeable. It provides the execution environment for WebAssembly, powered by the Wasm runtime under the hood. It allows you to run many WebAssembly modules all at once. It manages their memory. it manages inputs and outputs, and it provides APIs to the WebAssembly sandbox, that developers can use to actually gain the capabilities that they need to write applications for the server. That's called the runnable API.
It's something that I've been working on quite a lot lately. It's something you have to do, to interact with that sandbox. Because WebAssembly is denied by default and it means that nothing can access the outside world unless you explicitly granted the permission to do so. Reactor manages all of that on behalf of the developer so you don't actually need to think about it. Then when you put those three together, those three building blocks together, they form Atmo and Atmo is the batteries included version if you will.
It means that you don't actually need to set up a web server or TLS or any of the boilerplate that you would normally need to write when you're building a web service, you interact with it, using what I call the directive, which is a declarative format for defining your web services. It lets you define the end points and the routes and all of the steps that you want the application to follow, to handle those endpoints. You do so by composing together functions that are compiled to WebAssembly.
A project for Atmo is a collection of functions written in various languages. We support Rust and Swift and TypeScript slash assembly script is coming very soon. It'll build all of your functions to WebAssembly modules. It'll package them all up together with your directive and with a set of static files. Then Atmo will take that bundle and execute the application as you've described it in the directive without you needing to write any boilerplate code whatsoever. There's a couple of different ways that you can approach it. I think it's a nice mixture of control. If you want to go the do it yourself route and have sole maximum control or simplicity and go with the Atm route batteries included.
Justin: 14:16 All this is open source?
Connor: 14:19 That's right.
Justin: 14:22 I saw on your website, you're currently not looking for sponsor, by the way, your websites are beautiful. They're so polished. Love them. But if you're not looking for sponsors donations or patrons, how are you sustaining this? Like what is going on? What's the plan here?
Connor: 14:39 I work for 1password. That's my job. I work on suborbital and evenings and weekends. It's my own time. It's something that I just love doing. That's something that I enjoy. I've been working on for almost years now. While it might seem that there's a lot there, it's been building up over a long period of time. It's just really enjoyable for me. I love interacting with other developers through open source. It's just fascinating problems that I like to solve.
Justin: 15:06 Have you considered submitting any of your projects to the CNCF?
Connor: 15:13 Yeah, it's definitely something I've considered once WebAssembly as a whole kind of builds up a bit more steam, and the user base grows a little bit. It's definitely something that I want to think about doing.
Tzury:15:25 Are you doing all this work by yourself on your own? Are you collaborating with others? This sounds like a lot to achieve on a spare time?
Connor: 15:35 Yeah. There's definitely some open source contributors that have come in and helped out. Especially on the tooling side with the suborbital, SCLI called Subo, and with a graph project and the reactor project as well. I definitely have spent a lot of time on it myself. Contributors started coming on board maybe six months ago as the popularity of the project started to grow a little bit. A good chunk of it is me, but there's definitely they're contributors as well.
Justin: 15:59 How are you managing like your community? Just like have a slack? Basically, Tzury and I started this podcast because we want to learn from other open-source maintainers. If we ask you questions that might seem basic, they kind of are because we're learning.
Connor: 16:16 Community is something that I'm learning. It's somewhat new to me. I've done some community stuff through 1password through a command line tool, but I am putting a bit more of a concerted effort on it for suborbital. We have a discord for example, that you can join if you'd go to chat.suborbital.dev, it'll take you right there. A fair amount of interaction honestly happens in Twitter. It's one of the most active places like I've been tinkering with some community analytics apps like Comscore and Orbit. When you look at the graphs, like, sure, GitHub is number one. But actually Twitter is even more active than Dysport and people love to, retweet things. That often lets you go a little bit viral on a particular day.
Justin: 17:01 And then you're doing podcasts with the people that find you on Twitter.
Connor: 17:04 Yeah. That's like, that's actually pretty much how it's done. I'll have a particular tweet that gets a bit of attention and then somebody will reach out saying, hey, come show off what you're working on this YouTube show or this podcast. I love doing them. There's so much fun.
Justin: 17:16 Here's another question. 1password is your bread and butter. How are they using cloud native? Are they using any of your projects like what's going on?
Connor: 17:27 Yeah, there's a little bit of use of some of the suborbital building blocks. One password actually started out. However, I think it was well over a decade ago now it was just a Mac app and it's now grown to being, we have an app on every platform. Then in 2015, actually, literally the day I joined the company, they launched one password for Teams, which is the cloud product that we now just know as 1password because almost everybody uses the cloud offering now. We've built up quite a lot of experience running cloud native, 1password did the entire service. 1password.com is a Go system that has treated us extraordinarily well. We've been expanding more recently into integrations.
You might've seen two weeks ago, we launched 1password secrets automation, which is an extension and an expansion of what 1password normally does, which is the usernames and passwords and credit cards that you as a person use day to day. We've now expanded that to include infrastructure secrets, Kubernetes plugins, HashiCorp Vault plugin, all sorts of things to manage the secrets that machines and your business needs to run all sorts of different automations around that.
There's definitely been some expansion there and there's been a bunch of lessons learned because not only are we running cloud native software to power 1password, but we're now also offering cloud native software to our customers to run. There's the 1password connect server that actually links 1password into your infrastructure. There's the 1password skim bridge that lets you connect with identity services like Okta, and the one password command line tool, which was kind of the way that I started out there.
There's plenty of different things that have come in the last couple of years. That makes a lot of sense for 1password.
Justin: 19:08 I would have never known that.
Tzury: 19:10 I had no idea and I'm glad to hear about it.
Justin: 19:12 Me too. This is awesome.
Connor: 19:14 It literally launched on April 13th. Just a couple of weeks ago and it was a pretty great launch, got quite a lot of attention.
Tzury: 19:21 We're too focus on our products. We no longer pay attention to what happens.
Justin: 19:28 I'm like way too close to fire. You need to get back and like, see what else is going on. I don't get it. Are you competing with HashiCorp or you're working with HashiCor? What's going on?
Connor: 19:41 No, absolutely not. We actually have a partnership with HashiCorp. What you can do now is you can actually, there's a plugin for HashiCorp Vault with 1password secrets automation. You can actually make your 1password data available through HashiCorp Vault using their back end system.
Justin: 19:57 Now that's a smart idea because they are very ingrained into the cloud native landscape. Hooking up with them, I think that's a brilliant move. We've been doing this podcast for well over two months or so. Half of the people that come on this podcast say cloud native is way too complicated and little less than half that say it's easy. It's the most easiest thing in the world. I know you have some feelings on complexity in the cloud native world. Talk to me and the audience about this.
Connor: 20:35 I definitely have thoughts here. That's one of the main drivers when I'm building suborbital I'm constantly thinking about the complexity needed to get this system up and running in production. It's a double-edged sword like no other where you have a massive amount of customization and options available to you in this space. But then that just flips around and becomes paralysis of like, what do I choose. Will making a certain decision ruin my system five years down the line if I choose wrong. The number of layers that you need to be thinking about constantly is crazy. Orchestration, networking. Do I add a service mesh? How do I run my database?
What are the differences between the cloud providers and Kubernetes distributions? What's this K3s thing over here. There's just so much to think about. It used to be so simple. You would throw up a VM, you would auto scale it and you would run your monolith. I don't think we should go back to that by any means, but I think there's a new generation on the horizon that gives us some of the best of both. That's what I'm trying to do with Atmo. Atmo is designed to give you the best scaling properties of microservices and server list, while still keeping your code base and the architecture of your system simpler.
It's enabled by WebAssembly. That's the great thing because an Atmo application is split up into what could be dozens or even hundreds of tiny WebAssembly modules, that are all working in concert to solve the goals of your application. Atmo can distribute that execution among many instances or even across multiple layers of the network, like Edge, Central Cloud, even devices one day. I haven't quite gotten that far yet, but you can imagine where a system that can intelligently decide where to run the different pieces of compute that comprise your application.
That's something that I've been calling decomposed computing. That's not an official term or anything. That's just what I call it. Where if your application is already naturally broken up into these tiny pieces, you as the operator, as the developer, shouldn't need to care where those individual pieces are running, whether it's on an edge network in your AWS region or on a device somewhere. As long as it is achieving the business goals that you've described for it. My hope and whether it's through Atmo or through something else, my hope is that we can get to this place where "the network" tries to figure out more of this stuff for you.
A lot of the complexity that we see today gets abstracted down a level and the developers and the operators who are dealing with this stuff every day don't need to care so much and they can focus more on what actually brings value to the application.
Justin: 23:37 Basically, what you're saying is absorbing complexity and making it hard to screw up.
Connor: 23:42 That's exactly right. It's something I believe in. I think especially if you're building products and tools and services for developers, and I mean for everybody else, but developers are kind of what I focus on. Absorbing complexity, where it makes sense is always the right call. Give them the knobs and leavers that they need to customize and use the application the way that they need to use it. But do it in such a way that they can't accidentally break something. There should be no foot guns to be had anywhere in your system. There should be no combination of configuration options that causes them to get into a bad state, whether that's with performance or security or scalability, it should be really hard to screw it up so that they can focus on building what they need to make their application work.
Justin: 24:32 That's like the AWS way, if an engineer screws up at AWS, they don't blame the engineer. They blame themselves for that happening. It shouldn't have happened. I totally get that.
Connor: 24:45 Yeah. if you would deploy an Atmo application and something breaks or something behaves in a way that doesn't make sense, that's my fault. That's not your fault.
Justin: 24:53 Exactly. Accountability.
Connor: 24:56 Accountability in cloud native.
Tzury: 24:58 Just for me to better understand Atmo's I would say purpose and positioning, is it to replace existing application from development or is it to empower existing ones? Is it extendable? Is it pluggable?
Connor: 25:16 Yeah, that's a great question. If you use Atmo on its own, it could very easily slot into an existing microservice system, for example, because it's just a web server and it's a web server powered by WebAssembly and a declared a format and all this fancy new fun stuff, but it is a web service. You could slot it into an existing setup if you want it to.
Tzury: 25:40 Just for me to understand. You actually implemented your own web server or is it something that you're writing on? Like existing proxy or the networking?
Connor: 25:50 Yeah. It's based on Go's networking stack and it provides all of the abstractions and all of the boiler plate that you shouldn't need to deal with. It handles all of that for you, but it does use the Go networking stack to power all of that.
Tzury: 26:06 Well, that's quite powerful and stable.
Connor: 26:08 That's right. It won't go off on too much of a tangent, but I do believe Go is the best thing to be using for cloud native right now, of course there's others. Of course, Rust is the fancy thing that everybody loves.
But for building cloud native technology right now is the best choice. But to go back to the question of how it fits in, you can kind of think of Atmo roughly in the same vein of no JS where no JS is running JavaScript on the server and includes some APIs to make use of hardware. It makes use of the networking protocols that you need to use. It lets you run a technology that also just so happens to be traditional using the browser, lets you run it on the server. That's the comparison I like to make.
If you want to use that same WebAssembly runtime and power to extend existing applications, that's where those building blocks come in. If you want to add WebAssembly execution to an existing Go app, for example, you could use reactor. If you want to add these network mission capabilities to one of your existing applications, use graph.
It kind of depends on what your goal is.
Tzury: 27:16 Well, this is fascinating. You're actually saying, if I hear it correctly, say an organization already have code base running Go base platform. Now they can add more capabilities and diversity in terms of languages. They can write say service with Rust, compile it into WebAssembly and get Atmo to play along on top of the Go run time, for example. Is that correct?
Connor: 27:46 Yeah. If you want it to take some Rust code and run it as a standalone web service Atmo is fantastic. But if you want it to actually embed that Rust execution in an existing Go application, then you can use reactive.
Tzury: 27:57 Can I use any language that is compiled to WebAssembly to write an Atmo or any specific frameworks in specific languages are available.
Connor: 28:10 Yeah. That's a slightly tricky question because yes, it will run anything that compiles WebAssembly, but if you want to be able to take advantage of the capabilities provided by the runnable API, you have to use one of the languages that we support currently.
Tzury: 28:22 Which are Rust, Go, Swift
Connor: 28:27 And Assembly Script. Go will come shortly after Assembly Script.
Tzury: 28:30 This is so cool, man. Getting it done on spare time.
Justin: 28:36 It's so clean. Like you've been to the website, I just love design. I love talking about websites and how they look.
Connor: 28:43 Our plug, unicorn platform, it's a site builder that I really like I'll take no credit for actually developing it. I had just put the site together with the tools available from unicorn.
Justin: 28:52 Interesting. Wait, does it bright markdown and how does that work?
Connor: 28:56 It's a static site builder. It's very much a gooey kind of like a web flow or something like that.
Tzury: 29:06 Do you know of users using Atmo in production at scale?
Connor: I'm specifically not recommending Atmo for production use quite yet? Not because of stability problems, but because the API is changing very rapidly still. I can't expect anybody to build their entire big system on Atmo when I'm going to be kind of pulling the rug out from under them every couple of months. I'm hoping that will change fairly soon.
I'm hoping by Atmo beta five or so the, the API will have stabilized to the point where I can start recommending it for production use. We're on beta two right now. Beta three is right around the corner. However, the building blocks, they are quite stable and I would recommend those for production use. I do know of a couple of startups and a couple of companies that are using reactor, for example, to build custom functionality and run WebAssembly.
Nothing for Atmo yet because I've been specifically telling people, try it out, please give me all the feedback that you can. people have built a small hobby applications and some side projects with it. But I'm explicitly saying that it's not quite ready for production use yet.
Tzury: 30:06 Can you tell us a little bit about server side technology for runnning in executive web assemblies? Cause I know like Envoy as WebAssembly support for plugins first, it should be filters. What are the available server side technologies to plug in and to integrate with WebAssembly modules or WebAssembly cover?
Connor: 30:27 Yeah, for sure. There's actually quite an interesting landscape right now. It ranges all the way from like the low-level runtimes. Think Wasm time, which is run by the bytecode Alliance there's Wasmer and there are some other runtimes like whabam and second state SSBM, these are kind of the lowest level execution engines. Then as you build your way up to like the more high level obstructions and that's kind of where Atmo lives at the high level obstruction kind of application layer. Things in the middle include things like the cross lit project from Microsoft, which is actually allowing you to schedule WebAssembly using the Kubernetes API, which is really quite fascinating. Then you've got other frameworks that are kind of in the same vein as Atmo like Wasm cloud and a [inaudible 31:14]
These are other open source projects that are trying to accomplish some of the same goals using WebAssembly. Then if you go kind of even further past that there are some cloud providers and some actually hosted solutions that let you run WebAssembly. That includes Fastly's computer edge platform and the CloudFlare workers platform as well.
Tzury: 31:35 I believe those were actually using VA. Is that correct?
Connor: 31:39 That's right. Fastly platform is using Wasm time and Lucid because Fastly was one of the founding members of the byte code alliance. But CloudFlare workers is indeed using VA and actually most recently the denim project released support for WebAssembly and one of their fairly recent versions on their new cloud product is also going to be having WebAssembly support.
Tzury: 32:02 It's looks like a promising landscape and promising technology is awesome.
Justin: 32:09 The plethora of knowledge you hold around is Wasm is Wasm. It's crazy. It's awesome.
Connor: 32:17 I'll say one thing is that I'm not a compiler developer. I actually don't know a whole lot about compilers and the low level specifications and all of that stuff. I know a lot of people working on those things. I know people at the byte code alliance and who were in the WebAssembly working group, WebAssembly community group. Compilers aren't my thing. I work at a higher level, like a higher level abstraction than that. The work that they are doing in the compiler space to support WebAssembly, especially across multiple languages is quite impressive. I would definitely suggest checking out talks from like the WebAssembly summit, the recent WebAssembly live event and the upcoming cloud native WebAssembly day at KubeCon
Justin: 33:00 Are you attending that?
Connor: 33:01 I am giving a lightning talk at Wasm Day.
Justin: 33:05 That's cool, man. I was going to ask if you were going too. I'm glad it came up because I probably forgot, but in my notes I was going to say, bring up KubeCon and here it is. Are you representing 1password or are you representing your open source?
Connor: 33:24 I am a developer from 1password as part of part of my career, part of my title and all of those things. But the talk is about suborbital so why don't I say both.
Tzury: 33:35 Are they like sponsoring that event?
Connor: 33:38 No 1password isn't sponsoring that event, but they do participate in lots of events. For example, GopherCon is one that 1password sponsors year after year, actually a couple of years ago we were the diamond sponsor. We were like the marquee sponsors at GopherCon a couple of years ago, which was really fun. But yeah, not this particular event.
Tzury: 33:55 By the way, guys, 1password username for the brand of a company. Make sure you will never use the same 1password across all your websites.
Connor: 34:04 That's right. Password management is very important. Yeah.
Tzury: 34:09 I think that's where they got the name for it right?
Connor: 34:12 Yeah.
Tzury: 34:15 Because people use one password for everything they said, no, let us take care of it.
Connor: 34:19 That's right. That's right. The master password is what I think they refer to, 1password the name is you use your master password to unlock the application. Then it stores, generates and manages completely unique and strong passwords for every different website.
Tzury: 34:35 What if you forgot your master password, then you forgot the model of the first car your father had on 1974. What are you gonna do then?
Connor: 34:46 We have something called recovery that allows one of your family members in your family account to recover you if you forget your master password, or if you're part of a business or a team, then the administrators of your business can recover your account. Since everything is N10 encrypted, we actually could not unlock your account, even if we wanted to, because the cryptography happens right on your device.
We never hold the keys for that. Signing up for a family account and getting a couple of members of your family onboard is always a good idea.
Tzury: 35:13 Make sure you keep the relations with your family members.
Justin: 35:17 Don't get in a fight and then like, oh shoot.
Tzury: 35:22 Connor where did you get this cool names suborbital?
Connor: 35:28 I am a big space flight nerd. I love watching rocket launches and I follow all that stuff very closely. That was kind of the inspiration for it. But the main reason why I chose this name in particular is that the GitHub username was available.
Justin: 35:40 That's all that matters at the end of the day. Is the domain available? Can you get the username on all major platforms?
Tzury: 35:54 What about Atmo? Is it playing with atom.
Connor: 36:02 Yeah. Atmo is actually playing on the word atmosphere. When something is coming into the Earth's atmosphere, they say entering Atmo kind of thing, all of the projects have a bit of a space flight theme to them. Something that I'm still a little bit of joy for myself as I give them the cool nerdy names.
Justin: 36:16 Then you're using Orbit for community management.
Connor: 36:20 Yeah. I've been playing around with that platform too. It's a fun little coincidence there. Yeah, Orbit's great. There's a bunch of products coming up in this space. Like I've been looking at Comscore as well and there's some other ones that I haven't even had a chance to try yet. But community management and community analytics is a big trend these days that I've been seeing. I'm really happy about it, especially because it kind of coincides with me trying to build a community. I've got a lot of brand new fancy tools at my disposal to try and build this well.
Justin: 36:47 Yeah. I got to definitely get on Orbit. It's on my to-do list. It's just been pretty busy here. Pretty, pretty busy.
Connor: 36:56 I recently actually got to meet Patrick one of the founders.
Justin: 37:01 He's my boy. We hang out. Him and Josh, Josh is the Co-Founder really great team. Love them.
Connor: 37:12 Yeah and then Mac and the team over at Comscore have also been doing really great work. They've got an investment firm like Alexis Ohanian, 776, like there's a big upswell of community tooling coming up these days.
Tzury: 37:23 If I recall correctly, Firebase cloud function about two years ago or so they announced support for WebAssembly I'm talking about cloud Firebase, Google Firebase.
Connor: 37:38 I'm not even sure I've seen that one.
Tzury: 37:41 I'm just thinking how about for developers, an idea. If you have a Firebase operation and a very popular in a mobile space. Take Atmo as an option or at least if a developer would like to explore how to integrate Atmo in their operating platform. They can probably consider, I'm just trying to think for myself, which of running platforms that I'm in charge with, can experiment with it. Have you considered actually integrating with clouds functions around the world and making it easier for like server lists and all those frames, writing on those?
Connor: 38:30 Yeah. it's an interesting question because there was actually a project called assembly lift run by somebody I know well, Dan. That project is specifically designed around running WebAssembly in AWS Lambda. There are projects specifically designed for that. I am myself not targeting the existing server list platforms because I don't agree. It's not something that I vehemently opposed, but I don't work well with the model of current server lists. It doesn't feel ergonomic to me the way that you have to organize projects and organize your code and the way that it's deployed, and the way that it's so tightly coupled to the vendors that provide them.
That is not true for all of them. There's things like that are Kubernetes based and stuff like that. But I don't enjoy building on the current generation of server lists hosted server list platforms. That's why Atmo is function-based. It takes some of the parts that I do like about designing code for it. But it's not like the server list the way that you think about it with Lambda, where it is designed to be obstructed away from you. You don't have to care about how it's running and it's designed to manage itself, but it's not the current style of server list. I would consider Atmo pseudo server list platform.
It's not quite server list, but it's not server list. I think it lends itself like the main differentiator for me is how do you organize your project? You as a developer, how are you fitting all of the pieces together? With current server list, there's just so much like popsicles and glue sticks that you have to use to thread logic through the different AWS or Google products to make everything work the way you want. That's just not how my brain works. That's not how I like to build systems. They've done some really amazing things on the technology side. It's just the ergonomics of it is not the way I like to work.
That's why Atmo is slightly different. I would like Atmo to be able to replace Lambda in some senses. Like it could be the platform that you build on top of, instead of Lambda. It doesn't mean it can inter-operate with Lambda, especially like with something like assembly, you could build code that runs both on Atmo and on assembly lift and have them work together. There's no reason you can't do that. It's just not something that I feel like I need to be working on right now.
Justin: 40:55 Anything else we want to cover?
Connor: 40:58 I mean, from my end, I would just love to get feedback on the suborbital projects, the documentation, the tooling, the experience of building an application. These are all things that I care very much about. If you want to join the suborbital discord or file issues in the GitHub repos or join the GitHub discussions in our meta repo, these are all places that you can reach me. I'd love to hear anyone's thoughts about the tools and the frameworks.
Tzury: 41:23 So it's suborbital.dev and it's github.com/suborbital and Twitter suborbital.
Connor: 41:31 That's right. Yeah. If you go to chat.suborbital.dev it's take you right to our server.
Justin: 41:35 That's smart, a redirect.
Tzury: 41:38 We have learned a lot today Connor.
Justin: 41:41 We have. I've never seen someone so excited about Wasm. I hear people talk about it, but you are a great brand advocate for Wasm. I'm really excited that you came on the show because since I've been in this cloud native space for four months or so WebAssembly is, but next to Rust is probably the hottest buzzword there is. It's cool to see that it's not just a buzzword and it's being applied at companies like 1password. It's pretty cool.
Connor: 42:16 There's so many smart people working on these problems right now. I really believe like WebAssembly is going to be one of the killer technologies of the 2020s.
Justin: 42:23 Yeah, I agree. I mean, once I found out that Sigma ran on WebAssembly I was like, oh, I get why WebAssembly is so good, but I never even thought that it was going to be used as a back-end server side at all.
Connor: 42:40 If there's one kind of idea that I could leave off with, is that I'm hoping a couple years from now WebAssembly will just be an implementation detail. I don't want WebAssembly to be the headline feature on my website in three years. I want it to be a footnote. I want to be able to take advantage of all the great properties that it gives us, the security and the portability and the performance that it gives us. But it should be an implementation detail. You shouldn't need to care in a couple of years.
Tzury: 43:08 So you mean suborbital on its own regardless of the actual under the hood languages, all of those details.
Connor: 43:15 You should be using Atmo because of the systems that it lets you build and design, not because it's a WebAssembly.
Tzury: 43:22 The security is simplicity and all those benefits. Well, I wish you will actually get to there which you spend majority of your time on this project without interfering with your career at 1password. Maybe they would love to have you on both. It's great potential, great project.
Connor: 43:45 Thank you.
Announcer: 43:47 Listeners. I hope you enjoyed this one. Do tune in next time. We're really excited about our lineup of guests. We have super exciting guests next week as well. Check out the show notes for this podcast at podcast.curiefense.io. for the community to cloud native podcast. Thanks again for listening tune in next week, catch you later.
Special Guest: Connor Hicks.
Sponsored by Reblaze, creators of Curiefense
Panelists
Justin Dorfman | Tzury Bar Yochay
Guest
Connor Hicks
Show Notes
Hello and welcome to Committing to Cloud Native Podcast! It’s the podcast by Reblaze where we talk about open source maintainers, contributors, sustainers, and their experiences in the Cloud Native space. Today as our guest, we have Connor Hicks, Maintainer of Suborbital and Staff Software Developer, Product Discovery Lead at 1Password. We will learn all about Suborbital and how it’s going to make Cloud Native better, and the three projects that he refers to as the building blocks. We also find out more about 1Password, how they are using 1Password with Cloud Native with their projects, and their most recent launch of 1Password Secrets Automation. Connor talks about his partnership with HashiCorp, and we hear his thoughts on the complexity in the Cloud Native world. Go ahead and download this episode now because there is so much more we talk about with Connor!
[00:01:41] Connor explains what Suborbital is and how it’s going to make Cloud Native better.
[00:03:04] Microsoft, Google, Intel, and Mozilla want to move WebAssembly beyond the browser, and Conner explains what this means.
[00:05:00] Connor tells us a little bit about himself and how he got into computers and software, and why he decided iOS development was not for him.
[00:09:46] We find out more about how many front-end applications there are today using WebAssembly, and he mentions Figma and Internet Archive.
[00:10:33] Connor explains two ways you can take advantage of Suborbitals projects. He explains the three projects that he refers as the building blocks: Graph, Reactr, and Vectr, which together form Atmo.
[00:14:28] Justin wonders since Connor is not looking for sponsors, donations, or patrons, how is he sustaining this and what’s the plan. Also, Justin wonders if he’s considered submitting any of his projects to the CNCF.
[00:15:25] Tzury asks Connor if he’s doing all this work by himself or if he’s collaborating with others, and Justin asks how he’s managing his community. Connor talks about their recent launch of 1Password Secrets Automation, and how they’re now also offering Cloud Native software to their customers to run, which are the 1Password Connect Server, 1Password SCIM bridge, and 1Password command-line tool.
[00:19:35] Connor tells us about his partnership with HashiCorp.
[00:20:23] We find out how Connor feels about the complexity in the Cloud Native world.
[00:25:05] Tzury asks Connor if Atmo is used to replace obligation from development or if it used to empower existing ones, and if it’s extendable and pluggable. Connor also tells us about using programming languages that they support such as Rust, Go, Swift, and AssemblyScript. Connor mentions using Unicorn Platform in helping him design his website.
[00:29:05] Find out why Connor recommends not using Atmo for production use yet.
[00:30:14] We learn what the available server-side technologies are to plugin and to integrate with WebAssembly modules or WebAssembly code.
[00:34:09] Connor tells us where the 1Password name came from and where he came up with the name Suborbital and Atmo.
[00:40:28] Connor tells us how he would like Atmo to replace Lambda in some ways. He tells us he would love to get feedback on the Suborbital projects so you can join the Suborbital discord, file issues in the GitHub repos, or join the GitHub discussions in their Meta Repo and reach out to Connor.
Quotes
[00:01:51] “It’s a family of open source projects and each of them individually may not stream WebAssembly, but that is actually the main theme, enabling WebAssembly specifically on the server side.”
[00:10:53] “And that’s because the projects are organized to be a set of building blocks and then a platform built on those building blocks. So, the three projects that I refer to as the building blocks are Grav, Reactr, and Vectr.”
[00:14:43] “It’s something that I just love doing.”
[00:15:14] “Once WebAssembly as a whole kind of builds up a bit more steam and once the user base grows a little bit, it’s definitely something that I want to think about doing.”
[00:17:22] ”Yeah, there’s a little bit of use of some of the Suborbital building blocks.”
[00:17:52] “And so, we’ve built up quite a lot of experience running Cloud Native at 1Password.”
[00:18:37] “There’s been a bunch of lessons learned, because not only are we running Cloud Native software to power 1Password, but we’re now also offering Cloud Native software to our customers to run.”
[00:19:41] “So what you can do now is you can actually, there’s a plugin for HashiCorp vaults with 1Password Secrets Automation so you can actually make your 1Password data available through HashiCorp vault using their backend system.”
[00:20:33] “So, I definitely have thoughts here and that’s one of the main drivers when I’m building Suborbital.”
[00:22:36] “But you can imagine where a system that can intelligently decide where to run the different pieces of compute that comprise your application, and that’s something that I’ve been calling decomposed computing.”
[00:23:54] “Absorbing complexity where it makes sense is always the right call.”
[00:26:08] “And I won’t go off on too much of a tangent, but I do believe “Go” is the best thing to be using for Cloud Native right now.”
[00:42:40] “And if there’s one kind of idea that I could leave off with is that I’m hoping a couple of years from now, WebAssembly will just be an implementation detail. I don’t want WebAssembly to be the headline feature on my website in three years, I want it to be a footnote.”
Links
Cloud Native Community Groups-Curifense
“Microsoft, Google, Intel and Mozilla want to move WebAssembly beyond the browser”-ZDNet
Credits
Executive Produced by Tzury Bar Yochay
Produced by Justin Dorfman
Edited by Paul M. Bahr at Peachtree Sound
Show notes by DeAnn Bahr at Peachtree Sound
Transcript by Layten Pryce
Transcript
Connor: 00:02 The number of layers that you need to be thinking about constantly is crazy. Orchestration, networking. Do I add a service mesh? How do I run my database? What are the differences between the cloud providers, Kubernetes distributions. What's this K3S thing thing over here. There's just so much to think about. It used to be so simple. You would throw up a VM, you would auto scale it and you would run your monolith. I don't think we should go back to that by any means, but I think there's a new generation on the horizon that gives us some of the best of both.
Announcer: 00:39 Hello and welcome to Committing to Cloud Native, the podcast where we talk about the interface between open source and cloud native. We're super excited about our guest today. Can't wait to introduce him. Our panelists today are Justin Dorfman and Tzury [inaudible 00:54] and they're going to have an awesome conversation. I really enjoyed listening to it and I really hope you enjoy this conversation.
Justin: 01:03 Hey Connor, how are you?
Connor: 01:04 Hey, doing well. How are you?
Justin: 01:06 Great, good to see you in the flesh. Sometimes it's weird because when you meet someone on Twitter, it's like you got the static image and now like you're alive, full color and everything. Yeah. I saw you host something. This thing called suborbital. Before we go into that, I want Tzury to say hello. Tzury, say what's up.
Tzury: 01:29 Hey Connor, how are you?
Connor: 01:30 Doing great. How are you?
Tzury: 01:32 Thank you for coming on the podcast.
Connor: 01:34 Yeah. It's my pleasure.
Justin: 01:36 I got questions for days, but we only have 40 minutes. Let's get started. What is, suborbital tell the folks listening to this, what it is, why we need it, how it is going to make cloud native better.
Connor: 01:52 It's a family of open-source projects and each of them individually may not scream Web Assembly but that is actually the main theme, is enabling WebAssembly specifically on the server side. It's split up into a couple of different modules. There's vector graph, reactor, Atmo. These are all different projects that when you put them together, they allow you to do some interesting things, when building server side technology.
Justin: 02:25 Got it. Ever since I went into the cloud native space, all I hear about is WebAssembly. I think what's interesting actually, ZD net did a story about it, the byte code alliance. Are you part of the byte code alliance? There is this project part of it?
Connor: 02:44 I meet with them regularly, but I am not personally a member just yet. I think they actually just opened up for new members like this week. I've been looking into doing that, but most of the members are companies and suborbital is not a company, it's an open-source project. I've been talking with them quite a lot though. I really love what they're doing.
Justin: 03:04 Microsoft, Google, Intel, Mozilla. They want to move WebAssembly beyond the browser. What does that mean?
Connor: 03:11 It was originally kind of designed as a technology to enable compiled languages other than JavaScript to be used in the web browser. That was honestly still what most people associated with. But in fact, WebAssembly is not specific to the web browser in any way. It was just the first thing that it was adopted in. WebAssembly at its core is a way of representing byte code, compiled code and where you run that, it's up to you. I mean, you can absolutely embed it in the browser and you can run it to power web applications, but there's a ton of other use cases for it.
The ones that I work with are made for developing cloud native services software, but there's others such as IOT devices, embedded applications, there's non cloud native, non-browser things like desktop applications. It's really whatever you can think of. There's probably some way of incorporating WebAssembly into it.
Tzury: 04:13 We could spend a day talking about WebAssembly, it's greatness. I hope we're going to do a lot with Web Assembling this conversation. I mean, just mentioning the facts, talking about just shortly type language, you can buy into any runtime application without recompiling takes a week, consider nearly impossible or really hard to get done in previous to study compiled languages.
We can talk about V8 role in these revolutionary in JavaScript [inaudible 04:43] and WebAssembly falling after that. I would love if you can Connor to take us through the history and the evolution and the revolution of these technology in the recent, I would say, what 10 years is it around, a decade around us, more or less. But before we get to Connor, I'd like myself and our audience to know you a little better. If you can step back a little bit, tell us about your history. How did you get into computers, software, etc?
Connor: 05:15 Yeah, for sure. I did a computer science degree in university and I don't think that's so uncommon, but definitely not by any means needed anymore. That's just the way that I went. During school I did a couple of internships. I worked for Airbus in their defense and space division. I worked for WordPress in their VIP division. Then my last year of school, I got an internship at 1password. I was actually in the iOS team that was building their iOS app.
After I graduated, I decided that iOS development wasn't for me. I wanted to try something else. Just so happened that there was a prototype sitting in a get repo somewhere of a command line tool for 1password. I asked if I could pick that up and work with that. They thankfully said I could. That kind of took my transition out of the mobile development space and into more of the automation and tooling space. Then from there, I started working more on the systems and back-end side of things. I built a team around integrations and now I lead a team called product discovery there, which is all about research and development and trying out new ideas.
Then for the last year and a half or two years or so, I've been working on this idea of suborbital and it started out as a functions as a service system for Docker. It was nice, but there was nothing truly special about it. There was nothing that Kubernetes, Docker, OpenFAST couldn't already do. That's when I kind of took a pause and ask myself, what could I build in the space? Because it was a very interesting space to me, distributed computing, job processing, all that kind of stuff. I love thinking about those problems. I was like, what can I build that would be unique and differentiate itself from everything else out there.
That's where WebAssembly kind of came onto the scene. I will say, like I actually built server side WebAssembly before I ever even built WebAssembly that runs in the browser, which I think is strange, but I never even bothered running WebAssembly in the browser. I just went right to the service. That's how my brain works these days. I think in terms of distributed systems.
Tzury: 07:31 Well, don't get me wrong. I mean, the world will benefit more from you doing cloud native than mobile native apps. But as you mentioned that you decided iOS development is not for you, I wonder, what was it in iOS development, I mean, I never experienced, I never even tried developing iOS application. I did so many all sorts of development platforms, but never did this one. What was in the process in the technology, in the tooling or that move you away from it?
Connor: 08:08 It's none of those things actually believe it or not. I think Apple has some of the best software design and tooling available. I mean, X code has a little bit to be desired. At least it did when I was using it. I've heard it's gotten a little better since I last touched it, but it's none of those things that made me want to switch. It was actually the fact that I just had no desire to build user interfaces. That was the thing that wasn't working well for me. It just became, something that I lost interest in. Even to this day, like building web applications, like front end development, web application, it still doesn't really vibe with me. It's not something that I enjoy doing. It's very cool and it takes a lot of skill and it's something I respect highly, but it's definitely not my cup of tea.
Tzury: 08:55 So you would rather developers will use your API application programming interface rather than users using your interface.
Connor: 09:09 Yeah. I love having developers as my users and my customers.
Tzury: 09:13 That's interesting the transition that language that was mainly design and mainly targeting browser makes its way eventually to the server side. I would say even more far more popular, more common than actually in the browser. I'm sure there's applications that we know is an end user to actually make use of WebAssembly. But every existing server platform. Every LLVM language will have it's WebAssembly. Is that the case?
Connor: 09:47 You'll actually be surprised at how many front-end applications there are out there today using WebAssembly. It's definitely not totally saturated yet. There hasn't been a massive wave of people using it, but it's more than I think you would expect. Some recent ones that have come up is for example, Figma the very popular design application. They use that to help rendering. One of my favorites as the internet archive, using it to emulate flash, to be able to preserve old flash.
A bunch of gaming applications as well that have come up in the last little while. But it's one of those things that you have no idea that you're interfacing with it, right? When it's running in the web browser, you have no idea that it's being used. But it's more popular than you might think.
Tzury: 10:34 Where is the suborbital come into play when it comes to cloud native and service side that should protect applications in WebAssembly?
Connor: 10:43 There's two different ways that you can take advantage of suborbitals projects. There's what I call it, the do it yourself way or there's what I call the batteries included way. That's because the projects are organized to be a set of building blocks and then a platform built on those building blocks. The three projects that I refer to as the building blocks are graph, reactor and vector.
Graph is what I call a distributed messaging mesh. It's actually an obstruction over messaging protocols and discovery protocols that allow you to really easily write asynchronous code for communicating on the network. Then vector is an HTTP framework for go, not exactly consequential to WebAssembly, but it integrates really well with the rest of the suborbital ecosystem. It's one of my like passion projects. It's not for everyone. It's very opinionated, but I think it's great.
Then there's reactor, which is the core WebAssembly runtime. It's a function scheduler or a job scheduler that allows you to run either Go or WebAssembly workloads, either one they're completely interchangeable. It provides the execution environment for WebAssembly, powered by the Wasm runtime under the hood. It allows you to run many WebAssembly modules all at once. It manages their memory. it manages inputs and outputs, and it provides APIs to the WebAssembly sandbox, that developers can use to actually gain the capabilities that they need to write applications for the server. That's called the runnable API.
It's something that I've been working on quite a lot lately. It's something you have to do, to interact with that sandbox. Because WebAssembly is denied by default and it means that nothing can access the outside world unless you explicitly granted the permission to do so. Reactor manages all of that on behalf of the developer so you don't actually need to think about it. Then when you put those three together, those three building blocks together, they form Atmo and Atmo is the batteries included version if you will.
It means that you don't actually need to set up a web server or TLS or any of the boilerplate that you would normally need to write when you're building a web service, you interact with it, using what I call the directive, which is a declarative format for defining your web services. It lets you define the end points and the routes and all of the steps that you want the application to follow, to handle those endpoints. You do so by composing together functions that are compiled to WebAssembly.
A project for Atmo is a collection of functions written in various languages. We support Rust and Swift and TypeScript slash assembly script is coming very soon. It'll build all of your functions to WebAssembly modules. It'll package them all up together with your directive and with a set of static files. Then Atmo will take that bundle and execute the application as you've described it in the directive without you needing to write any boilerplate code whatsoever. There's a couple of different ways that you can approach it. I think it's a nice mixture of control. If you want to go the do it yourself route and have sole maximum control or simplicity and go with the Atm route batteries included.
Justin: 14:16 All this is open source?
Connor: 14:19 That's right.
Justin: 14:22 I saw on your website, you're currently not looking for sponsor, by the way, your websites are beautiful. They're so polished. Love them. But if you're not looking for sponsors donations or patrons, how are you sustaining this? Like what is going on? What's the plan here?
Connor: 14:39 I work for 1password. That's my job. I work on suborbital and evenings and weekends. It's my own time. It's something that I just love doing. That's something that I enjoy. I've been working on for almost years now. While it might seem that there's a lot there, it's been building up over a long period of time. It's just really enjoyable for me. I love interacting with other developers through open source. It's just fascinating problems that I like to solve.
Justin: 15:06 Have you considered submitting any of your projects to the CNCF?
Connor: 15:13 Yeah, it's definitely something I've considered once WebAssembly as a whole kind of builds up a bit more steam, and the user base grows a little bit. It's definitely something that I want to think about doing.
Tzury:15:25 Are you doing all this work by yourself on your own? Are you collaborating with others? This sounds like a lot to achieve on a spare time?
Connor: 15:35 Yeah. There's definitely some open source contributors that have come in and helped out. Especially on the tooling side with the suborbital, SCLI called Subo, and with a graph project and the reactor project as well. I definitely have spent a lot of time on it myself. Contributors started coming on board maybe six months ago as the popularity of the project started to grow a little bit. A good chunk of it is me, but there's definitely they're contributors as well.
Justin: 15:59 How are you managing like your community? Just like have a slack? Basically, Tzury and I started this podcast because we want to learn from other open-source maintainers. If we ask you questions that might seem basic, they kind of are because we're learning.
Connor: 16:16 Community is something that I'm learning. It's somewhat new to me. I've done some community stuff through 1password through a command line tool, but I am putting a bit more of a concerted effort on it for suborbital. We have a discord for example, that you can join if you'd go to chat.suborbital.dev, it'll take you right there. A fair amount of interaction honestly happens in Twitter. It's one of the most active places like I've been tinkering with some community analytics apps like Comscore and Orbit. When you look at the graphs, like, sure, GitHub is number one. But actually Twitter is even more active than Dysport and people love to, retweet things. That often lets you go a little bit viral on a particular day.
Justin: 17:01 And then you're doing podcasts with the people that find you on Twitter.
Connor: 17:04 Yeah. That's like, that's actually pretty much how it's done. I'll have a particular tweet that gets a bit of attention and then somebody will reach out saying, hey, come show off what you're working on this YouTube show or this podcast. I love doing them. There's so much fun.
Justin: 17:16 Here's another question. 1password is your bread and butter. How are they using cloud native? Are they using any of your projects like what's going on?
Connor: 17:27 Yeah, there's a little bit of use of some of the suborbital building blocks. One password actually started out. However, I think it was well over a decade ago now it was just a Mac app and it's now grown to being, we have an app on every platform. Then in 2015, actually, literally the day I joined the company, they launched one password for Teams, which is the cloud product that we now just know as 1password because almost everybody uses the cloud offering now. We've built up quite a lot of experience running cloud native, 1password did the entire service. 1password.com is a Go system that has treated us extraordinarily well. We've been expanding more recently into integrations.
You might've seen two weeks ago, we launched 1password secrets automation, which is an extension and an expansion of what 1password normally does, which is the usernames and passwords and credit cards that you as a person use day to day. We've now expanded that to include infrastructure secrets, Kubernetes plugins, HashiCorp Vault plugin, all sorts of things to manage the secrets that machines and your business needs to run all sorts of different automations around that.
There's definitely been some expansion there and there's been a bunch of lessons learned because not only are we running cloud native software to power 1password, but we're now also offering cloud native software to our customers to run. There's the 1password connect server that actually links 1password into your infrastructure. There's the 1password skim bridge that lets you connect with identity services like Okta, and the one password command line tool, which was kind of the way that I started out there.
There's plenty of different things that have come in the last couple of years. That makes a lot of sense for 1password.
Justin: 19:08 I would have never known that.
Tzury: 19:10 I had no idea and I'm glad to hear about it.
Justin: 19:12 Me too. This is awesome.
Connor: 19:14 It literally launched on April 13th. Just a couple of weeks ago and it was a pretty great launch, got quite a lot of attention.
Tzury: 19:21 We're too focus on our products. We no longer pay attention to what happens.
Justin: 19:28 I'm like way too close to fire. You need to get back and like, see what else is going on. I don't get it. Are you competing with HashiCorp or you're working with HashiCor? What's going on?
Connor: 19:41 No, absolutely not. We actually have a partnership with HashiCorp. What you can do now is you can actually, there's a plugin for HashiCorp Vault with 1password secrets automation. You can actually make your 1password data available through HashiCorp Vault using their back end system.
Justin: 19:57 Now that's a smart idea because they are very ingrained into the cloud native landscape. Hooking up with them, I think that's a brilliant move. We've been doing this podcast for well over two months or so. Half of the people that come on this podcast say cloud native is way too complicated and little less than half that say it's easy. It's the most easiest thing in the world. I know you have some feelings on complexity in the cloud native world. Talk to me and the audience about this.
Connor: 20:35 I definitely have thoughts here. That's one of the main drivers when I'm building suborbital I'm constantly thinking about the complexity needed to get this system up and running in production. It's a double-edged sword like no other where you have a massive amount of customization and options available to you in this space. But then that just flips around and becomes paralysis of like, what do I choose. Will making a certain decision ruin my system five years down the line if I choose wrong. The number of layers that you need to be thinking about constantly is crazy. Orchestration, networking. Do I add a service mesh? How do I run my database?
What are the differences between the cloud providers and Kubernetes distributions? What's this K3s thing over here. There's just so much to think about. It used to be so simple. You would throw up a VM, you would auto scale it and you would run your monolith. I don't think we should go back to that by any means, but I think there's a new generation on the horizon that gives us some of the best of both. That's what I'm trying to do with Atmo. Atmo is designed to give you the best scaling properties of microservices and server list, while still keeping your code base and the architecture of your system simpler.
It's enabled by WebAssembly. That's the great thing because an Atmo application is split up into what could be dozens or even hundreds of tiny WebAssembly modules, that are all working in concert to solve the goals of your application. Atmo can distribute that execution among many instances or even across multiple layers of the network, like Edge, Central Cloud, even devices one day. I haven't quite gotten that far yet, but you can imagine where a system that can intelligently decide where to run the different pieces of compute that comprise your application.
That's something that I've been calling decomposed computing. That's not an official term or anything. That's just what I call it. Where if your application is already naturally broken up into these tiny pieces, you as the operator, as the developer, shouldn't need to care where those individual pieces are running, whether it's on an edge network in your AWS region or on a device somewhere. As long as it is achieving the business goals that you've described for it. My hope and whether it's through Atmo or through something else, my hope is that we can get to this place where "the network" tries to figure out more of this stuff for you.
A lot of the complexity that we see today gets abstracted down a level and the developers and the operators who are dealing with this stuff every day don't need to care so much and they can focus more on what actually brings value to the application.
Justin: 23:37 Basically, what you're saying is absorbing complexity and making it hard to screw up.
Connor: 23:42 That's exactly right. It's something I believe in. I think especially if you're building products and tools and services for developers, and I mean for everybody else, but developers are kind of what I focus on. Absorbing complexity, where it makes sense is always the right call. Give them the knobs and leavers that they need to customize and use the application the way that they need to use it. But do it in such a way that they can't accidentally break something. There should be no foot guns to be had anywhere in your system. There should be no combination of configuration options that causes them to get into a bad state, whether that's with performance or security or scalability, it should be really hard to screw it up so that they can focus on building what they need to make their application work.
Justin: 24:32 That's like the AWS way, if an engineer screws up at AWS, they don't blame the engineer. They blame themselves for that happening. It shouldn't have happened. I totally get that.
Connor: 24:45 Yeah. if you would deploy an Atmo application and something breaks or something behaves in a way that doesn't make sense, that's my fault. That's not your fault.
Justin: 24:53 Exactly. Accountability.
Connor: 24:56 Accountability in cloud native.
Tzury: 24:58 Just for me to better understand Atmo's I would say purpose and positioning, is it to replace existing application from development or is it to empower existing ones? Is it extendable? Is it pluggable?
Connor: 25:16 Yeah, that's a great question. If you use Atmo on its own, it could very easily slot into an existing microservice system, for example, because it's just a web server and it's a web server powered by WebAssembly and a declared a format and all this fancy new fun stuff, but it is a web service. You could slot it into an existing setup if you want it to.
Tzury: 25:40 Just for me to understand. You actually implemented your own web server or is it something that you're writing on? Like existing proxy or the networking?
Connor: 25:50 Yeah. It's based on Go's networking stack and it provides all of the abstractions and all of the boiler plate that you shouldn't need to deal with. It handles all of that for you, but it does use the Go networking stack to power all of that.
Tzury: 26:06 Well, that's quite powerful and stable.
Connor: 26:08 That's right. It won't go off on too much of a tangent, but I do believe Go is the best thing to be using for cloud native right now, of course there's others. Of course, Rust is the fancy thing that everybody loves.
But for building cloud native technology right now is the best choice. But to go back to the question of how it fits in, you can kind of think of Atmo roughly in the same vein of no JS where no JS is running JavaScript on the server and includes some APIs to make use of hardware. It makes use of the networking protocols that you need to use. It lets you run a technology that also just so happens to be traditional using the browser, lets you run it on the server. That's the comparison I like to make.
If you want to use that same WebAssembly runtime and power to extend existing applications, that's where those building blocks come in. If you want to add WebAssembly execution to an existing Go app, for example, you could use reactor. If you want to add these network mission capabilities to one of your existing applications, use graph.
It kind of depends on what your goal is.
Tzury: 27:16 Well, this is fascinating. You're actually saying, if I hear it correctly, say an organization already have code base running Go base platform. Now they can add more capabilities and diversity in terms of languages. They can write say service with Rust, compile it into WebAssembly and get Atmo to play along on top of the Go run time, for example. Is that correct?
Connor: 27:46 Yeah. If you want it to take some Rust code and run it as a standalone web service Atmo is fantastic. But if you want it to actually embed that Rust execution in an existing Go application, then you can use reactive.
Tzury: 27:57 Can I use any language that is compiled to WebAssembly to write an Atmo or any specific frameworks in specific languages are available.
Connor: 28:10 Yeah. That's a slightly tricky question because yes, it will run anything that compiles WebAssembly, but if you want to be able to take advantage of the capabilities provided by the runnable API, you have to use one of the languages that we support currently.
Tzury: 28:22 Which are Rust, Go, Swift
Connor: 28:27 And Assembly Script. Go will come shortly after Assembly Script.
Tzury: 28:30 This is so cool, man. Getting it done on spare time.
Justin: 28:36 It's so clean. Like you've been to the website, I just love design. I love talking about websites and how they look.
Connor: 28:43 Our plug, unicorn platform, it's a site builder that I really like I'll take no credit for actually developing it. I had just put the site together with the tools available from unicorn.
Justin: 28:52 Interesting. Wait, does it bright markdown and how does that work?
Connor: 28:56 It's a static site builder. It's very much a gooey kind of like a web flow or something like that.
Tzury: 29:06 Do you know of users using Atmo in production at scale?
Connor: I'm specifically not recommending Atmo for production use quite yet? Not because of stability problems, but because the API is changing very rapidly still. I can't expect anybody to build their entire big system on Atmo when I'm going to be kind of pulling the rug out from under them every couple of months. I'm hoping that will change fairly soon.
I'm hoping by Atmo beta five or so the, the API will have stabilized to the point where I can start recommending it for production use. We're on beta two right now. Beta three is right around the corner. However, the building blocks, they are quite stable and I would recommend those for production use. I do know of a couple of startups and a couple of companies that are using reactor, for example, to build custom functionality and run WebAssembly.
Nothing for Atmo yet because I've been specifically telling people, try it out, please give me all the feedback that you can. people have built a small hobby applications and some side projects with it. But I'm explicitly saying that it's not quite ready for production use yet.
Tzury: 30:06 Can you tell us a little bit about server side technology for runnning in executive web assemblies? Cause I know like Envoy as WebAssembly support for plugins first, it should be filters. What are the available server side technologies to plug in and to integrate with WebAssembly modules or WebAssembly cover?
Connor: 30:27 Yeah, for sure. There's actually quite an interesting landscape right now. It ranges all the way from like the low-level runtimes. Think Wasm time, which is run by the bytecode Alliance there's Wasmer and there are some other runtimes like whabam and second state SSBM, these are kind of the lowest level execution engines. Then as you build your way up to like the more high level obstructions and that's kind of where Atmo lives at the high level obstruction kind of application layer. Things in the middle include things like the cross lit project from Microsoft, which is actually allowing you to schedule WebAssembly using the Kubernetes API, which is really quite fascinating. Then you've got other frameworks that are kind of in the same vein as Atmo like Wasm cloud and a [inaudible 31:14]
These are other open source projects that are trying to accomplish some of the same goals using WebAssembly. Then if you go kind of even further past that there are some cloud providers and some actually hosted solutions that let you run WebAssembly. That includes Fastly's computer edge platform and the CloudFlare workers platform as well.
Tzury: 31:35 I believe those were actually using VA. Is that correct?
Connor: 31:39 That's right. Fastly platform is using Wasm time and Lucid because Fastly was one of the founding members of the byte code alliance. But CloudFlare workers is indeed using VA and actually most recently the denim project released support for WebAssembly and one of their fairly recent versions on their new cloud product is also going to be having WebAssembly support.
Tzury: 32:02 It's looks like a promising landscape and promising technology is awesome.
Justin: 32:09 The plethora of knowledge you hold around is Wasm is Wasm. It's crazy. It's awesome.
Connor: 32:17 I'll say one thing is that I'm not a compiler developer. I actually don't know a whole lot about compilers and the low level specifications and all of that stuff. I know a lot of people working on those things. I know people at the byte code alliance and who were in the WebAssembly working group, WebAssembly community group. Compilers aren't my thing. I work at a higher level, like a higher level abstraction than that. The work that they are doing in the compiler space to support WebAssembly, especially across multiple languages is quite impressive. I would definitely suggest checking out talks from like the WebAssembly summit, the recent WebAssembly live event and the upcoming cloud native WebAssembly day at KubeCon
Justin: 33:00 Are you attending that?
Connor: 33:01 I am giving a lightning talk at Wasm Day.
Justin: 33:05 That's cool, man. I was going to ask if you were going too. I'm glad it came up because I probably forgot, but in my notes I was going to say, bring up KubeCon and here it is. Are you representing 1password or are you representing your open source?
Connor: 33:24 I am a developer from 1password as part of part of my career, part of my title and all of those things. But the talk is about suborbital so why don't I say both.
Tzury: 33:35 Are they like sponsoring that event?
Connor: 33:38 No 1password isn't sponsoring that event, but they do participate in lots of events. For example, GopherCon is one that 1password sponsors year after year, actually a couple of years ago we were the diamond sponsor. We were like the marquee sponsors at GopherCon a couple of years ago, which was really fun. But yeah, not this particular event.
Tzury: 33:55 By the way, guys, 1password username for the brand of a company. Make sure you will never use the same 1password across all your websites.
Connor: 34:04 That's right. Password management is very important. Yeah.
Tzury: 34:09 I think that's where they got the name for it right?
Connor: 34:12 Yeah.
Tzury: 34:15 Because people use one password for everything they said, no, let us take care of it.
Connor: 34:19 That's right. That's right. The master password is what I think they refer to, 1password the name is you use your master password to unlock the application. Then it stores, generates and manages completely unique and strong passwords for every different website.
Tzury: 34:35 What if you forgot your master password, then you forgot the model of the first car your father had on 1974. What are you gonna do then?
Connor: 34:46 We have something called recovery that allows one of your family members in your family account to recover you if you forget your master password, or if you're part of a business or a team, then the administrators of your business can recover your account. Since everything is N10 encrypted, we actually could not unlock your account, even if we wanted to, because the cryptography happens right on your device.
We never hold the keys for that. Signing up for a family account and getting a couple of members of your family onboard is always a good idea.
Tzury: 35:13 Make sure you keep the relations with your family members.
Justin: 35:17 Don't get in a fight and then like, oh shoot.
Tzury: 35:22 Connor where did you get this cool names suborbital?
Connor: 35:28 I am a big space flight nerd. I love watching rocket launches and I follow all that stuff very closely. That was kind of the inspiration for it. But the main reason why I chose this name in particular is that the GitHub username was available.
Justin: 35:40 That's all that matters at the end of the day. Is the domain available? Can you get the username on all major platforms?
Tzury: 35:54 What about Atmo? Is it playing with atom.
Connor: 36:02 Yeah. Atmo is actually playing on the word atmosphere. When something is coming into the Earth's atmosphere, they say entering Atmo kind of thing, all of the projects have a bit of a space flight theme to them. Something that I'm still a little bit of joy for myself as I give them the cool nerdy names.
Justin: 36:16 Then you're using Orbit for community management.
Connor: 36:20 Yeah. I've been playing around with that platform too. It's a fun little coincidence there. Yeah, Orbit's great. There's a bunch of products coming up in this space. Like I've been looking at Comscore as well and there's some other ones that I haven't even had a chance to try yet. But community management and community analytics is a big trend these days that I've been seeing. I'm really happy about it, especially because it kind of coincides with me trying to build a community. I've got a lot of brand new fancy tools at my disposal to try and build this well.
Justin: 36:47 Yeah. I got to definitely get on Orbit. It's on my to-do list. It's just been pretty busy here. Pretty, pretty busy.
Connor: 36:56 I recently actually got to meet Patrick one of the founders.
Justin: 37:01 He's my boy. We hang out. Him and Josh, Josh is the Co-Founder really great team. Love them.
Connor: 37:12 Yeah and then Mac and the team over at Comscore have also been doing really great work. They've got an investment firm like Alexis Ohanian, 776, like there's a big upswell of community tooling coming up these days.
Tzury: 37:23 If I recall correctly, Firebase cloud function about two years ago or so they announced support for WebAssembly I'm talking about cloud Firebase, Google Firebase.
Connor: 37:38 I'm not even sure I've seen that one.
Tzury: 37:41 I'm just thinking how about for developers, an idea. If you have a Firebase operation and a very popular in a mobile space. Take Atmo as an option or at least if a developer would like to explore how to integrate Atmo in their operating platform. They can probably consider, I'm just trying to think for myself, which of running platforms that I'm in charge with, can experiment with it. Have you considered actually integrating with clouds functions around the world and making it easier for like server lists and all those frames, writing on those?
Connor: 38:30 Yeah. it's an interesting question because there was actually a project called assembly lift run by somebody I know well, Dan. That project is specifically designed around running WebAssembly in AWS Lambda. There are projects specifically designed for that. I am myself not targeting the existing server list platforms because I don't agree. It's not something that I vehemently opposed, but I don't work well with the model of current server lists. It doesn't feel ergonomic to me the way that you have to organize projects and organize your code and the way that it's deployed, and the way that it's so tightly coupled to the vendors that provide them.
That is not true for all of them. There's things like that are Kubernetes based and stuff like that. But I don't enjoy building on the current generation of server lists hosted server list platforms. That's why Atmo is function-based. It takes some of the parts that I do like about designing code for it. But it's not like the server list the way that you think about it with Lambda, where it is designed to be obstructed away from you. You don't have to care about how it's running and it's designed to manage itself, but it's not the current style of server list. I would consider Atmo pseudo server list platform.
It's not quite server list, but it's not server list. I think it lends itself like the main differentiator for me is how do you organize your project? You as a developer, how are you fitting all of the pieces together? With current server list, there's just so much like popsicles and glue sticks that you have to use to thread logic through the different AWS or Google products to make everything work the way you want. That's just not how my brain works. That's not how I like to build systems. They've done some really amazing things on the technology side. It's just the ergonomics of it is not the way I like to work.
That's why Atmo is slightly different. I would like Atmo to be able to replace Lambda in some senses. Like it could be the platform that you build on top of, instead of Lambda. It doesn't mean it can inter-operate with Lambda, especially like with something like assembly, you could build code that runs both on Atmo and on assembly lift and have them work together. There's no reason you can't do that. It's just not something that I feel like I need to be working on right now.
Justin: 40:55 Anything else we want to cover?
Connor: 40:58 I mean, from my end, I would just love to get feedback on the suborbital projects, the documentation, the tooling, the experience of building an application. These are all things that I care very much about. If you want to join the suborbital discord or file issues in the GitHub repos or join the GitHub discussions in our meta repo, these are all places that you can reach me. I'd love to hear anyone's thoughts about the tools and the frameworks.
Tzury: 41:23 So it's suborbital.dev and it's github.com/suborbital and Twitter suborbital.
Connor: 41:31 That's right. Yeah. If you go to chat.suborbital.dev it's take you right to our server.
Justin: 41:35 That's smart, a redirect.
Tzury: 41:38 We have learned a lot today Connor.
Justin: 41:41 We have. I've never seen someone so excited about Wasm. I hear people talk about it, but you are a great brand advocate for Wasm. I'm really excited that you came on the show because since I've been in this cloud native space for four months or so WebAssembly is, but next to Rust is probably the hottest buzzword there is. It's cool to see that it's not just a buzzword and it's being applied at companies like 1password. It's pretty cool.
Connor: 42:16 There's so many smart people working on these problems right now. I really believe like WebAssembly is going to be one of the killer technologies of the 2020s.
Justin: 42:23 Yeah, I agree. I mean, once I found out that Sigma ran on WebAssembly I was like, oh, I get why WebAssembly is so good, but I never even thought that it was going to be used as a back-end server side at all.
Connor: 42:40 If there's one kind of idea that I could leave off with, is that I'm hoping a couple years from now WebAssembly will just be an implementation detail. I don't want WebAssembly to be the headline feature on my website in three years. I want it to be a footnote. I want to be able to take advantage of all the great properties that it gives us, the security and the portability and the performance that it gives us. But it should be an implementation detail. You shouldn't need to care in a couple of years.
Tzury: 43:08 So you mean suborbital on its own regardless of the actual under the hood languages, all of those details.
Connor: 43:15 You should be using Atmo because of the systems that it lets you build and design, not because it's a WebAssembly.
Tzury: 43:22 The security is simplicity and all those benefits. Well, I wish you will actually get to there which you spend majority of your time on this project without interfering with your career at 1password. Maybe they would love to have you on both. It's great potential, great project.
Connor: 43:45 Thank you.
Announcer: 43:47 Listeners. I hope you enjoyed this one. Do tune in next time. We're really excited about our lineup of guests. We have super exciting guests next week as well. Check out the show notes for this podcast at podcast.curiefense.io. for the community to cloud native podcast. Thanks again for listening tune in next week, catch you later.
Special Guest: Connor Hicks.
Sponsored By:
Curiefense: Protect Your Cloud Native Applications 👉 Try Curiefense today!