Choosing a Continous Delivery Tool: Argo CD vs Spinnaker

Samuel Rowe
Tech @ Trell
Published in
7 min readDec 15, 2021

--

Kubernetes is not a solution for everything in an enterprise’s workflow. For example, continuous integration is beyond the scope of Kubernetes. So Kubernetes needs to be integrated with tools like Jenkins, Travis CI, GitHub Actions, and so on for continuous integration. The same applies to other use cases that are beyond container orchestration, which is what Kubernetes is designed for.

At Trell, we deal with millions of requests every day. We have adopted Kubernetes to help us scale. Kubernetes solves our scaling problems really well.

Given my role at Trell as a full-stack developer, I have been using Kubernetes a lot lately. I am simply mesmerized by the level of engineering behind this amazing tool. The design choices behind Kubernetes’ APIs are nothing short of brilliance!

In this article (or possibly a series), I talk about my experience at Trell integrating Kubernetes with a continuous delivery platform.

Currently, our workflow is pretty straightforward. We create a new feature branch, make changes to the codebase, create a merge request, get it reviewed, and then merge it to the staging branch. At this point, our GitLab CI /CD pipeline kicks in and deploys the changes to our staging environment.

Once the tests are completed and the team is confident with the new changes, we merge the staging changes to the master branch. Our GitLab CI/CD pipeline then deploys the changes to our production environment.

This workflow has worked out well for us so far. If a bug surfaces in production, we quickly revert the new changes and the entire workflow restarts. Since we deploy the new changes to all the pods, bugs impact all our users.

Like all the other teams at Trell, the engineering team, too, is determined to provide the best experience for our users. This means, all our users experiencing a nasty bug is something that we cannot compromise on. I’m currently part of the team whose efforts are focused on mitigating this.

So how do we plan to reduce the number of users that are affected? The idea is to implement a canary deployment strategy.

What is Canary Deployment?

Canary deployment is a deployment pattern where we roll out new features to a small portion of our users. If there are production bugs, only a small portion is affected, instead of the entire user base.

Canary deployment in action

For implementing a canary deployment, we need a continuous delivery platform with interactive capabilities. By which I mean, a dashboard that allows an administrator to manually approve a deployment.

There are a few continuous delivery tools out there that provide this. Based on our requirements and architecture, we shortlisted Spinnaker and Argo CD.

Here’s a brief list of common continuous delivery tools in the market:

  • Spinnaker
  • Argo CD
  • Tekton CD
  • GitLab
  • Azure DevOps

Most articles on Spinnaker vs Argo CD are agnostic and give you a generic answer saying “it depends”. In this article, however, you’ll see the factors that we considered, the evaluation of these factors along with relevant reasoning, and the choice that we finally made.

1. Understanding the tools

Before we continue with the differences, let’s first understand Spinnaker and Argo CD.

What is Argo CD?

Argo CD is an open-source continuous delivery platform developed at Intuit. According to their official blog, Argo CD is designed for fast and reliable continuous delivery with Git as the source of truth.

Practices that allow engineers to manage infrastructure and application configurations using Git are commonly known as GitOps. Personally, I prefer this paradigm because it allows you to reproduce environments via your commit history.

Like Kubernetes, Argo CD is also declarative. What I mean by this is, you specify the desired state for your application; you don’t specify how to reach the desired state. Argo CD achieves this by monitoring the configuration in your Git repository and comparing it with the current state of your cluster.

When a developer makes changes to the repository, Argo CD detects the changes and concludes that the cluster is out of sync and notifies the administrators. When the administrator approves the changes, Argo CD reconciles with the desired state by manipulating the relevant Kubernetes resources.

Argo CD dashboard, as shown in the documentation.

What is Spinnaker?

Spinnaker is an open-source continuous delivery platform developed at Netflix. According to their official website, Spinnaker is designed with high velocity and confidence in mind.

In DevOps, velocity refers to speed and direction for faster deployments, more deployments, faster repair times, and more successful deployments.

Spinnaker was originally designed to deploy applications imperatively. Newer releases of Spinnaker also offer a declarative paradigm that fits well with GitOps.

