Why and when do you need Argo CD?

We have a free Lightning Course about Argo CD. It covers the main components of this tool, as well as how to use them to deploy your applications. But, before you learn how to use this tool, it helps to understand whether you need it at all, unless you want to learn it just for fun, nothing wrong with that. As we see many companies trying to adopt Cloud Native tools without much consideration of whether it makes sense beyond satisfying the internal urge to try new things and extend one’s CV (nothing wrong about both desires either), let me try to provide some guidelines that will help you to assess if Argo CD makes sense for your setup or not. And if not, then when will it start making sense. Note that for the most of the article you can find and replace “Argo CD” with “Flux CD” or “Rancher Fleet”, and everything will still apply as-is.

Criteria #1: Whether you use Kubernetes and how much you use it

It’s worth starting with the fact, that Argo CD makes no sense outside the Kubernetes world. It’s a tool that needs Kubernetes to run, and it’s a tool that only works with applications running on Kubernetes. Argo CD is not a generic job execution system like GitHub Actions, Jenkins, or any other CI/CD tools you might be used to.

You might need Argo CD if you run your applications on Kubernetes, but it depends on how exactly you are using Kubernetes. Consider the following:

Are all of your applications running on Kubernetes, or only a subset of them?

Let’s say you're using AWS, and you have a mix of AWS Lambda, AWS ECS, or App Runner, as well as EC2-based workloads (welcome to the future, by the way), with only a subset of those applications running on Kubernetes, then introducing Argo CD only for those applications might be wasteful. In other words, if you only have a Proof of Concept or just a couple of less important services running as pods, then it’s likely that rolling out a separate deployment tool won’t be beneficial for the company.

Do you use Kubernetes as a foundation of your platform, or as a simple container runtime?

There are two ways to look at Kubernetes. You can look at it as a powerful framework for building your own infrastructure abstractions and your own internal platform, and you can look at it as a simple way to run your containerized applications (there is nothing simple in it).

In the first case, your clusters are way more complex, and you have multiple clusters. They probably have a number of operators running, to cover monitoring, logging, networking, security, secrets management, and whatnot. And all of this with at least a namespace-based multi-tenancy, with correct RBAC, SSO, and so on.

In the second case, you just use it to run containers and expose them to the world with Ingress or Gateway API. You probably have just a couple of applications, mostly the same people working on them, without a complex internal hierarchy of teams and projects.

You need a tool like Argo CD in the first case. Once you start building something resembling a Kubernetes-based platform, properly managing all the software running on multiple clusters becomes tedious. Argo CD helps to bring all of your clusters together, in a single management interface, with alerts, automatic synchronization, image updates, and all the other features that make Argo CD great.

Just as an example, imagine you want to run Prometheus in 10 different Kubernetes clusters. You want to configure it to run smoothly, probably with Thanos, some storage, and some configuration to make it easy for application developers to collect and query metrics via Grafana. That’s a lot of Kubernetes objects running in each of your clusters, and you need to perform regular updates to each of them, as well as extend with new capabilities. Now consider that each cluster probably also has some Ingress Controller, some secrets management solution, and many other things, each multiplied by 10, split across multiple stages. That’s when you want Argo CD by your side.

You don’t need it by your side if you don’t have such a setup. If you only run a handful of applications, split across “dev”, “stage”, and “prod” clusters, then there are easier ways to manage these clusters, especially if you stop thinking about Kubernetes as a container orchestrator and embrace the serverless flavor of it.

Do you have enough people with deep knowledge of Kubernetes?

It’s not uncommon for companies, especially smaller ones, to use Kubernetes without having experienced people to manage it. We’ve seen many cases where only a couple of developers were trying to keep the cluster running while combining this with their primary task of working on application code. Learning Argo CD, as well as rolling it out and maintaining it, assumes that you have colleagues who understand how Kubernetes works, and who has time to do this job.

If you do end up in a situation where Kubernetes is there, but there aren't enough hands or skills to manage and extend it, then schedule a call with us. We specialize in supporting companies with cloud-native technologies, and we’ll either bring your K8s back into shape or find a way to free you from it.

