Why you should be paying attention to Spinnaker 1.0 release

spinnaker 1.0 releaseYesterday Google Cloud announced the release of Spinnaker 1.0, a continuous delivery tool for software developers. Spinnaker is an open source, multi-cloud continuous delivery (CD) platform for high velocity software releases. I wanted to give some context as to why the Spinnaker 1.0 release is something you should pay attention to.

According to Google Cloud’s announcement, “Back in 2014, we (Google) started working with the Netflix team that created Spinnaker, and saw in it a release management platform that embodied many of our first principles for safe, frequent and reliable releases. Excited by its potential, we collaborated with Netflix to bring Spinnaker to the public, and they open-sourced it in November 2015. Since then, the Spinnaker community has grown to include dozens of organizations including Microsoft, Oracle, Target, Veritas, Schibsted, Armory and Kenzan, to name a few.”

Continuous Delivery to the infrastructure of your choice from an open source community

Spinnaker gives software teams the ability to deploy and continuously deliver code across multiple cloud providers including AWS EC2, Kubernetes, Google Compute Engine, Google Container Engine, Google App Engine, Microsoft Azure, and Openstack, with Oracle Bare Metal and DC/OS coming soon. It also gives developers the ability to create deployment pipelines that run integration and system tests, spin up and down server groups, and monitor your rollouts across this infrastructure.

Spinnaker allows you to trigger pipelines via git events, Jenkins, Travis CI, Docker, CRON, or other Spinnaker pipelines. Because the tool is open source, there is a wide breadth of experience across many organizations contributing to this project to share best practices across multiple types of infrastructure deployments. Users of Spinnaker can take advantage of that experience to create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues. Users also get to leverage immutable infrastructure in the cloud with built-in deployment strategies such as red/black and canary deployments.

Why does it matter that Spinnaker simplifies the CD process?

We worked on a lot of Continuous Integration / Continuous Deployment (CI/CD) projects over the last several years. The processes that Spinnaker includes all had to be debated and implemented in a bespoke fashion at each consulting engagement. When team members within an organization went to a team with a different CD mindset, people had to spend time learning and improving those CD workflows.

By using a CD tool like Spinnaker, software developers that are deploying applications to the cloud can benefit from the opinionated deployment strategies included within Spinnaker. This means that software developers can focus on their own application and leverage the mutli-cloud deployment strategies included with Spinnaker.

Out-of-the-box, Spinnaker supports sophisticated deployment strategies like release canaries, multiple staging environments, red/black (a.k.a. blue/green) deployments, traffic splitting and easy rollbacks. This is enabled in part by Spinnaker’s use of immutable infrastructure in the cloud, where changes to an application trigger a redeployment of an entire server fleet. Compare this to the traditional approach of configuring updates to running machines, which results in slower, riskier rollouts and hard-to-debug configuration-drift issues. With Spinnaker, you simply choose the deployment strategy you want to use for each environment, e.g. red/black for staging, rolling red/black for production, and it orchestrates the dozens of steps necessary under-the-hood. You don’t have to write your own deployment tool or maintain a complex web of Jenkins scripts to have enterprise-grade rollouts.

With the release of Spinnaker 1.0, Google also announced the launch of a new CLI tool, halyard, that helps admins more easily install, configure and upgrade a production-ready instance of Spinnaker. Prior to halyard and Spinnaker 1.0, admins had to manage each of the microservices that make up Spinnaker individually. Starting with 1.0, all new Spinnaker releases are individually versioned and follow semantic versioning. With halyard, upgrading to the latest Spinnaker release is as simple as running a CLI command.

Matthew Scott