The Spinnaker dashboard, as shown in the documentation.

2. Community, Popularity, and Development Status

When it comes to choosing open-source software, community and popularity are important factors to consider. The community plays an important role in shaping and improving the software. Without good participation and contribution from the community, the project is bound to suffer from stale issues and discontinuation.

Spinnaker was initially released on November 16th, 2015. As of this writing, it has been five years since then. Spinnaker has 8.2k stars and 1.1k active forks on GitHub. The latest release v2.2.0 was made on 19th December 2017! Other than a few minor changes, for the most part, development seems to have slowed down significantly.

Screenshot from Spinnaker’s GitHub repository

Argo CD was initially released on October 13th, 2018. As of this writing, it has been three years since then. Argo CD has 7.8k stars and 1.9k active forks on GitHub. The latest release v2.2.0 was made just 17 hours ago!

Screenshot from Argo CD’s GitHub repository

Despite being late to the party, Argo CD clearly has an edge over Spinnaker in terms of community, popularity, and development status.

3. Installation, Usage, and Resource Consumption

Argo CD is lightweight. It is implemented as a Kubernetes controller which monitors, compares the desired state with the current state, and syncs whenever there’s a deviation. You can install it on any functional Kubernetes cluster, including Minikube, in less than 30 minutes.

Spinnaker is heavyweight and resource-intensive. Its microservices can be deployed on both a Kubernetes cluster and a single machine. Although it’s not required, Spinnaker recommends using their command-line tool Halyard for managing the lifecycle of the Spinnaker deployment.

Unfortunately, I was not able to run Spinnaker locally after spending a whole day. It took me another day to deploy Spinnaker on our Kubernetes without using Helm. Personally, I found the learning curve for Spinnaker a bit steep. On the other hand, I was able to run Argo CD and deploy an application in less than 30 minutes!

Spinnaker definitely covers a lot of use cases that Argo CD does not, which explains the complexity. However, at this point in our journey, as an enterprise, we need a continuous delivery solution with simple prerequisites, installation, configuration, and architecture. So another point goes for Argo CD.

4. Security

As an organization grows, it is important to ensure that employees have limited access to resources. An employee must be given access to only those resources that are required to complete their job. Therefore, authentication, authorization, and other security factors provided by the software need to be scrutinized before integrating.

Authentication, Authorization, and TLS in Argo CD

  • Argo CD implements authentication using JSON Web Tokens (JWTs) for both Single Sign-On (SSO) via OAuth 2.0 and username/password.
  • Authorization is performed using Role-Based Access Control (RBAC) policies specified in YAML configuration files.
  • All network communication is performed using Transport Layer Security (TLS), including service-to-service communication.

Authentication, Authorization, and TLS in Spinnaker

  • Spinnaker implements multiple authentication methods which include OAuth 2.0 / OIDC, SAML, LDAP, and X.509.
  • Spinnaker implements multiple authorization methods which include YAML file-based configuration, GitHub Teams, Google Groups, LDAP, and SAML Groups.
  • All network communication is performed using Secure Sockets Layer (SSL).

Clearly, Spinnaker offers more methods to secure an enterprise’s continuous delivery platform.

At Trell, we intend to secure our continuous delivery platform by using Google OAuth 2.0 for authentication and RBAC authorization using YAML configuration files. This means both Spinnaker and Argo CD suffice our requirements.

Conclusion

Both Spinnaker and Argo CD are powerful platforms for continuous delivery backed by industry giants. They have been battle-tested and are used by many organizations at scale.

Spinnaker and Argo CD were developed for different purposes. Argo CD is designed for small groups of developers who are deploying applications to Kubernetes. On the other hand, Spinnaker is designed for large enterprises with heterogenous targets, that is, containers and virtual machines.

Although Spinnaker is much more powerful than Argo CD, we have decided to move forward with Argo CD, for the reasons mentioned above.

Thank you for reading this article. I hope you enjoyed reading this article as much as I enjoyed writing it. I hope to see you again soon.

--

--

Samuel Rowe
Tech @ Trell

With software development, there is always something new to discover. Designing a platform that is helpful to millions of users is my ultimate goal.