Spinnaker vs. Jenkins

Continuous delivery (CD) platforms help DevOps teams manage software releases in short cycles, ensuring they are delivered safely, reliably and quickly. The goal is to reduce the costs, time and associated risks connected to building, testing and delivering changes by enabling a more incremental and regular approach towards updating applications in production. The debate over whether Spinnaker or Jenkins is the better CD platform has been around for some time.

Originally created at Netflix, Spinnaker now has the backing of Google and several other major software companies. Last week, TechCrunch dubbed the open source CD platform as “the next big open source project to watch.” Its users include Target, Capital One, Adobe and Daimler and a developing ecosystem of vendors. In recent developments, the Spinnaker project announced it was putting a formal governance structure in place at its second community summit recently held in Seattle.

Jenkins, meanwhile, is an automation server to build, test, and deploy. While both CD are tools used for software updates, there are key differences. Spinnaker is not a build tool, but a deployment tool, with a focus on the cloud.

Continuous delivery (not continuous deployment)

While the two terms are often used interchangeably, there is one key difference between continuous delivery and continuous deployment. Continuous delivery (CD) means implementing a series of practices to ensure that software can be deployed, rapidly and safely, at any time. With continuous delivery, the deployment to production is manual. With continuous deployment, however, the process is automatic. It is the next step of continuous delivery: every change that passes the automated tests is automatically deployed to production.

Both continuous delivery and continuous deployment shorten software production cycles. Both are meant to create an environment in which software can be built, tested, and released with greater speed, and at a greater frequency.

Continuous integration (CI) is often a key part of CD. CI is a development practice whereby developers are required to integrate their code into a shared repository multiple times a day. It allows errors to be detected quickly and easily so that less time is spent backtracking to discover where something went wrong and there is more time for building features.

Spinnaker

Netflix publicly released Spinnaker in 2015, making it available on GitHub, at which time they described it as “an open source multi-cloud Continuous Delivery platform for releasing software changes with high velocity and confidence.” Since then, not only has it been tested in production in over millions of deployments, it has also gotten backing from Google and other major software companies (notably, Amazon and Microsoft).

Spinnaker has been making news recently because of the announcement that it is putting a formal governance system in place. Spinnaker will now have both a technical steering committee, and a steering committee. Netflix’s Director of Engineering, Andy Glover, explained the decision, saying, “The project has largely been run by Netflix and Google. We’ve taken any questions from the community and big companies, whether they be Cisco or Target, about trying to figure out ‘What’s the deal here?’ How do we how do we reduce risk, how do we guard ourselves from Netflix closed-sourcing it or Google’s deciding to license it or something like that.” Deployments have not only been tested with Netflix, but 100% of Waze’s production deployments since 2016 have been handled by Spinnaker. As Spinnaker has grown beyond Netflix, in order to scale, putting together a formal governance structure is an important step in that process. The new governance policy is also an important step to getting other developers involved as it outlines how developers can commit code to the project.

Here are some of Spinnaker’s features:

• Multi-Cloud
  • Spinnaker deploys across multiple cloud providers, including AWS EC2, Kubernetes, Google Compute Engine, Google Kubernetes Engine, Google App Engine, Microsoft Azure, and Openstack. It is not currently available on Oracle Bareno Metal and DC/OS, but they are coming soon.
• Automated releases
  • Via Spinnaker, you can create deployment pipelines that run both integration and system tests. You can also spin up and down server groups, as well as monitor your rollouts. To trigger pipeline events, you can do so via git events, Jenkins, Travis CI, Docker, CRON, as well as other Spinnaker pipelines.
• Built-in deployment best practices
  • For faster rollouts, spinnaker allows you to create and deploy immutable images. This also allows for easier rollbacks as well as eliminates hard-to-debug configuration drift issues. By leveraging the immutable infrastructure in the cloud, you have access to built-in deployment strategies, such as red/black and canary deployments
• Demo/Evaluation installs
  • If you want some quickstart solutions, not meant for production use, you can use Amazon Web Services, Google Cloud Launcher, Microsoft Azure, or Kubernetes Helm chart. For a full install, you will need to use Spinnaker’s CLI tool, haylard.
• CI Integrations
  • From Jenkins or Travis CI, you can listen to events, collect artifacts, and trigger pipelines. You can trigger via git or cron, or a new image in a docker registry.
• Integration monitoring
  • You can tie your releases to monitoring services. Supported services are Datadog, Prometheus, or Stackdriver. You can use their metrics for canary analysis.
• CLI for setup and admin
  • Your Spinnaker instance can be installed, configured and updated with Spinnaker’s CLI tool, haylard
• Deployment strategies
  • With built-in deployment strategies, you can configure your pipeline. You can define your own custom strategy, or use built-in strategies such as highlander and red/black, with rolling red/black and canary in active development
• VM Bakery
  • Packer comes packaged with Spinnaker. You can use it to bake immutable VM images. It also offers support for Chef and Puppet templates
• Notifications
  • You can set up event notifications for Slack, HipChat, email or even SMS (which is done via Twilio)
• Role-based access control
  • By hooking into your internal authentication system, you can restrict access to projects or accounts. This can be done using OAuth, SAML, LDAP, X.509 certs, Google groups, Azure groups, or GitHub teams
• Manual judgements
  • Prior to releasing an update, you can require a manual, with a manual judgement stage
• White-listed execution windows
  • In order to ensure that deployments happen during off-peak traffic hours, or to ensure that the right people are available to monitor roll-outs, you can restrict execution of stages to certain windows of time
• Chaos Monkey integration
  • In order to test that an application can survive instance failures, you can terminate them on purpose
