Apollo is a central platform for deploying and managing software
across many different types of environments of varying degrees of scale and complexity.
It operates using a hub and spoke architecture where the Apollo hub
is the platform control plane and you'll deploy an agent into each Kubernetes cluster or environment that you want to manage with Apollo.
And that agent does a couple of things.
It reports status back to your Apollo hub and then executes updates or changes
in those environments that the Apollo hub recommends.
In each of these managed environments,
you deploy and manage releases of your products.
Think of these as helm charts that you want to roll out across
all the environments under management.
And application owners will add their products to specific release channels,
and environment owners will subscribe to those channels based on their risk tolerance and appetite for new features.
Let's take a look at how a new release of an open source grafana helm chart
might roll out across environments that are being managed with Apollo.
In this hypothetical scenario, each grafana release will promote through a simple dev staging and
production stage of a promotion pipeline, and this is fully configurable to match workflows in your organization.
Application owners add products to these release channels and environment
owners subscribe to those channels based on their ability to tolerate risk and desire to take new releases.
So environments that are subscribed to the dev release channel here will get new features.
For example, grafana 9.3.6 the moment they're available.
As Apollo gathers data on the deployment of this release in dev environments,
it will determine whether it's ready for promotion to the staging release channel.
And for any of these channel promotion stages,
I can view the environments where this release is installed.
Environments that do have this release installed will contribute to key health monitoring.
So time requirements and you can configure the specific thresholds
which we call adjudication requirements in Apollo that must be met before the release
is automatically promoted then to the next release channel.
These channel promotion requirements are just one aspect of Apollo's constraint based deployment.
On the right, I see there are details about other types of constraints that
I can encode in addition to the release channels we just looked at.
You can also encode requirements based on custom labeling dependencies,
vulnerabilities, product recalls, maintenance,
Windows and Apollo will make sure that each of these constraints is met before recommending an upgrade in any one of the environments that use grafana.
So we've seen an active promotion pipeline for our releases.
But environment owners can also set requirements like maintenance windows and release channels for the environments that they manage.
Let's look at one of these environments, which here is notionally called EU production.
Here.
As an environment owner, I can easily find the product releases installed on any of the environments connected to Apollo,
and those environments also support many rich settings like maintenance,
Windows release channels so that me as an environment owner, I can encode my own requirements
so that it will essentially be the union of my requirements as an environment owner
and the requirements of the application set by the application developers that will let Apollo
know whether an upgrade should be recommended.
All these intersect and requirements are being evaluated constantly in the background.
It is autonomous deployment, but when you want to know what's going on behind the scenes,
Apollo gives us interfaces like this one.
To see a record of all the changes that have been made to our environment.
So in some we briefly looked at how this constraint based deployment works
from the perspective of an app owner as well as an environment owner, to show how Apollo's autonomous deployment
ensures that every requirement gets met while also helping us to balance stability and velocity.