Criteria #1 Summary

Note that at this point, I am not even suggesting using Argo CD for deploying your actual applications. For now, we figured that it’s a good addition to your toolchain in case if:

1. You're building a Kubernetes-based platform that’s going to run lots of various workloads for many different teams;

2. You have many clusters with many cluster operators and components running on them;

3. You have a team of people who are good with Kubernetes and have time to learn, implement and maintain Argo CD.

Whether you need Argo CD to deploy the applications that your customers really care about, we need to move to the next criteria.

Criteria #2: How your current CI/CD is done

In the majority of cases, when you are in a position of considering Argo CD, you probably already have some applications running. In the rare case when you don’t have an actual product that serves some customers, and you are thinking about GitOps tool for your Kubernetes clusters before shipping some code: just stop.

If you already have some applications running, then they were deployed somehow. Thus, let’s explore things to consider in this case.

Do you already have some proper CI/CD pipelines?

You can't jump from manually deployed applications to Argo CD. At the very least, there has to be some system that takes your code, ideally runs some tests, then packages it as a container image and ships it to the registry. That’s the CI and CD (as in “Continuous Delivery”) part. You might even be among the fortunate club of companies who also have CD, as in “Continuous Deployment”: you merge the feature branch, and it gets deployed to production (or at least to development).

If you don’t have any of these, then it’s not the right time to think about introducing Argo CD, you have big gaps to fill with some pipelines first.

Do you have a well-understood and used deployment tool already?

You need to ask yourself whether the company already has a well-maintained and well-understood deployment system. If let’s say, everyone is already using GitHub Actions to deploy applications, then it makes more sense to evaluate how to use GitHub Actions to deploy your applications to Kubernetes as well.

If this existing system doesn't fit some of the requirements you have (and this requirement can not be “I want Argo”), or it lacks some features you would like to introduce to your deployment process (and this feature can't be “deploy is done with Argo”), then you need to evaluate if it’s better to extend an existing system instead of introducing a new one in addition.

Do you understand how deployment works in a GitOps-based system?

This is a trick question because we first need to clarify what a GitOps-based system is. In its pure form, GitOps simply means “your infrastructure code is in git, and there is a deployment tool that applies this infrastructure code”. It doesn't necessarily mean “pull-based”.

If you merge the code into the mainline, and there's a push event that triggers the pipeline, that does kubectl apply, then you already have a GitOps-based system, as long as everything that's being applied comes from the repository.

When people talk about GitOps today, they most often mean pull-based GitOps systems. It means, that a tool like Argo CD continuously monitors the state of your repository, and when it sees something new, it deploys it. It also deploys code in the repository if infrastructure drifted away from the state in git. If someone changed things by hand, Argo CD will fix it for you (if you configure it in a certain way).

Now, think about this process in terms of a regular application repository, that has some continuous delivery in place:

1. You create a feature branch;

2. CI/CD system runs tests, lint, and maybe pushes the snapshot version of the image (CI/CD system here is not Argo CD, Argo CD can’t do any of this);

3. You merge the branch (after code review, approvals, etc.);

4. CI/CD system does the same and pushes the new production-ready image version to the registry;

5. Argo CD applies the code from this repository to the cluster.

We have a problem here. Step 5 doesn't happen after step 4. While step 4 is triggered by the event - push to the mainline - step 5 is triggered whenever Argo CD notices that there are new commits in the repository. Most likely, because image build takes a bit longer, Argo CD will try to apply the code before step 4 finishes (or even starts). What does it apply to? Well, it depends.

The only “code” that Argo CD deploys is Kubernetes manifests (wrapped with Helm charts or any other tool, but still). If your manifests are stored in the same repository, and they changed, Argo CD will apply these changes. For example, it will change the number of replicas, or update the ConfigMap. But if you only changed the application code, then Argo CD has nothing to do. Deployment won’t happen, because your application’s container image version is not in the git repository! What do you do now?

There are two options:

1. You store your application’s image version in the repository;

