What is Spinnaker?

At Nebulaworks, our Transformative Methodology consists of four steps: educate, build, adopt, and innovate. By utilizing DevOps approaches, cloud adoption, and “open-source first” and “fail fast” mentalities, we deliver measurable outcomes to IT teams. Often times, the topics of Continuous Delivery and Continuous Deployment (CD-I and CD-II or “CD” collectively) are discussed in engagements with our clients. A typical response to the question, “what tool should we use for this?"–whether it’s referring to using infrastructure-as-code (IaC) to provision the infrastructure in cloud environments, or to the container orchestrator that will act as the platform for our containerized applications–is “processes are far more important than tools.” However, we do have general recommendations for tools, and the tool that we typically recommend for Continuous Deployment (CD-II) is Spinnaker. To develop an adequate understanding of this tool, we need answer the question: What is Spinnaker?

What is Spinnaker?

To clarify before continuing, Spinnaker is a tool for Continuous Deployment (CD-II). The difference between Continuous Delivery (CD-I) and Continuous Deployment (CD-II) is that CD-I is the phase of CD in which deployment artifacts are created, tagged, promoted, etc., and CD-II is the phase of CD in which deployment artifacts are actually deployed onto your infrastructure.

Depending on the maturity of your software development life cycle (SDLC), Spinnaker might be beneficial to adopt and use. But if your current Continuous Deployment solution is using Jenkins-driven Bash scripts, or even worse, if it’s completely manual, then Spinnaker should probably be considered as a tool that can help elegantly automate away many of the steps in Continuous Deployment that are either manual, or not best practice. It is also important to note that although Spinnaker–and CD-II in general–can be adopted without mature Continuous Integration (CI), CD relies on CI, so it would not be wise to develop your CD pipeline without first creating or refining your CI pipeline. Finally, a baseline understanding of application architecture and bare-bones SDLC is needed in order to understand the subject matter in this article.

Spinnaker’s History

In the SDLC, CD-II is no longer an unsolved problem, and the need is apparent. But across the business space, among those who are creating software, CD is typically the least mature facet of their SDLC. Netflix (in conjunction with Google, Microsoft, and Pivotal) originally created Spinnaker as a replacement for Netflix’s legacy CD-II platform, Asgard. And since it’s release in 2015, it has been adopted by the CNCF and has overseen production workloads at large-enterprises like Netflix and Google, mid-sized companies like Gogo Air, and small companies like Nebulaworks.

Spinnaker’s Architecture

The architecture of Spinnaker (above) consists of various application architecture abstractions (from the bottom up):

• Server Group: the atomic unit of deployment in Spinnaker. It’s a collection of working units (virtual machine (VM) images, container images, etc.) that exist as artifacts when pre-deployed.
• Cluster: A group abstraction for Server Groups (a group of Server Groups).
• Application: A group abstraction for Clusters (a group of Clusters). An Application is meant to correlate one-to-one with a service: a service (whether its in a microservice architecture or not) is meant to be run as an Application in Spinnaker.

With some networking abstractions as well:

• Load Balancer: load balances traffic to the working units of a Server Group (VM’s, containers, etc.), by using an ingress protocol.
• Firewall: a definition for network access that sits between the load balancer and the Cluster that the load balancer balances traffic to.

By using these abstractions, in conjunction with modern deployment strategies like blue/green, and canary, Spinnaker manages the process of upgrading the software that lives on your infrastructure, so that, in the most automated case, code can be committed to your version control system (VCS), be continuously integrated into your code base, and be continuously deployed to your infrastructure with no manual steps in between.

Companies Adopting Spinnaker

At Netflix, over 95% of newly created autoscaling groups (in Amazon Web Services (AWS)) are created with Spinnaker. The Waze team at Google has 100% of their production deployments going through Spinnaker. Gogo Air–a mid-sized company that enables internet connectivity on airplanes–has mass adopted Spinnaker and has even created an open-source Spinnaker pipeline templating tool called Foremast that enables them to define Spinnaker pipelines with ease.

It is apparent from its mass adoption that Spinnaker is an incredibly useful tool, both for mature and immature software development pipelines. Spinnaker enables teams and organizations to automate away a lot of the manual steps that are typically associated with traditional deployment. If you’re curious about Spinnaker or would like to take the next step in maturing your CD pipeline, then please reach out to us.