The 4 Stages of the Argo Maturity Curve

The 4 Stages of the Argo Maturity Curve

10 min read

Argo CD is the most popular GitOps tool for deploying applications to Kubernetes clusters. Many teams that move their applications to Kubernetes choose Argo CD for its powerful sync engine and intuitive dashboard.

Argo CD is also fully open source, which means teams can freely install it on their private clouds, behind-the-firewall data centers, or even in air-gapped environments without any licensing restrictions. Argo CD’s popularity is surging right now, especially since Weaveworks (the company behind Flux – the main Argo CD competitor) ceased operations in early 2024.

It’s important to understand, however, that while Argo CD is great as a GitOps sync engine, it’s missing several features that big enterprises need when deploying at scale. If you have one or two Kubernetes clusters and a small number of applications, it’s easy to start using Argo CD. For larger installations with multiple clusters and multiple applications, using plain Argo CD takes too much manual effort. In those cases, looking at an enterprise solution like the Codefresh platform will be more beneficial as your organization scales its Kubernetes use.

In this guide, we look at the 4 stages of the Argo maturity curve. We explain how Codefresh can help you at each stage beyond what Argo CD offers out-of-the-box.

The central theme here is that enterprises have several other requirements not offered by the sync engine of Argo CD, while Codefresh is built from the ground up as an enterprise platform.

Stage 1 – Initial Argo CD installation versus using a control plane

The OSS version of Argo CD allows for 2 installation modes out of the box:

  1. Installing an Argo CD instance per Kubernetes cluster.
  2. Installing a central Argo CD instance that manages several other clusters.

Each method has advantages and disadvantages. We cover them in detail in our Argo CD architecture article. The takeaway is that no option is perfect, each has shortcomings.

The individual Argo CD instances are very difficult to manage on a large scale.

The biggest problem is daily cluster management. You now need to manage multiple Argo CD instances and their respective dashboards. If you have for example 6 Kubernetes clusters, you’ll also have 6 different dashboards. When searching for an application you need to remember to use the appropriate Argo CD dashboard. Upgrading all 6 Argo CD instances to the same version is also a non-trivial job.

On the other hand, you can have the central Argo CD instance that manages other clusters.

This also comes with significant challenges.

  1. The central Argo CD instance is a single point of failure.
  2. Communication to other clusters is outgoing. This means you need to open holes in your firewall if the other clusters aren’t in the same networking domain as the central instance.
  3. The centralized instance will quickly become a bottleneck when you have a large number of applications and clusters.

Teams that choose either of these installation options will have to deal with the disadvantages on a day-to-day basis and either accept them or try to find workarounds.
With Codefresh there is a third solution – using a Control Plane.

The Codefresh Control Plane unifies multiple Argo CD instances under a single management dashboard.

The Control Plane approach offers the best of both worlds without the disadvantages

  1. Communication with the Control Plane is inbound. This means you can manage Argo CD instances behind the firewall and there isn’t any need for open ports
  2. There isn’t a single point of failure. Even if the Control Plane has issues, the individual Argo CD instances will continue syncing on their own.
  3. There are no performance bottlenecks as you can easily mix and match multiple Argo CD instances and clusters.
  4. There’s still a single application dashboard for Argo CD instances.

The last point is especially important for end users of Argo CD and, more specifically, developers. They can now view their applications easily without juggling between different dashboards.

Even at this early stage (installation of Argo CD), choosing Codefresh brings extra value to both Argo CD administrators and users.

Stage 2 – Managing multiple applications and tracing back code changes

With the initial installation out of the way, let’s examine what happens with day-2 operations. Creating Argo CD applications is a straightforward process. Out of the box, Argo CD supports your Helm charts, Kustomize overlays, and any other custom manifests you already have.

The main problem here is that Argo CD has very limited information about the applications that your developers create. The only thing that Argo CD knows about an application is:

  1. The Git repository that has the Kubernetes resources
  2. The container image that gets deployed
  3. The target cluster where the application gets deployed
  4. The Git hash of the manifests that were applied

And that’s all! Argo CD has no visibility into the things that matter for developers. Developers want to know what source code changes went into a release, plus information like unit test results, security vulnerabilities, and pull request information. Argo CD doesn’t know what happened before a container image was built.

This means that developers have to switch between multiple systems like GitHub, Jira, the CI server, and Argo CD to understand exactly what Argo CD deployed.

Several teams adopt Argo CD hoping that developers will use the Argo CD UI as a one-stop solution for all their deployment needs. Unfortunately, it quickly becomes apparent that developers can’t work with just the Argo CD UI. At this point organizations start looking at developer portals and internal developer platforms to address the daily needs of the development team.

With Codefresh you get full traceability from source code committed to deployment.

Codefresh aggregates information from several other systems, like the CI server or the ticket server (i.e. JIRA), and provides a complete timeline of what happened with an application deployment including:

  • Who initiated a change
  • What was the Git commit
  • What features (i.e. Jira tickets) were included
  • Which pull request took part in the change
  • Which pipeline was used for artifact creation
  • Results of security scans, unit tests, lint checks, etc
  • Which container images were produced and pushed
  • Which Kubernetes applications were affected
  • Which individual components were updated

The timeline also gives you the overall health status of a service/application across the complete history of deployments.

Using Codefresh, developers can answer in seconds the burning questions they face every day. Some examples are:

  1. What JIRA features are now deployed in Staging? 
  2. Who deployed release 0.3.0 last Thursday and what source code features did it contain?
  3. Where is JIRA feature 4524 deployed right now? Is it in Production just yet?
  4. What is the CI pipeline that created container image billing:v0.4.0 that’s been sitting in the QA environment for the last 5 weeks?
  5. Do we have any critical vulnerabilities known in the artifact deployed in the Load Testing environment?
  6. How many developers have just pushed their feature to QA?
  7. Who approved pull request 2345 that just went into production?

