Runner Architecture
How Nuon makes BYOC possible.
When building Nuon, the central design challenge we faced was how to allow vendors to manage an app in a customer’s cloud account without requiring cross-account access. Through multiple iterations — and a lot of learning things the hard way — we have arrived at our current architecture, built around the Nuon Runner.
Overview
At a high level, the Nuon platform consists of a Control Plane, remotely controlling Runners deployed into different accounts. The Control Plane does not send commands to the Runners. Instead, the Runners poll the Control Plane, waiting to be told to run a job. This allows the Control Plane to orchestrate jobs for all the Runners, without having any access to the accounts the Runners are hosted in.
No cross-account access is required to provision, maintain, and deprovision an install.
Now that you have a high-level view of the architecture, let’s dive into the details.
The Nuon Runner
The Runner itself is pretty simple. It is a stateless, stand-alone Golang binary, and it does three things:
- Polls the Control Plane for jobs.
- Runs jobs.
- Pipes logs from those jobs to the Control Plane.
helm install or terraform apply. These are not application logs. The Runner does not collect logs from your application.The level of access the runner has within the customer account can be controlled via permissions and policies. It can also be disabled and re-enabled by the customer if they don’t want it running at all times.
The Nuon Control Plane
The Control Plane is a more complex piece of machinery than the Runner. It is capable of orchestrating and monitoring jobs across many numbers of Runners, and acts as a single pane of glass across all of your app installs in all of your customer’s environments.
The Control API
The central component of the Control Plane is the Control API. This is the interface used to orchestrate and inspect apps, installs, and jobs. The Dashboard and CLI are built on top of this, and you can integrate with it yourself to build custom interfaces for both internal and customer use.
The Runner API
We maintain a separate API for Runners to interact with. This is the API they poll for jobs, and write logs and metrics to.
The Build Runner
The first step to provisioning your app components in an install is building an OCI artifact for Runners to pull. Because all of your Installs will be using the same artifacts, we provision a Build Runner for you in the Control Plane.
This is exactly the same executable used in Installs, and it works exactly the same way, except it only runs build jobs. This is the only part of the Control Plane that touches your source code and build artifacts.