2. You use Argo CD Image Updater to update the image in the cluster (other tools, for example, Flux CD, have similar solutions).

Let’s expand these options.

In option 1, you can't store this image version in the same repository as the application code. You will either end up in an infinite CI/CD and deployment loop (git push event -> run ci/cd -> push new image and update version in the repo -> another git push event -> run ci/cd -> ..) or you'll have to be very strategic about which file changes your CI/CD and Argo CD listen for. For example, you could tell your CI/CD system to only trigger on all files except helm/values.yaml, and Argo CD to only monitor helm/ subdirectory.

The alternative is (and that is the best practice in the pull-based GitOps world) to create another repository, that only has Kubernetes manifests, together with the application version. The workflow would look like this:

1. You create a feature branch;

2. CI/CD system runs tests, lint, and maybe pushes the snapshot version of the image (CI/CD system here is not Argo CD, Argo CD can’t do any of this);

3. You merge the branch (after code review, approvals, etc.);

4. CI/CD system does the same and pushes the new production-ready image version to the registry;

5. As the last step, CI/CD system pushes a new commit into another repo, “my-application-config”, with an update to the current version (here you can customize it to create a Pull Request on this config repo, in case you can’t have continuous deployment);

6. Argo CD applies the code from the my-application-config repo to the cluster (after Pull Request to the config repo is merged, in case you can’t have continuous deployment).

With this setup, the extra benefit is that you can change your Kubernetes manifests without triggering the whole CI/CD pipeline, with image builds and so on. The downside of this setup is that you entered a world where each application repo has an extra config repo, and you have quite untrivial automation pipelines in two places. Was it worth it?

In option 2, you install yet another component, that you need to configure, maintain and monitor. At the moment of writing, it also did not reach version 1.

Criteria #2 Summary

Making a decision whether to use Argo CD to deploy your actual application code is a tough one. It requires changing the way your deployments work, and you still need to keep your original CI/CD system, because Argo CD can’t replace it. In a bigger setup, it’s a lot to ask for. The change stops being a pure technology change, but becomes a change of how you work and how you deploy. It becomes especially hard if you have existing deployment dashboards and humans from other departments and professions involved in the deployment process.

Cloud Native consulting: regardless if you are just getting started, or looking for a big shift from the old ways to the future, we are here to help. About consulting

To Sum It Up

If you have a Kubernetes cluster and you run applications there, it doesn't mean that you need Argo CD. It’s an excellent tool to simplify multi-cluster management at scale, but it’s not the best kid on the block for application deployment. You have to always keep in mind, that in the essence of it, Argo CD and similar tools are extremely sophisticated ways to run kubectl apply. Argo CD in particular is fully focused on doing just that and doing it great. A sophisticated, scalable kubectl apply is what every platform engineer, cursed with a fleet of Kubernetes clusters, needs.

Application deployment requires a bit more than that. One reason for this is that the deployment process is quite often way too company-specific (even though we stand by the idea, that it doesn’t have to be company-specific). Another reason is that the deployment process involves more people, than just the platform team. You might have QA involved, release managers, and some internal tools to give beautiful deployment dashboards and internal automation. None of this Argo CD will solve for you.

Neither Argo CD will replace your Jenkins or GitHub Actions or Tekton or any other job execution system. Argo CD can’t lint, can’t build, can’t run tests. It means that Argo CD will become one more tool, and not the tool to handle your Kubernetes CI/CD. You need to understand all the choices and changes involved in introducing Argo CD for application deployment. As a rule of thumb, in most cases, it’s not the right tool to handle that part of your organization.

It’s a perfect moment to remember, that Argo CD is only a part of the rich Argo ecosystem. It has Argo Workflows for CI/CD, Argo Rollouts for a bit more sophisticated deployments, and Argo Events for events and dependency management. All of them have a rich UI, and each of them is a great open-source product. If you have the capacity to run all of them, the resulting system can be marvelous.

And hey, you don’t have to walk the GitOps road alone. Give us a call, and we’ll discuss how mkdev can help you on your Cloud Native journey.