Adopting containers is a common strategy for enterprises today to roll out new application changes quickly, deploy efficiently and run applications securely. To achieve those goals, many enterprises are now adopting continuous delivery (CD) in order to deploy changes into production quickly, frequently, and safely.
Many CD tools are used to deliver software to production. Some of the most common tools in the market are:
- Argo CD
- Tekton CD
- Git Lab
- Azure DevOps
Spinnaker and Argo CD are favorite tools for transforming software delivery processes, and so we are often asked to describe the difference between Argo and Spinnaker and to assess which one is better. The short answer has been “it depends” on the specific situation and requirements for each customer. But that’s not a satisfying answer, so let’s dig deeper into when Spinnaker and Argo make sense.
A quick introduction to Spinnaker and Argo CD
What is Spinnaker
Spinnaker is an open-source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence.
Spinnaker offers a powerful and flexible pipeline management system which is used by many Fortune 500 companies to deploy millions of changes per year. Read more on What is Spinnaker
Refer the Spinnaker UI:
What is Argo CD
ArgoCD is a declarative continuous delivery tool for Kubernetes applications that uses GitOps style to manage cluster resources. Argo CD monitors application configuration defined in your Git repository and compares it with the live state in the cluster. When a developer makes a change to the app definition in Git, Argo CD detects and notifies administrators about the out of sync status. If the administrator approves the change, ArgoCD creates resources in Kubernetes clusters with the newly defined configuration. Refer the Argo CD UI:
Spinnaker has been in the market since 2017 and so it has a large and active community (with almost 1,68,000 contributions to date); Argo CD is newer to the continuous delivery market, with version 1.0 being released in May 2019.
Argo CD vs Spinnaker
We have separated our evaluation of Argo and Spinnaker along four dimensions: installation and implementation, deployments, complex workflows and safety
Installation and Implementation
One of the top parameters that any enterprise visualizes is Day1 operation, which includes prerequisites, installation, configuration, and architecture.
Argo CD is very lightweight and can be installed in minikube or micro k8s ( with 2GB memory and 2 CPUs), whereas Spinnaker is feature-rich which makes it pretty heavy. Installation of Halyard- lifecycle manager for Spinnaker- takes at least 12 GB of memory (though it can be run in 1 GB for small setup). Besides, Spinnaker needs a K8s cluster with four cores and 16GB of RAM.
From an installation perspective, both Spinnaker and Argo CD are well documented and easily installed with a few commands and in a few minutes. Both CD tools offer fault-tolerant, highly available architecture to minimize service disruption during software deployment.
One of the significant differences between the two-CD solutions is deployment models. Spinnaker offers both on-prem and Spinnaker SaaS versions, while Argo offers on-prem installation only.
Learning curve and enterprise-wide adoption
Another factor that certainly helps enterprises scale the adoption of a CD solution is the learning curve involved in understanding the product. Spinnaker offers many resources, documentation, videos, and enterprise Spinnaker plugins, which help the DevOps team learn and adopt it very quickly in production. The amount of training information on Argo CD is much more limited.
If an organization wants to deploy a lightweight CD solution, Argo CD can be a good choice. If an organization wants to have a centralized and production-ready CD solution that is able to handle a wide variety of application types and deployment targets, or if scale and speed are especially important, Spinnaker qualifies best.
Spinnaker Deployments vs Argo CD Deployments
Argo CD treats Git as source of truth and monitors the repository for any changes in manifest file for app deployment in Kubernetes. Manifest can be specified in a text file or JSON file, or Kustomize applications, or helm charts, or ksonnet applications, or jsonnet files.
Argo CD is meant to be used with Kubernetes applications and services only. Argo CD tracks updates to branches, tags, or pinned to a specific version of manifests at a Git commit and deploys the changes into Kubernetes. Kubernetes manifests from a Git repository are applied to your Kubernetes cluster, and Argo will strive to ensure that your repository and clusters are always in sync. Please refer to the below architecture which highlights how the Argo CD deploys changes into K8S clusters.
Argo CD has a basic UI to showcase the deployment status of a change (and depends on sync with Git change). Argo also does not provide detailed visibility into the status of a deployment or into metrics across deployments or across pipelines.
Spinnaker, runs a little differently. It offers both declarative and imperative pipeline delivery models. DevOps engineers who are familiar with public cloud, and Spinnaker will choose to deploy using pipelines by creating stages. It deploys apps into multiple cloud environments like AWS, GCP, Azure, Kubernetes, VM. Spinnaker offers VM Bakery to bake immutable VM images via Packer, which comes packaged with Spinnaker and offers support for Chef and Puppet templates.
Developers who want to use declarative or GitOps methodology can define their infrastructure changes in YAML files and trigger a Spinnaker pipeline on any commit to the document in Git. Spinnaker API can be called to create and manage infrastructure (security groups, load balancers, firewalls) and process deployments. Manifest files can be specified in text file or JSON file, or Kustomize applications, or HELM charts or Spring Spel templates, and Spinnaker pipelines can be triggered to read the file changes and automate the deployment based on the desired states in the specified target. Application deployment tracks updates to branches, tags, or pinned to a specific version of manifests at a Git commit.
One feature that Spinnaker currently does not support for Kubernetes is the capability to re-issue the Git state to the target environment if something in the target changes and is therefore out of sync with the Git master.
Spinnaker can be used to construct an end-to-end delivery workflow in your organization. Various webhooks can be configured in Spinnaker pipelines to trigger Jenkins build jobs, deploy into test environments, trigger automated test cases and deploy into staging and production environments. Manual judgment and verification gates can also be configured as a part of the same pipeline to ensure an automated and risk-free release process.
Below figures- Fig A represents the orchestration of an enterprise software delivery process using Spinnaker, and Fig B represents a sample Spinnaker pipeline automating various delivery stages- build, test, deploy and prod:
For safe deployment, Spinnaker offers in-built deployment strategies like highlander, blue-green, rolling updates, and canary deployment. However, in Argo CD one has to install another product of Argo project called Argo Rollouts to strategically deploy.
Both tools support on-prem and manageed Kubernetes. Argo CD and Spinnaker support application deployment into the managed K8s (EKS/GKE/AKS). The former deploys directly based on the configuration change, whereas the latter uses delivery pipeline for deployment.
If you have a few applications hosted on on-prem or managed K8s, and are still undergoing some cloud transformation, then Argo CD can be well suited for you. However, if you want to construct a seamless workflow to automate a delivery process that includes test integration, approval gates (manual or automatic), integrated image builds and visibility into deployments to hybrid or multicloud environment, then choose Spinnaker for continuous delivery.
Scaling Enterprise-Wide with Complex workflows
VM based deployments
Every enterprise deploys applications to VMs – either to the cloud – GCP, AWS, or a different cloud – or to an on-prem datacenter VMs. It is standard practice to create a specification for the environment that is required for an application – the OS version, binaries, storage, networking, libraries, applications, compressed files, etc to create a VM. This is also called VM bakery, where the infrastructure team makes a snapshot of the overall environment and persists it in something like an AMI store. And once that image is ready, creating multiple images – even up to tens of thousands of images – can be created to match the requirements of the application. The process is also known as Immutable infrastructure, and it is practiced to avoid configuration drift.
Like Spinnaker uses HELM charts to bake K8s manifest files, Spinnaker uses a packer template (under the hood) to bake VM images. Once a delivery pipeline is completed, Spinnaker can provision those VMs (along with load balancers, firewalls, etc) in the target environment (from the cloud to on-prem VMs to bare metal servers). This helps infrastructure teams to leverage Spinnaker to orchestrate VM based deployments. This ability to deploy updates to K8s services and VM-based applications is one of the important reasons that many organizations choose to standardize on Spinnaker for software deployments.
In addition to that, Spinnaker provides a single pane of glass from where you can see and control your resources. Developer and operation teams don’t need to log into a different UI or public cloud to understand the status of resources.
Argo CD does not provision infrastructure like Spinnaker. One has to use external open source software like Crossplane to be able to assemble and manage infrastructure of any public cloud.
Stability and Performance
When it comes to handling multiple application deployments and scaling a CD solution enterprise-wide, Argo CD has some known performance issues. For example, according to the Argo documentation in their roadmap section , Argo becomes very slow when it has to handle more than 1000 kubernetes applications.
Further, to handle more than 100 Kubernetes clusters, you must increase the number of replicas of Arogo CD controllers (i.e. scale horizontally) and configure Argo for automated sharding (to distribute the workload among all the Argo CD controllers).
Similarly, Argo CD has issues (specifically, it may not be able to generate manifests properly) when configured to handle 50+ applications in a single repository.
Moreover, Argo CD releases only metrics (both counter and gauge type) for Prometheus to measure performance issues of the Argo CD system itself. Of course this is challenging for enterprises who have chosen to use any of the monitoring systems other than Prometheus (like Datadog, NewRelic, Dynatrace, and many others).
On the other hand, Spinnaker is known to handle scale and complicated software delivery workflows. Read how Cisco uses Spinnaker to handle more than 1000applications for nearly 2000 developers, performing 10,000 deployments per year.
Spinnaker exposes metrics (both counter and gauge type) through the Spinnaker-monitoring daemon. Although Spinnaker supports Datadog, Prometheus, and Google Stackdriver, the daemon is quite extensible and can be integrated with any monitoring solutions in your premise.
Feedback and notifications are an essential part of the CI/CD process. Any CD tool needs to have extensive coverage of the wide variety of tools used to communicate in a DevOps setting.
Argo CD provides notifications through Email, GitHub, Slack, Mattermost, OpsGenie, Telegram, and Microsoft Teams.To enable notifications, one has to install Argo Notification. Argo Notification currently does not work with other products like Argo Rollout (which provides different options for deployment strategies).
Spinnaker supports notifications through email and provides integrations with many collaboration and service management tools such as Slack, ServiceNow, JIRA, Twilio, PagerDuty, Microsoft Teams, and others.
Argo CD enables administrators to approve a deployment immediately after a change in Git has been recognized. Manual judgement steps at various stages in the software delivery requires substantial configuration and scripting in Argo CD.
Spinnaker enables administrators to easily approve the promotion of an update at any stage in the overall process, typically before integration testing, staging, and production. OpsMx Enterprise for Spinnaker (OES) takes this step further and allows the project or release managers to take informed approvals, by providing 360-degree information about build, test, tickets status, etc(refer the below image). Release managers can now make quick and informed decisions to progress a pipeline. Deployments done via a Spinnaker pipeline are more safer as there is more visibility on the various stages involved and data-driven approvals to confidently approve a deployment to production.
Argo CD provides only community-based support, so there is no SLA. The community is new and the existing support database lacks extensive articles. For Argo CD support, you can visit here:
Spinnaker has multiple options for support. There are many blogs, videos, and technical articles. One example is OpsMx, who provides “no-excuses” support on a 24×7 basis. There is an active slack channel where Spinnaker users post and answer questions. OpsMx offers OpsMx Enterprise for Spinnaker (OES), that makes Spinnaker even more simple, scalable, secure and intelligent.
There is also an annual user conference called Spinnaker Summit that has a wide variety of courses – for experts and beginners. There is also a very large group of people with expertise on Spinnaker and an even larger number of users who are familiar with its usage. Finding people who are knowledgeable about Spinnaker is not typically an issue.
Enterprises are adopting new DevSecOps culture that aims to enforce security into the CI/CD pipelines. This shift-left mentality requires organizations to consider requirements from security teams like proper authentication, authorization, secure connections, and many others.
Argo CD has undergone security reviews and penetration testing and removed all vulnerabilities from the product itself.
Argo CD provides authentication through JSON Web token and authorization through RBAC policies. The communication among different services (argoCD-server, argocd-repo-server, argoCD-application-controller) is secured through TLS. Argo CD also provides secret management by storing credentials of external clusters in Kubernetes secrets. Argo CD is un-opinionated on how to manage secrets.
Spinnaker offers high-security standards for enterprises to prohibit any internal or external threats. It supports various protocols like RBAC, LDAP, OAuth, and MFA for proper authorization and authentication. With support for mTLS and X.509 certificate-based communication, Spinnaker is considered one of the most secure CD tools available. Furthermore, Spinnaker directly discourages you from storing secrets, tokens, passwords, and similar sensitive information in plain text and instead offers integration with Git, S3, and Vault to keep such information.
Policy and Compliance
Argo CD does not provide any support for policy checks during software deployment.
Spinnaker provides automated policy enforcement. Spinnaker integrates with OPA (Open Policy Agent), a standard for specifying policies, so that policy managers can easily define Spinnaker policies using declarative language and enforce policies in pipelines. This helps organizations ensure 100% adherence to industry standards like HIPAA, GDPR, SOX, and to internal best practices.
Both Argo CD and Spinnaker offer auditing capabilities.
Argo CD depends on external tools like Event Exporter, Event Router, or ElasticSearch to get events about application activity or audit logs. This means the DevOps team needs to interact with the Kubernetes cluster outside ArgoCD and needs some configuration to fetch audit logs and extra effort to troubleshoot.
Spinnaker has a mechanism to store log information about pipeline runs and deployments. With Spinnaker, auditors can easily investigate all activities regarding deployments.
Organizations that are mature in DevOps frequently seek to minimize the risk of new releases in production by properly assessing quality and performance for every change. This is called continuous verification.
Argo CDs don’t offer any mechanism to fetch logs or metrics data from external sources, or to provide you with information that helps you make go/no-go decisions for deployment. OpsMx Enterprise for Spinnaker (OES) allows verification of new releases in various stages of delivery. Many customers configure verification gates in OES to perform automated risk assessment and roll forward or rollback their releases in production.
Tabular Comparison: Spinnaker vs Argo CD
This comparison evaluates Argo CD and Spinnaker along four broad dimensions that enterprises usually consider before deploying a CD platform. In some cases, the tools are roughly equivalent in features, but there are few dimensions where Spinnaker is better over Argo CD and is an obvious choice.
Argo CD and Spinnaker are designed for different purposes. Argo is primarily intended for an individual or a small group of developers who are deploying apps into K8s only. In this task, it is fairly lightweight and easy to use. Spinnaker is designed as an enterprise platform that can handle all types of applications and deploy to many different targets. It can be easy to use in a simple case, and is very flexible and extensible for complex and less common cases. This has led Spinnaker to be the system-of-choice for most organizations that are transforming their software delivery to use continuous deployment across the board.