Let's observe Argo CD: focus on the first two CD tools

Releases happen every quarter with up to ten patches in between. Today, the team's roadmap mostly includes performance improvements and alerting features through connectors with Slack, Github, PagerDuty, etc.

Several companies have implemented it, including technology companies like Qonto, Tesla, TicketMaster, and large corporates such as Volvo, EDF Renewables, and HSBC.

Practicing GitOps means building your infrastructure as code and then versioning and deploying it with automated tools. Although versioning infrastructure code becomes a no-brainer, ArgoCD enforces GitOps practices and removes any imperative CLI tools like kubectl from the developer workflow.

We first used ArgoCD to deploy one application on more than 10 client-dedicated clusters on 2 Cloud Providers. Along the way, we discovered that ArgoCD has a lot to offer to enhance the deployment experience and be a standard interface between dev and ops.

For whom?

ArgoCD is appealing for:

• CTO/Engineering Managers for scale-ups already highly efficient at DevOps who want to push further the reliability and the fluidity of their deployments<
• SREs struggling to show and explain the scope of their work to non-initiated ops

Main benefits

Benefit #1: It improves the maintainability of your continuous delivery pipelines

CI/CD tools, and especially Gitlab CI is used for three main stages:

• Running unit and functional tests
• Building artifacts such as Docker images
• Deploying the artifacts onto the infrastructure

Because of this, gitlab-ci.yaml files are lengthy and complicated, which makes these configuration files hard to maintain. Argo facilitates the separation of concerns (an important SOLID principle) by introducing a specific way to handle the third stage: artifacts' deployment.

ArgoCD makes the delivery of a part of the application by defining it with Kubernetes templates:

Kubernetes resources for Code Delivery

When a pipeline pushes a new Docker image to the registry or a Kubernetes template changes, ArgoCD reacts and deploys the new image, without any "push stage" in your CD. No further maintenance is required!

Benefit #2: It provides excellent visual management for Kubernetes architecture

ArgoCD introduces the concept of Applications: a set of Kubernetes resources grouped by business logic. This is a game-changer: Applications bring developers closer to the business domain and remove the requirement to understand complex infrastructure resources...

Argo provides a straightforward UI to show:

• The types of Kubernetes resources (service, service account, etc.) and their relationships<
• If they are healthy (green heart) and synchronized with the last changes made in the folder containing the Kubernetes resource definitions committed or a new docker image pushed to the registry (green check)

Argo CD view of an Application

Six kubectl commands are needed to obtain the same information:

• If you're not aware that a resource is involved, for instance, a Service Account, you won't find it as the command line result does not display connections between resources<
• You can only know about the health of Pods ("Running" information in the screenshot below), not other resources
• You can't know if the resources are in sync

Kubectl CLI results to obtain the same information about the Application

Benefit #3: It performs slow Rolling Updates to give you time to test your application in production

When you're deploying a Kubernetes application, you can perform a rolling update:

1. Kubernetes creates a pod with the new version
2. When the readiness check has passed, the Pod starts receiving traffic
3. Kubernetes terminates a pod with the old version
4. Kubernetes repeats steps 1-2-3 until it deletes the last old Pod

We can upgrade services without downtime: it's fantastic, but it's not enough. Two versions of your app coexist, and you can't test your new release on a small percentage of users in a controlled manner. This last deployment technique is called Canary Release.

Argo Rollout helps you to do so by configuring pauses between your rollouts:

This video shows that one pod is updated, and then the deployment is posed during 60s, then 2 other pods are updated, and the deployment is posed again during 60s. These two minutes give you time to perform tests on the fresh release.

Drawbacks and Trade-offs

Drawback #1: You can't still run Canary Releases

As shown above, you can configure pauses with Argo Rollout. Still, you lack observability:

• If you're multitasking, you can forget to run tests and move on to a new task. If issues happen, you won't be aware before someone or something pings you. Then you don't have precise data about what happened to help you debug.
• Even if you're watching the rollout happen, you can not be sure about the application's behavior. With manual testing, you're not sure to reach the desired pods. You need more tools to send requests to specific pods or filter logs appropriately.
  
  

Trade-off #1: It is heavily coupled with Kubernetes

Get stuff done with Kubernetes -

This quote is the headline of the Argo website. It is crystal clear: Argo works only for your applications hosted in a Kubernetes environment.

Furthermore, developers are getting used to gitlab-ci.yaml files. Shifting to Argo makes the deployment part more hidden for developers as it's become a Kubernetes resource.

Trade-off #2: Yet, another tool to maintain

Mckinsey claims that working on tools rationalization gives the company "a return on investment of more than 50 percent, a reduction in time to market of at least 30 percent".

Introducing ArgoCD introduces a new tool that requires maintenance with updates, security configuration, and so on.

Our Secret Sauce

At Padok we use ArgoCD with two main goals.

First, we use it to train, both internally for junior ops and externally to help developers we work with.

One picture is worth a thousand words - Confucius

Thanks to the UI we're able to visualize abstract concept as Service, Secret, etc. The trainee can deploy several types of Kubernetes infrastructure and visualize it. Then he can do the reverse exercise: draw its infrastructure and visualize it with Argo to eventually catch differences.

Besides, we coupled Argo with Kiali in order to adopt Canary Releases deployment. Indeed Kiali displays the traffic in real-time with information about error rates. Therefore we can catch a faulty release before its full rollout and address part of drawback #1.

Finally, there is a lot of enthusiasm around Kubernetes Custom Resources or operators helping the community define we believe that ArgoCD is that kind of tool helping the community define its whole project only as Kubernetes resources with :

• Tekton to define the CI
• Config Connector to define your infrastructure (IAM, ...)

This will provide a simple way to create Cloud Agnostic architecture in the future. Stay tuned for my next article on the future of Infrastructure as Code. 😉