If you have only Argo CD, answering these kinds of questions can take significantly longer (even hours in some cases). With Codefresh,  developers can instead reason about any deployments and quickly discover the full picture for any active application.

Stage 3 – Promoting apps between environments

After you have the initial deployment for every application in place, the next step for developers is promoting applications from one environment to another.

Unfortunately, the open-source version of Argo CD can’t help with promotions. Argo CD has no concept of an “environment” and doesn’t have any information about promotions. This forces people who’ve adopted Argo CD to try implementing their own promotion mechanisms with several workarounds.

The classic pattern here is the “special” naming of applications and the hardcoding of an “environment” in the application name:

Here these 3 Argo CD applications have been named with a special pattern to try accommodating “environments”. Even though it’s clear to a human user that this is the same application deployed in 3 environments, for Argo CD it’s 3 different applications with no connection between them whatsoever.

Codefresh has full support for both grouping multiple applications (in products) as well as modeling environments the proper way:

A Codefresh environment can be a different namespace, a different cluster, or different namespaces in a different cluster. Basically, you can mark any combination of clusters/namespaces as an environment. Then Codefresh can correlate applications and their environments in the backend and reason about them. In the example above, even though the underlying applications are still named “accounts-qa, account-staging, accounts-production”, Codefresh knows that it’s the same application – accounts – deployed to 3 different environments. 

In addition to environment support, Codefresh can aggregate information from the CI phase into environments (as explained in the previous section). This means that, unlike Argo CD, which only knows a container image version and nothing more, Codefresh can match other metadata into an environment, like source code commits, pull requests, security scans, and more.

Here’s another view of the environment dashboard which now has JIRA information as well:

Using this dashboard, developers can reason in seconds about their GitOps environments and answer questions about features which isn’t possible with just Argo CD.

The highlight feature, of course, is the promotion between environments. Since Codefresh has all the context about which application is deployed into which environment, promotions are a core, built-in construct in the Codefresh GitOps platform.

In the most simple scenario, you can simply let developers promote applications by drag-and-drop. Codefresh automatically creates a commit with all the required information to perform the promotion.

In a more complex scenario, you can define a complete promotion workflow with specific restrictions and pre/post checks that again isn’t possible with plain Argo CD.

In the screenshot above, we defined a basic promotion policy between 4 environments. New applications can only be deployed in “dev”. After they pass the checks in “dev”, they can move in parallel to “staging” and “qa”. Only if all checks pass in both “staging” and “qa” can the application go to production. 

The beauty of the promotion policy is that you can define any pre/post checks and enforce them. Your checks can be security scans, smoke tests, database checks, etc. 

If a check fails, promotion gets blocked:

In this example, checks were successful in “staging”, but something went wrong in “qa”. This means developers can’t push to production until  “qa” gets fixed. You can use the friendly Codefresh UI to understand what went wrong and drill down in the logs.

Essentially, when it comes to environments and promotions, plain Argo CD can’t help you at all.

The functionality of Codefresh is essential as developers always think in terms of environments and promotions.

Stage 4 – Enterprise features

With the basic functionality out of the way, we can finally look at all the features that enterprises need as they scale.

Often, organizations start with just Argo CD and soon realize they need other features like built-in pipelines and progressive delivery (blue/green/canary). At this point, they choose to manually install Argo Workflows and Argo Rollouts. Then they spend extra time integrating those products.

Even though the Argo projects are made to work together, integrating them in a single cluster is a non-trivial process. For example, Argo Workflows have a different SSO mechanism than Argo CD, while Argo Rollouts has no SSO support at all.

Codefresh comes with this integration out-of-the-box. The Codefresh runtime is a unified installation package that contains all 4 Argo projects out-of-the-box and with security patches applied.

The unified integration dashboard we mentioned in the first section also applies to the other Argo projects. For example, by adopting the Codefresh runtime, you get free SSO support for all 4 projects with no extra effort.

Here’s an example of using progressive delivery in an application from the same Codefresh interface.

At the same time, Codefresh offers several enterprise features that would require significant effort to replicate with just Argo CD. Because Codefresh has full visibility of what happened in both the CI and CD phases, DORA metrics are always available from the Codefresh UI with zero configuration.

Finally, you can find several statistics and insights that reveal bottlenecks in your deployment process. Again, you’d need to manually create them if you only use Argo CD

This was just an overview of the extra enterprise features offered by Codefresh. There are several other features, like annotating container images with extra metadata:

Correlating images with deployments also happens out-of-the-box with Codefresh:

Often, developers need to know where a specific image is deployed. Answering this question with Codefresh literally takes seconds. Answering with just Argo CD can take hours depending on the complexity of the application.

Conclusion

We’ve seen the 4 stages for GitOps maturity and explained at every stage what you get with Argo CD and what extra features Codefresh offers.

It should now be clear that Argo CD is great as a sync engine but misses several features that enterprises need for effective deployments. With Codefresh you get a full enterprise platform that has all the missing functionality, while still using Argo CD under the hood.

The Codefresh platform is actually a superset of all 4 Argo projects and contains extra features in regards to:

  1. Initial installation
  2. Application deployment and correlation with the CI process
  3. Full traceability for a source code change from the initial commit until it reaches production
  4. Environment promotion and creation of developer guardrails
  5. Enterprise security and support
  6. Deployment statistics, DORA metrics, and application insights

Get started with the Codefresh GitOps platform, sign up now or schedule a demo.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 2

No votes so far! Be the first to rate this post.

Ready to Get Started?
  • safer deployments
  • More frequent deployments
  • resilient deployments