Spinnaker: Single Pane of Glass for Software Delivery

Jul 17, 2018 by Alex Bello

Successful software delivery involves a combination of fast feedback from development through production, quick cycles that integrate production knowledge into the next release, and continuous improvements to the entire pipeline.

Each focus area tracks different data. Lead times capture time from idea to production. Telemetry data like response latency, error counts, and MTTR inform the team about production operations. Higher level metrics like change fail rates and deployment frequency provide the foundation for continuous improvement initiatives. Teams bend over backwards just to track this data—not to mention the effort that goes into acting upon said data.

Spinnaker powers the core of Armory’s Platform, which provides data and tooling to improve delivery performance. Armory acts as your team’s single pane of glass, enabling them to examine data in order to understand and control production operations, and automating many of the functions (like canary deployments) that were previously done manually — if at all.

Introducing Spinnaker

Spinnaker is Armory’s foundation. Spinnaker was originally designed and developed by the continuous delivery pioneer, Netflix. Netflix built and refined their continuous delivery process with AWS using Spinnaker. The open-source community extended the same feature set to Google Cloud, Microsoft Azure and Kubernetes. Spinnaker provides safe and consistent deployments to all of these platforms, whether it’s deploying VMs, containers or both (and support for serverless is already being built). Beyond that, Spinnaker’s features make it easier to run and maintain applications once they have been deployed. Pairing contextual information with action items creates a single pane of glass for development and operations.

Spinnaker provides a “golden path, with guardrails” level of standardization across deployent targets and clouds, and visibility into all your cloud infrastructure.

A Single Pane of Glass

The applications page is at Spinnaker’s core. The above image is from the official Spinnaker ebook. Box 1 shows the current application, box 2 shows the cluster and its health in the PROD account, box 3 shows a single server group with one healthy instance running version 001 from build number 189, and box 4 shows specific infrastructure details along with quick actions and logs. All of this information is provider-agnostic, so interactions are the same whether the applications run on Amazon AWS, Google GCP, Microsoft Azure or Kubernetes.

This beats working in each cloud provider’s admin console. Let’s assume for a moment that the “spindemo” application runs on AWS. The topology, such as autoscaling groups, EC2 instances, and ELBs, is available in one section of the console. Health may be in CloudWatch or EC2. Application logs likely live in a separate logging solution, so they are not even in the AWS console. These examples barely scratch the surface of how disjointed this information can be—and that does not even account for different cloud providers.

Information provides insight, which leads to action. Typically, users have to go elsewhere to act. The single pane of glass puts actions beside contextual information.

Spinnaker control panel

This screenshot from Armory’s demos shows what can be accomplished from the control panel: rollback, resize, destroy, and clone. Engineers (or even product owners) can initiate rollbacks if there is a problem. Is the application under-load or over-capacity? If so, you can adjust the capacity. Again, remember that these actions are infrastructure-agnostic. The screenshot shows an application running on Kubernetes. These actions would work the same way for non-containerized applications, as well.

Both rescaling and autoscaling are important to teams and end users. Autoscaling reduces cost while also adjusting to end users’ demands. Spinnaker bakes autoscaling into the platform. The following screen demonstrates creating a scaling policy that tracks average CPU utilization. Spinnaker contextualizes the target values with historical data so engineers can make more informed decisions.

Safety of software deployments affects the rate at which applications are delivered to customers. Unfortunately with the multitude of health metrics being emitted by each deployed application outside of the deployment process, it is not easy to visualize in context and take actions to improve your application’s general health.

Armory enhances Spinnaker with a turn-key SLA measurement service in order to ensure you are constantly measuring and improving the safety of your deployments. The SLAs are defined using existing application health metrics integrated into Spinnaker to provide a single pane of glass.

Spinnaker per-app SLA

Armory SLA dashboard

Increase Deployment Velocity through Safety

In order to increase deployment velocity and pace of innovation, Spinnaker provides several features aimed at mitigating the risk of deployments. One way, is to include canary stages as a part of the deployment pipeline. The canary stages send a percentage of production traffic to a new build of the application and analyze key metrics to determine whether the new build causes stability problems. Spinnaker integrates with underlying telemetry providers like Datadog and Google Stackdriver and performs automated canary analysis to determine whether to promote the new build to production.

Users may configure canary stages based on metrics like HTTP response latency and response counts without leaving Spinnaker. Spinnaker also provides history and reports. The screenshot below shows a canary report in action.

Automation aside, Spinnaker understands that manual sign-offs are sometimes needed to ensure stability and are a stepping stone to full software delivery automation. Sign-off may come from the QA team, a sales lead, or managers. Spinnaker bakes this directly into the pipeline management.

The manual judgement stage allows people to decide when it is appropriate to deploy to production. It is also customizable with questions so that it can be more than just a yes/no decision. The screenshot above shows a manual judgement before deploying to production. This stage, like any other stage, can split off into actions like triggering emails, paging the on-call person, or proceeding with the deployment.

Another example of the low-effort solution for mitigating risk and ensuring the safety of your deployments is to gate deployments to specific time windows. The image below shows a scheduled window overlayed with traffic data.

Launch, Extend and Adapt

Everything we have covered so far applies to existing applications, but Armory also extends Spinnaker for quickly launching new applications and adapting to existing workflows.

Armory’s one-click apps turn Spinnaker into a platform for launching new applications in a quick and consistent way. One-click apps automates the entire new application bootstrapping process: creating the git repo, configuring CI with Jenkins, and building a deployment pipeline. All of the existing features apply after the application has been created. In other words, Armory users do not need to leave the single pane of glass.

Spinnaker also supports custom stages to adapt and integrate into existing deployment workflows. Custom stages can have their own UIs, data, and business processes. Some examples of this are running a load test, executing Terraform scripts, flipping feature flags for some users, and simply filling the gap between Spinnaker and existing technology. Providing custom stages keeps Spinnaker at the center of production operations and the release process.


Spinnaker’s single pane of glass design centralizes deployment pipelines while ensuring adherence to continuous delivery best practices. It can configure canary stages, manage auto-scaling policies, integrate manual decisions, and handle everything related to deploying and rolling back applications.

Features are agnostic to the underlying technology. Teams can shift between AWS, Google Cloud, Microsoft Azure, and deploying Kubernetes applications to either cloud provider. How many other deployment systems can do that?

These features make Armory the best choice for enterprise teams to adopt continuous delivery, deploy applications, and manage production operations. Not feeling sure yet? Take Armory for a test run and see just how much is at your fingertips.

Recently Published Posts

Introducing Pipelines-as-Code Plugin for Open Source Spinnaker

Jul 21, 2023

Easily Scale and Automate with Version Control in Git Developers choose best-of-breed version control systems like GitHub for a reason: they need the ability to collaborate and improve code together.  But a broken Spinnaker deployment pipeline can often be the last thing standing in the way of getting your application to market.  Until now. Armory’s […]

Read more

What is FedRAMP and Why It Matters

Jun 8, 2023

What’s FedRAMP? Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP is important since it’s the gold standard for assessing cloud service providers (CSP) within the government. Under this program, authorized FedRAMP cloud service providers […]

Read more

New Spinnaker Operator Updates Now available for the Spinnaker Community

Mar 15, 2023

Stay up-to-date with the latest Kubernetes release with Spinnaker. The Armory crew has worked diligently the past several weeks to release a new stable version of OSS Operator (1.3.0). This is the first release in just over 18 months and is now available for the open source community.  What Changed? The Spinnaker Operator is the […]

Read more