• Architecture made from microservices
  • Spinnaker’s architecture is made up of a number of different microservices. Deck provides the browser-based UI; the API gateway is Gate; Orca, which handles ad-hoc operations and pipelines, is the orchestration engine. For a full list of microservices that make up Spinnaker’s architecture, go here.

Jenkins

Jenkins is an “open source automation server which enables developers around the world to reliably build, test, and deploy their software.” At 100,000 installations, Jenkins is the most widely-deployed automation server. Jenkins can be used to automate tasks related to software deployment, whether building, testing, delivering or deploying. Jenkins can run standalone by any machine with Java Runtime Environment (JRE) installed, or it can be installed through native system packages Docker.

Jenkins features include:

• Continuous integration and continuous delivery
  • Since Jenkins is an extensible automation server, there are options. It can be turned into the continuous delivery hub for any project, or it can be used as a simple CI server
• Out-of-the box installation
  • A self-contained, Java-based program, Jenkins is ready to run out-of-the-box. It has packages for Windows, Max OS X, as well as other Unix-like operating systems
• Plugins
  • Jenkins integrates with many tools in the continuous integration and continuous delivery toolchain. Some of their newest plugins are HUAWEICloud Credentials, Quality Clouds Scan, Hashicorp Vault Pipeline, Gradle Repo, and Compuware Topaz Utilities. Part of Jenkins’ advantage is the many plugins it has. Having been built in 2006, there are many integrations built for Jenkins. You can search their database of 1000+ plugins here
• Distributed
  • To drive builds, tests, and deployments faster, Jenkins can distribute work across multiple machines
• Multiple use-cases
  • Jenkins has an extensive list of use cases, such as Android, C/C++, Docker, Embedded, GitHub, Java, PHP, Continuous Delivery, Python and Ruby. An extensive list of plugins is available for each of these use-cases

One of Jenkins’ continuous delivery tools is Blue Ocean. Blue Ocean is a user experience designed for the Jenkins Pipeline. Pipeline is the suite of plug-ins that support integrating continuous delivery pipelines into Jenkins. Blue Ocean allows users to create visualizations of CD pipelines, aiding a better comprehension of a pipeline’s status. Blue Ocean allows people to follow, through a visualization, as a pipeline executes.

Spinnaker vs. Jenkins

Some people use Spinnaker and Jenkins together, since Spinnaker has a native Jenkins API, which delegates compilation and packaging. Originally, Jenkins was not built specifically for continuous delivery, but the Jenkins 2.0 release had an added focus on CD.

Here are some of the key differences between them:

• Spinnaker is not a build tool. It integrates with existing build tools, like Jenkins, to start jobs and monitor progress and results, but it was never intended to be a build tool. It was never intended to fully replace Jenkins at a compilation level. Instead, it can make a deploy phase more flexible
• Because Spinnaker was not intended to be a build tool, there are things that Jenkins will do better, such as managing SCM, running tests, and building packages
• Since Jenkins was not originally built for CD, its CD functionality is more of an afterthought. It was originally built for continuous integration (CI)
• Jenkins was not designed for cloud deployment. External scripts are required
• Spinnaker was built specifically to combine CI and CD for cloud deployments, and Spinnaker has a cloud-centered view. This means that it offers built-in supports for creating load balancers, executing rollbacks, and resizing clusters. It does not need custom code or glue scripts, and offers native support for basic and advanced deployments
• Spinnaker was built as a cloud-agnostic, cohesive package, with all the capabilities of an existing deployment/management tool. This means it has an all-in-one dashboard to monitor compilation, baking, and deployment as well as resource management for multiple cloud environments
• Jenkins has extensive plugin support, so it has a lot of flexibility
• Though Jenkins has extensive plugin support, it can fall short as a complete deployment tool. And, since it wasn’t built with the cloud in mind, this is particularly true of the cloud
• Spinnaker has a richer deployment model
• What Spinnaker does well is takes a piece of software that has been published (whether that is a debian package, a docker image, or a deployable JAR) and runs it through a highly-customized, predictable deployment cycle
• Spinnaker was built to make it easy to do highly-available, multi-account, multi-cloud artifact deployment
• Spinnaker includes a web UI. This web UI can not only provision resources, but it can do it in multiple cloud environments. From the same UI as your delivery tool, you can create basic resources such as VMs, load balancers, and clusters
• Since it was built to manage Netflix’s entire cloud management platform, there is little to no need for sprawled tools to support delivery or infrastructure management
• Spinnaker has no fine-grained access controls
• Jenkins’ plugins and native configurations offer resource-level access control

Spinnaker and Jenkins, however, can work well together. Jenkins is a build tool, and Spinnaker allows for easy deployment. As a use-case, some groups at Netflix use Spinnaker and Jenkins. Part of the reason Spinnaker has the features it does is because Jenkins’ Pipeline functionality was not available to Netflix when they began building Spinnaker. Since they rely on Jenkins for their builds, they created the transition between Jenkins and Spinnaker stages to be seamless. There are teams at Netflix, for example, that do not use the Spinnaker pipeline functionality, and instead, in their Jenkins jobs, use the Spinnaker API. They use this as a shortcut to deploy to AWS. Spinnaker can break down Jenkins jobs into automatic, reusable tasks, and they do this around one application.

Spinnaker is not meant to replace Jenkins. Its goal is to make deploying to the cloud simpler, as well as more extensible. Spinnaker’s new governance policy shows Spinnaker’s commitment to growth, and there has been talk of whether it will land at one of the major open source foundations, such as the OpenStack Foundation, the Linux Foundation, or the Apache Foundation. With Google, Amazon, and Microsoft now backing the project, and with Spinnaker running on their clouds, Spinnaker is poised to grow. While it will never be part of the build of the project, it does aim to make deployment more seamless, and more flexible.