An alternative to the open-source project Spinnaker is Harness. This blog compares key differences between each CD solution.
Updated: July 30th 2018
Spinnaker and Harness are two names that come up frequently when talking about Continuous Delivery.
Truth is, competition and choice is a great thing for customers. It’s also a good thing for vendors too – competition is validation and it always fuels innovation.
Normally a customer would have 5 or 6 vendors to compare with for any given market, but the reality is that not many options exist for Continuous Delivery (CD) right now.
With CD, customers have just three options:
- Build it yourself using scripts and an orchestration tool like Jenkins
- Build and contribute to the open-source project Spinnaker
- Buy CD As-A-Service from Harness
Spinnaker and Harness Origins
Spinnaker was a result of Netflix building their own Continuous Delivery platform back in 2015 (they use Jenkins for Continuous Integration). Netflix open-sourced parts of their CD platform under the Spinnaker alias in November 2015, and Spinnaker 1.0 was officially released on June 6th, 2017.
Harness was founded in 2016 by two gentlemen, Rishi Singh and Jyoti Bansal (former founder & CEO of AppDynamics). Rishi built out Apple’s Continuous Delivery Platform back in 2012 and partnered with Jyoti who identified Continuous Delivery as a massive challenge for his customers while he ran AppDynamics. Harness came out of stealth in October 2017 and is now GA.
CD as-a-Framework vs. CD as-a-Service
The first key difference between Spinnaker and Harness is their deployment models. Spinnaker is a download that you host, configure, run and manage yourself. Harness provides CD as-a-service through its SaaS platform AND as on-premises software for private clouds/data centers. We did that because enterprises these days require both deployment options.
The Spinnaker architecture consists of 10 distinct microservices, whereas Harness is abstracted to just 3 microservices (Automation, Verification & Platform). Both solutions are horizontally scalable.
While Spinnaker gives you complete control of your CD platform (build, configure, manage, support, fix, upgrade), Harnesses manages a lot of that deployment complexity for you. That’s why we call it CD as-a-Service.
Think of Spinnaker as a sailing boat you own, and Harness as a Jetski you rent. Both let you get from A to B, but in different ways.
User Experience, Analytics & Reporting
The second key difference you’ll notice between solutions is around user experience.
Spinnaker is a functionally rich user interface with access to a lot of deployment options, configuration, and controls.
Harness in comparison is less complex, with a more visual and intuitive perspective on CD – both solutions achieve CD very differently. Harness provides more high-level analytics, reporting, and visibility across deployment pipelines.
Here are a few screenshots to make your own mind up:
Platform Support & Integrations
Another difference is that Spinnaker is 100% aimed at the Cloud native, whereas Harness supports both traditional and cloud-native apps. Once again, we did this because we learned from enterprises that support for both types of architectures is important (not everything is in the cloud). With Harness its possible to have hybrid clouds and services residing in the same environment that run on totally different compute.
Spinnaker was originally designed to support multi-cloud architectures (to avoid vendor lock-in) and has a slight advantage over Harness in this regard. Spinnaker today supports AWS, Azure, GCP, and OpenStack. Harness in comparison supports AWS, Azure, GCP, PCF and bare metal, with OpenStack coming later this year.
As you would expect, both platforms have native support for Docker and Kubernetes. However, one surprise is that Spinnaker does not yet support AWS Lambda serverless. Harness released Lambda support back in November 2017; check out the blog here. One of our customers requested Lambda support during our early adopter program, and three weeks later it was shipped. Not bad for a vendor 🙂
While Spinnaker has a pluggable architecture, the number of supported integrations is quite low. Here’s a quick comparison:
|Cloud Providers||AWS, Azure, GCP, OpenStack||AWS, Azure, GCP, PCF, Bare Metal|
|Container Orchestration||Docker, Kubernetes||Docker, AWS ECS, Kubernetes, Helm|
|Artifact Repositories||GCS, GitHub, GCR, DockerHub||GCR, ECR, Nexus, Artifactory,
DockerHub, S3, Jenkins,
|Continuous Integration||Jenkins, Travis CI||Jenkins, Atlassian Bamboo,
Travis CI, CircleCI
|Monitoring CD KPIs||Datadog, Prometheus, Stackdriver||Custom API|
|Continuous Verification||HTTP Endpoint||APM: AppDynamics, New Relic,
Dynatrace, Datadog, Prometheus,
Log: Splunk, Sumo Logic,
ELK, Logz.io, Scalyr
Custom: HTTP Endpoint,
Jenkins Job, Shell Script
|Secrets Management||-||AWS KMS, Hashicorp Vault|
Spinnaker has extensible APIs to build around but that does require effort on the customers’ behalf to plug gaps and contribute.
Continuous Delivery Concepts & Capabilities
As you might expect, Spinnaker and Harness share common capabilities with minor terminology differences. Both have been architected ground up to abstract over any underlying cloud provider or technology stack complexity so you can build deployment pipelines using a common set of templates and features.
Here is how Spinnakers’ capabilities and terminology compares with Harness:
|Deployment Strategy||Deployment Type|
|-||Barrier (Flow Control)|
Spinnaker visualization of a pipeline:
Harness visualization of a pipeline:
Currently, Spinnaker does not support declarative pipelines or configuration-as-code.
Harness provides full support for declarative pipelines via YAML and thru Git sync for version-control. This means operators have bi-directional sync between harness YAML and our UI.
Both Spinnaker and Harness provide out-of-the-box for deployment strategies like Blue/Green (Red/Black), Canary, and Rolling deployments. You can also choose and define a custom deployment strategy in both products.
Deployment Verification & Health Checks
The most noticeable difference between solutions is the use of machine learning by Harness to verify deployments (we call this continuous verification). Harness basically connects to all your existing monitoring (AppDynamics, New Relic, Dynatrace) and log tools (Splunk, ELK, Sumo), then applies unsupervised algorithms to automate the analysis of time-series metrics and unstructured events to understand whether your app/service is behaving normally post-deployment.
For example, below is a screenshot showing how Harness can baseline and identify new error regressions in your application logs:
This is somewhat different to Spinnaker that allows basic HTTP health checks to be defined manually by the operator and using the likes of Datadog, Prometheus, and Stackdriver to poll the metrics inside the Spinnaker run-time.
One of the Server Group actions in Spinnaker is “Rollback,” which allows operators to manually select a server group version to roll back to. As previously mentioned, Spinnaker also supports a red/black deployment strategy which is also helpful for enabling rollback.
Harness has a concept called “failure strategy” where operators can define (and automate) what action needs to be taken when continuous verification (ML analysis) or deployments fail. By default, Harness will automatically roll back the application/service/artifact to the last working version in addition to any run-time configuration, both of which are version controlled by Harness. For example, read how Build.com performs production roll backs in 32 seconds.
Microservices Deployment Flow Control & Impact Analysis
Lets suppose you want to deploy many microservices at the same time in parallel, and then control their flow so that all dependencies are verified at the same time once all deployments are complete.
At the moment Spinnaker offers minimal capabilities to address this use case. Harness shipped two features in Q1 2018 which several customers requested called Microservices Flow Control and Service Impact Analysis.
Test Automation & Chaos Monkeys
Both Spinnaker and Harness provide native integration points for Jenkins, 3rd party REST calls, and shells scripts. It’s therefore relatively easy to reference and trigger existing test automation scripts or tools as part of your deployment stages and pipelines.
Chaos Monkey can also be used with Spinnaker once configured.
Both Spinnaker and Harness have support for role-based access control (RBAC) thru APIs like LDAP/SAML/etc.
A few Spinnaker customers (e.g. Intuit) are in the process of building their own audit trails on top of Spinnaker to satisfy internal security compliance. Audit trails are a standard feature of Harness, as is secrets management.
Harness provides native integration with both Amazon KMS and Hashicorp Vault to manage secrets across your deployment pipelines. This was a popular request from our customers, and it allows them to streamline access to cloud providers, environment, and tools across teams and application groups. Harness also provides usage and change logs into when secrets are accessed and used by deployment pipelines.
Spinnaker relies on its open-source community; Harness relies on a 24/7 dedicated customer success team (and 25+ engineers).
Depending on your organization’s preference, this means the level of support, education, training, documentation, and bug-fixing will vary between Spinnaker and Harness (just like any other open-source vs. commercial vendor discussion).
Ultimately, it’s about trade-offs. What is really important your team and organization? Some teams love to be part of a community that builds things, while others simply want to outsource tools so that they can focus on their core business. It’s also not uncommon for an enterprise to invest in both solutions to mitigate risk and lock-in.
Total Cost of Ownership
Open-Source vs. Commerical isn’t always a black and white “Free vs. No Free” discussion.
Open-Source may well be free to download and use, but it often isn’t free to build, extend, manage and support over time.
Some things to consider:
- Required people to install, configure, manage and support the solution?
- The time required to build a deployment pipeline?
- Size/cost of the infrastructure and storage to operate the solution?
- Capabilities provided by each solution, what is missing and requires investment/building?
- Time-to-value for each solution? Is it hours, days, weeks or months?
- What is the skill set required to use each solution? What is the learning curve?
The easiest way to understand TCO is to evaluate each solution and understand the real resource/time each takes to implement, manage and get value from. For example, if you have 3 people dedicated to implementing & managing a solution in your organization, that’s $600k of annual cost.
Spinnaker is no different to any other open-source project. You download it, configure it, build it, fix it, deploy it, manage it, and support it. Yes, a community exists to help you but there are no guarantees.
Harness, on the other hand, has tried to package CD as-a-Service so that a lot of the deployment and management complexity is avoided by end users (developers and operators). You can sign up for a trial here to give it a shot. We have several customers who were up and running in hours building their own pipelines.
On a final note, both Spinnaker and Harness are very much needed in the marketplace. They provide customers with options and choice, something which hasn’t existed before. Think of them both as a cups of iced water in deployment scripting hell.