GitOps hits stride as CNCF graduates Flux CD and Argo CD
Flux and Argo CD earned graduated status within CNCF after a year in which platform engineering adoption and DevOps advances put both in the enterprise spotlight.
With the open source community's seal of approval for two major GitOps projects, the automated code deployment method is ready for enterprise production and has already found widespread use there among early adopters this year.
IT experts disagree on what constitutes GitOps. But the strictest definition of the term, embraced by newly graduated Cloud Native Computing Foundation (CNCF) projects Flux and Argo CD, refers to an approach that uses Git code repositories as a single source of truth to govern all aspects of an IT environment.
Associated with Kubernetes infrastructure, which also requires a declarative mode of management via code, Flux and Argo CD can enforce a match at all times between a desired state expressed in Git repos and the actual state of production clusters. This GitOps approach contrasts with the earlier CI/CD philosophy, in which changes are more gradually applied to the production environment.
Flux and Argo CD first emerged in enterprise production in 2020. Argo reached the incubation stage within the CNCF later that year, and Flux followed in 2021. Both reached the third and final CNCF stage of maturity -- graduation -- in late November. Flux's graduation was announced publicly Nov. 30, and Argo's this week.
Even at the earliest stage, Flux was one of the most-used CNCF sandbox projects in production, according to CNCF's 2020 user survey, where 8% of respondents reported usage. In 2021, nearly 50% of CNCF survey respondents either used or were evaluating Argo CD, and about 30% of respondents used or were evaluating Flux. That's in addition to approximately 19% of respondents using or evaluating Flux's associated Flagger progressive deployment project.
The growth in usage and interest stems from simultaneous growth in enterprise platform engineering practices over the last year, according to one analyst.
"GitOps requires a platform, literally by definition," said Paul Delory, an analyst at Gartner. "If you're going to manage everything using only declarative constructs stored in Git … you must have some kind of platform underneath that abstracts away all the underlying complexity so that you really can operate it using only a declaration."
GitOps is the last mile of software delivery.
Paul DeloryAnalyst, Gartner
The GitOps adoption trend also reflects Kubernetes' entrance into the mainstream, along with sophisticated software delivery practices, Delory said.
"GitOps is the last mile of software delivery, basically," he said. "You have to already be at a very, very advanced stage in your platform automation and your delivery pipelines before you can do something like GitOps right."
While many enterprises didn't wait for CNCF graduation to put Flux and Argo into use, that designation does carry weight for organizations less inclined to be early adopters, Delory said.
Flux CD vs Argo CD -- or both?
Both projects' maintainers acknowledged this month that Flux and Argo CD perform the same function. There was an effort in 2020 to merge the underlying reconciliation mechanism of the two projects into a utility called GitOps Engine. But while Argo CD still uses GitOps Engine, Flux CD opted for its own approach with GitOps Toolkit.
The simplest way to summarize the difference between the two projects -- and why two similar projects remain within CNCF -- is that Argo CD includes a GUI while Flux does not. Argo CD is one of four components of the broader Argo Project, all of which reached CNCF graduation officially this week. The others include Argo Workflows, Argo Rollouts for progressive deployment and Argo Events for event-driven deployments. Flux is closely associated with the Flagger progressive delivery project but otherwise self-contained and managed via CLI.
The GUI and other, subtler differences between the two projects arose primarily because each originated within a different type of organization. Argo CD is the brainchild of financial software firm Intuit, an end user organization, while Flux is primarily maintained by employees of GitOps software vendor Weaveworks. Intuit developed Argo CD for its software developers, who wanted a simpler user interface than raw Kubernetes YAML to manage application deployments. Flux, without a UI or its own role-based access control, lends itself more to integration within wider cloud infrastructure platforms, such as Microsoft Azure, which launched Azure GitOps based on Flux in June, and Amazon EKS, which began to integrate with Flux late last year.
Respondents to a 2021 Cloud Native Computing Foundation user survey indicated widespread usage and evaluation for Flux and Argo while both were still incubating projects.
For end users, Flux versus Argo is often not a mutually exclusive proposition.
"I'm still using Flux for stuff like bootstrapping because Argo CD is a bit trickier to install," said Clément Blaise, an Argo project contributor and site reliability engineer at a blockchain software company he asked not be named. "I'm using eksctl to deploy our control plane. And it only integrates with Flux because they're just a binary you can install directly, whereas Argo is usually a Helm chart and requires some configuration."
That said, at both his current and most recent employers, Blaise has sworn by Argo CD because of its developer-friendly UI.
"I'm currently building a platform, and all the service catalog aspects will be built on Crossplane, while all the GitOps aspects will be based on Argo CD," he said. "To me it's very easy. … If you're more on the ops side, then Flux is going to be a good match for you. But if you're a developer, [with Flux,] you don't have a UI or an API to interact with as you're rolling out your application and you don't have RBAC to assign permissions based on different things like namespaces. … [With Argo,] you have the UI and it's very application focused. I can check my logs and view the structure of my application as a developer."
'A friendly rivalry' based on philosophical differences
Unified communications software firm RingCentral also has experimented with both Argo CD and Flux / Flagger but has steadily moved more toward Flux over the last 18 months.
"It's a lot easier to reason about because it's based on the notion of your repository [as a source of truth] from the very beginning," said Ivan Anisimov, director of engineering at RingCentral. "Argo can be adapted in this way, but it looks like a more complicated solution with more moving parts. And in a big company, you want to reduce the number of moving parts."
CNCF graduation criteria
According to CNCF's GitHub page, to graduate from sandbox or incubating status, or for a new project to join as a graduated project, a project must meet incubating stage criteria plus the following:
have committers from at least two organizations;
achieve and maintain a Core Infrastructure Initiative Best Practices Badge from the Open Software Security Foundation;
complete an independent and third-party security audit, with results published and all critical vulnerabilities addressed before graduation;
explicitly define a project governance and committer process;
explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers or those who may interact with the CNCF on behalf of the project;
have a public list of project adopters for at least the primary repository; and
receive a supermajority vote from the Technical Oversight Committee to move to graduation stage.
Companies whose intellectual property is in platform engineering interfaces might also naturally gravitate toward Flux, whether big cloud providers or smaller newcomers such as Amesto Fortytwo, a platform engineering service provider based in Bergen, Norway.
"The main reason why we choose to use Flux is because on the deployment side, it's just Kubernetes manifests," said Roberth Strand, principal cloud engineer at Amesto Fortytwo. "We don't have to create a new process based on the tool itself."
Still, among end user organizations, at least over the last year, Argo can cite stronger adoption stats in the CNCF survey as well as 350 self-identified end user companies using Argo CD in production. Argo also has a wider breadth of maintainers. A majority of around a dozen Flux maintainers work for Weaveworks, whereas about a third (12 of 40) of Argo's core maintainers are Intuit engineers.
"It's a friendly rivalry" between Argo and Flux in the wider community, according to Intuit's group product manager for platform and open source Henrik Blixt. "The fact that one project is led by an end user company and the other by a vendor makes it hard to combine them, because you have one company that's actually making a living out of the project and another that just wants to build a community around it and use it themselves."
Friendly or not, Blixt soon turned to the rivalry portion of the relationship, calling Argo's community diversity a key strength over Flux.
"When you're looking at longevity, when most of a project's maintainers are from one company, if that company goes away, that project is in real danger," Blixt said.
Weaveworks CEO Alexis Richardson, naturally, disagreed.
"Without a strong development group, a company cannot offer meaningful support to end users," he said. He cited Apache's Kafka project, largely maintained by engineers from Confluent, and the Apache Hadoop project as examples of how consistent core maintainers can lead to success and diversity of maintainers can lead to "chaos and failure" respectively.
"Weaveworks can underwrite security and create safe commercial partnerships for the benefit of end customers consuming enterprise products like [HashiCorp] Terraform Enterprise Edition," Richardson said. "Big companies like AWS and Microsoft can easily provide at-scale customer support this way and don't have to worry about hiring and training Flux experts to hack on core code."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
