Spinnaker over Jenkins X for Enterprise
It is not uncommon for Jenkins and Spinnaker to be mentioned in the same conversation.
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 like Spinnaker in addition to providing native Kubernetes deployment support created and supported by Google Team, also support multi-cloud deployment strategies using providers such as Amazon AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud and other platforms like Openshift, Pivotal Cloud Foundry, Openstack, DCOS. 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 only target a specific platform are limited to whichever—if any—deployment strategies are supported and do not provide a single pane of glass that most Enterprises that are containerizing workloads need. Spinnaker provides a “golden path, with guardrails” level of standardization across multiple deployent targets and clouds, and visibility into all your cloud infrastructure.
This is when you must identify your needs. Do you need a single pane of glass? Do you need multi-cloud deployments? Do you need sophisticated deployment strategies? Do you want to combine your build and deployment tools? Do you want to empower your engineering with service ownership? Jenkins X and Spinnaker answer these questions differently. Jenkins X is a deployment manager that also doubles as build server (given that it is still Jenkins under the covers). Spinnaker is a multi-cloud deployment manager with support for sophisticated multi-cloud deployment strategies and end-end service ownership, and is not a build server.
Jenkins X: Containerized Deployment Pipelines
Jenkins X primary focus is to extend Jenkins Core to enable automation and management of containerized applications deployed to Kubernetes. Jenkins X has some very strong opinions on the software lifecycle which might not always agree with the processes of your organization. It relies on using Jenkins Master as a pipeline orchestration component and is just Jenkins plus a variety of opensource projects in different state of production readiness (Chartmuseum, Nexus, Mongo, Monocular, etc). The main new addition is the jx executable which is responsible for installing and managing Jenkins X installations. This means that Jenkins X is essentially a superset of plain Jenkins. Of course it adds new deployment abilities to the mix but it also inherits all existing problems of Jenkins. Upgrading and configuring the Jenkins server is still an issue, pipelines are still written in Groovy. jx now takes place in the Jenkins X pipelines, this means that pipelines are now even more complicated as developers must now learn how the jx executable works and how it affects the pipelines it takes part in.
Although the Jenkins team works on the serverless Jenkins, this option does not seem to be a great idea either. Spawning Jenkins machine each time to run a job takes time, as Jenkins itself is pretty heavy. More than that: Jenkins master doesn’t persist the data about the builds in the durable storage. Maintenance on Jenkins master can cause the pipeline to break. While Jenkins-x by design aims to offer Kubernetes native experience, Jenkins itself fail to deliver the Pipeline Centric experience. Pipelines in jenkins rely heavily on stitching together bunch of plugins, which are not very stable and reliable.
Jenkins X is opinionated and requires the organizations to use Helm and and enforces trunk based development. Each pull request is built and deployed to its own, isolated preview environment. Deployments to master are done via pull request to the production configuration repository. There is no single pane of glass user interface at this point in time and such opinionated requirements are not condusive to many enterprise environments that don’t use Helm across the board and have a different Git flow.
Jenkins X is a running system itself, so you will have to set it up and run it somewhere. The JX CLI can install Jenkins X on an existing Kubernetes cluster. 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 software delivery platform by Netflix and Google used n production by some of the largest brands in the world that supports multiple artifact types, cloud providers, and sophisticated deployment strategies. Spinnaker is not a continuous integration tool. Rather, it is designed to coordinate deployments using robust deployment strategies. The following image from Google Team 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 then deploys that immutable image to AWS, Google Cloud, or Kubernetes. Spinnaker supports the canary, red/black (blue/green), 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 does not manage 100% of the infrastructure, but teams can use a native Spinnaker Terraform integration to create VPCs, subnets, etc. and configure pipeline steps accordingly. Spinnaker will manage the rest.
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 Jenkins at the core, integrated with a complex pairing of open-source Kubernetes tools to offer a prescriptive best practice CI/CD pipeline.
Spinnaker is purpose built open-source software delivery platform optimized for enterprise-grade deployments across varying cloud providers, inlcluding native support for Kubernetes, which is created and actively maintained by Google. This information, paired with the size of the community 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 good fit for small teams that are comfortable with Jenkins core. Choosing Jenkins X also means betting on a young project with a very little adoption, uncertain future and comminity backing. 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 very young 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.