GitOps the Hard Way, with Argo CD

Where Argo CD Came From, and Why That Gap Existed

Argo CD's story began with a vision to simplify how engineers manage applications on Kubernetes. In the early days of Kubernetes and microservices architecture adoption, Applatix, a startup with a keen eye for scalable production systems, saw the challenges firsthand.

Kubernetes gives you Deployments, Services, ConfigMaps, Ingresses, and a dozen other object types, but it has no built-in notion of "the application" those objects add up to. Ship a real service and you are tracking ten or twenty manifests with no single handle to deploy, inspect, or roll back as a unit. Teams filled that gap with hand-rolled shell scripts, kubectl apply ordering hacks, and CI jobs that pushed manifests straight at the cluster, which meant the running state and the state in Git drifted apart with nothing watching the difference. The Applatix team built the Argo project to close that gap.

The first product to emerge from this effort was Argo Workflows, designed to orchestrate complex, multi-step tasks within Kubernetes environments. Using Kubernetes' Custom Resource Definitions (CRDs), the team developed a tool that could handle parallel jobs, define dependencies, and manage workflows with greater efficiency. By 2017, Argo Workflows had been rewritten to make it more Kubernetes-native, after the team realized that they would focus on Kubernetes as the primary platform for their products.

In 2017, Weaveworks CEO Alexis Richardson coined the term "GitOps" for a way of running infrastructure and applications with Git holding the declared desired state. The model is declarative and version-controlled: you commit what you want, and software makes the system match it.