Suborbital Compute public beta: a deep dive
This week marks the first public release of our product, Suborbital Compute. We’ve been working hard for most of the year to get it ready for software teams of all kinds to start using, and we’re really excited to show you what we’ve been building. The problem we are looking to solve with Compute is the rigidity that often comes with SaaS applications, specifically when it comes to integrations. Being able to mold a product to your exact needs can be the difference between a wonderful experience and a horrible headache.
Compute builds on top of our open source work with server-side WebAssembly to run code written by the users of SaaS application as part of the business logic of the product itself. Our open source Atmo server application environment can run untrusted code safely while still giving developers the capabilities they need to write useful functions. When your application is integrated with Compute, any key action can be tweaked or extended by your users with a few lines of code written in familiar languages.
Let’s dig into the technical details, starting with the architecture. Compute is comprised of two cooperating halves; the control plane and the data plane. The control plane contains two services:
scc-builder. These two services manage the administrative and code compilation tasks of Compute, and expose APIs that you can take advantage of to make executing user functions simple.
SCC stands for 'Suborbital Compute Core', which is the component of Compute that you install. The other components include a web app for signup, API server, and the hosted function editor application.
scc-controlplane service manages the metadata, permissions, and authentication for your Compute instance, helping your application get all of the details about the functions your users have written. It also allows you to grant authenticated users access to the function editor. One of the key roles of
scc-controlplane is to act as a ‘brain’ for the data plane, providing all of the configuration, authentication, and even the functions themselves to Atmo.
Moving over to
scc-builder, this is where your users’ functions are compiled from code into WebAssembly modules. The
scc-builder Docker image contains the toolchains needed to build AssemblyScript and Rust code (with more languages coming soon!), and exposes all of the APIs needed to power the function editor. When you deploy Compute, your builder instance is exposed on the public internet with a DNS record and TLS certificate so that the function editor embedded in your application can securely build and test your users’ code.
The builder contains a full templating, building, and testing system that makes working with code inside your app very simple for users. The builder can use custom templates and libraries that you develop to provide a completely customized experience. You are in full control of what your users start with when they create a new function, what APIs are available to them, and what languages they’re able to write with. When everything is perfect and they click ‘build’,
scc-builder compiles their code into compact, optimized WebAssembly modules and makes them immediately available for testing, right inside the editor itself.
The builder can run ephemeral tests on functions-in-progress so that your users can be fully confident that their code is ready for prime-time before pressing ‘deploy’. You can even create a set of predefined tests with example inputs that your users can run from the editor to test their functions against ‘real-ish’ data. Last but not least, the editor and builder coordinate to automatically manage versioning for user functions, ensuring that your application can execute any version of every function, and your users can keep a draft on the sidelines as long as they want before promoting it to an active version.
Moving on to the data plane, Compute runs our open source Atmo server application environment in an auto-scaled group to execute functions in an extremely efficient and scalable way. Atmo runs in ‘headless’ mode, meaning that it does away with the Directive application format that Atmo applications are usually built with, and instead loads and runs individual functions on dedicated endpoints. Atmo connects to the
scc-controlplane service to load its entire configuration and state, allowing the control plane to become the brain to Atmo’s brawn, so to speak.
Atmo manages an internal pool of WebAssembly runtime instances and automatically manages the memory, capabilities, and execution of Wasm functions. When your application calls a user function, Atmo either pulls the module from the control plane, or uses an already-loaded module to execute it, and even cold-starts start up in single-digit milliseconds. Atmo also loads capability configuration from the control plane and sets up its Wasm runtime instances to filter every single host call made by your modules to ensure they can only do what you’ve explicitly allowed, and nothing more. Your declarative
scc-config.yaml file is translated into a secure sandbox that lets your users access useful capabilities without putting your infrastructure at risk.
The Compute data plane employs a two-layered autoscaling approach. Within each instance of Atmo, individual functions can be autoscaled by increasing the number of WebAssembly runtime instances available to process requests. This is done continually, reacting instantly to spikes in traffic as new instances can be spun up in microseconds. As individual Atmo instances begin to reach their capacity, our custom Kubernetes autoscaler based on the KEDA project kicks in and begins spinning up more instances of Atmo to compensate. Metrics from Atmo’s internals are used to make autoscaling decisions, and this two-layered approach ensures that rapid spikes are handled instantly, while sustained changes in traffic to the entire system are absorbed and distributed across many hosts.
The final piece of the puzzle is not a part of your Compute Core deployment, but instead lives on the hosted Suborbital Compute Network. The function editor is a web application that includes a code editor, pseudo-terminal, and all of the control that users need to write, test, and build their functions. The editor is designed to be embedded into your web application, and is configured to securely access your deployed builder service. Individual authentication tokens are generated by the control plane to grant your users access to their functions (and only their functions) so that they get a seamless experience that feels like a native part of your product. The editor loads instantly, and feels familiar for any developer with syntax highlighting, easy testing, and an integrated console for build and test output.
Ready to give it a try? Get started right now!
Finally, let’s talk about how Compute Core is deployed. You can run it locally on your development machine using Docker Compose, and production deployments are installed into your Kubernetes cluster on any cloud infrastructure. Our Subo CLI tool automatically installs local and production instances of Compute Core, including configuring TLS for your builder service and setting up the KEDA-based autoscaler. Subo will also make it easy to administer Compute over time, offering easy updates, and a local REPL to make experimenting with the function editor on your local machine as easy as possible.
Suborbital Compute is the culmination of all our work with server-side WebAssembly, offering a secure and useful environment for your users to customize your SaaS product with code. We are very eager to hear your feedback and to help you deploy and integrate Compute. Please feel free to file issues on our feedback repository, email us to schedule a work session, or use the live chat on the last page of the Compute signup flow so that we can help make your experience (and your users’ experience) with Compute as smooth as possible. We’re really excited to iterate on Compute. This is only the beginning, there are so many more capabilities, languages, and features that we are planning to bring to Compute over the coming months, and we can’t do it without your help.