It is not uncommon for Jenkins and Spinnaker to be mentioned in the same conversation. However, the conversation became more complicated with the new Jenkins X announcement from about a month ago.
Spinnaker and the new Jenkins X both target DevOps and continuous delivery/deployment with notable differences in their target use cases. This post will help you choose the best fit for your organization by identifying the use cases for each. This starts with a discussion on the process behind deployment pipelines.
Identifying Your Deployment Pipeline Needs
High-performing Engineering teams are deploying more frequently than ever before. This is due to a shift toward DevOps principles and practices, along with a growing niche of high-quality deployment tools. These tools position themselves as continuous deployment tools or deployment pipeline management software. Generally speaking, the software deployment follows this process:
Commit source control
Run a series of tests
Produce an artifact (e.g., a Docker image, virtual machine image, deb/rpm package, etc.)
Deploy the artifact to UAT/staging
Promote the build to production
It is possible to assess tools like Spinnaker, Jenkins X, Heroku Flow, and even GitLab’s Auto Devops according to how much (or how little) they control each step in the process. Tools vary greatly in how they support the last two steps.
Kubernetes has been winning more hearts and minds and has become the standard deployment target for containerized applications. Tools like Jenkins X and GitLab Auto Devops leverage this to target Kubernetes as a deployment platform. This implies that the application is containerized, where the tool may build the Docker image or offload that responsibility to end users.
Other tools support multi-cloud deployment strategies using providers such as Amazon AWS, Microsoft Azure, and Google Cloud Platform, and other platforms like Openshift, DCOS, and even Kubernetes. Deployment strategies are another key differentiator. Deployment strategies like canary, red/black (also known as blue/green), and rolling releases provide more control and stability to teams that are serious about continuous deployment. Tools that target a specific platform, such as Kubernetes, are limited to whichever—if any—deployment strategies are supported.
This is when you must identify your needs. Do you need multi-cloud deployments? Do you need deployment strategies? Do you want to combine your build and deployment tools? Jenkins X and Spinnaker answer these questions differently. Jenkins X is a container-native deployment manager that also doubles as build server (given that it is still Jenkins). Spinnaker is a multi-cloud deployment manager with support for multiple deployment strategies, and is not a build server.
Jenkins X: Containerized Deployment Pipelines
Jenkins X was announced in March of 2018. The primary focuses of this release are automation and management of containerized applications deployed to Kubernetes using Jenkins Core. Jenkins X manages deployment via source control. Each pull request is built and deployed to its own, isolated preview environment. Merges to master are automatically promoted to staging. Jenkins X keeps environment configuration in source control. Deployments to master are done via pull request to the production configuration repository. Jenkins refers to this workflow as "GitOps," but it also supports manual actions via CLI. There is no GUI at this point in time.
Jenkins X is a running system itself, so you will have to set it up and run it somewhere. The JMX CLI can install Jenkins X on an existing Kubernetes cluster. Teams will have to familiarize themselves with Kubernetes and Helm since deployments are actually packaged into Helm charts. It is important to note that Jenkins X does not manage Kubernetes, so teams will have to manage their own clusters or opt for a managed solution like Google Kubernetes Engine, Azure Kubernetes Service, or Amazon Container Service for Kubernetes.
Spinnaker: Cloud-Agnostic Deployment Manager
Spinnaker is a mature and battle-tested solution by Netflix that supports multiple artifact types, cloud providers, and deployment strategies. Spinnaker is not a continuous integration tool. Rather, it is designed to coordinate deployments using robust deployment strategies. The following image from Netflix’s announcement illustrates how Spinnaker fits into deployment pipelines.
The deployment pipeline is usually triggered by the continuous integration system when a new deployable artifact (e.g., a machine image, JAR file, or Docker image) is ready. Spinnaker bakes an immutable image and deploys that image to AWS, Google Cloud, or AWS using a load balancer and an auto-scaling group. Spinnaker supports the canary, red/black, and custom deployment strategies. Promotion between stages is automatic or manual. A "single pane of glass" GUI presents the state of all pipelines so any team member can identify what is running where and the current status.
Spinnaker leans heavily on an immutable infrastructure build with Packer. Each deployment produces a new machine image (e.g., an AMI) that is used for the deployment’s lifetime. Old infrastructure is thrown away at the end of each deployment process.
Spinnaker does not manage 100% of the infrastructure. Teams using AWS will need to create VPCs, subnets, etc. and configure pipeline steps accordingly. Spinnaker will manage the rest. It also does not handle things like service discovery, so configuration such as location of other services and monitoring information must be handled in the bake stage.
Spinnaker is also a running system, so it is up to you to set it up and manage it. Or, you can choose Armory's enterprise-grade managed solution.
Selecting for Best Fit
Spinnaker and Jenkins X have different value propositions. Jenkins X is optimized to provide a seamless process from code to running production using Kubernetes and GitOps. Spinnaker is optimized for enterprise-grade deployments across varying cloud providers. This information alone be may enough for you to decide, but let’s get a bit deeper.
Spinnaker can easily support smaller as well as enterprise teams with support for multiple artifact types and deployment targets. Organizations might prefer Spinnaker as the deployment system. Teams may opt to produce binary packages, Docker images, or JARs and deploy to the desired infrastructure. There are no build system requirements either, but Spinnaker can be triggered via API calls or even Jenkins jobs (which is likely already being used by large organizations). These bundled deployment strategies ensure reliable deployments across low- and internet-scale systems. The unified GUI is invaluable since it provides all relevant data to business, development, and operations personnel.
Jenkins X is a natural fit for small teams that are trying to offload as much deployment and infrastructure concerns as possible while working in a source control-driven workflow. It is likely that these teams are already (or will become) familiar with containers and Kubernetes. Choosing Jenkins X also means betting on a young project with an uncertain future. There will certainly be bugs, missing features, and other rough edges that you will need to resolve on your own.
The choice is clear for enterprise and larger organizations. Spinnaker is mature and battle-tested. Jenkins X is only a month old with a few committers. Spinnaker offers canary deployments, multiple artifact types, immutable infrastructure, and multiple deployment targets—all of which scale to small and large teams. It also offers the "single pane of glass" GUI that is useful to business and technical stakeholders. Given that Spinnaker makes no assumptions about the build systems, organizations are free to integrate Spinnaker with any existing build systems.
Larger and enterprise organizations need not even consider Jenkins X. Jenkins X makes more sense as pilot project in a smaller team or division. Really, it is hard to go wrong with Spinnaker.