leungchopan - Fotolia
As enterprise Kubernetes deployments grow, new GitOps tools that centralize and automate complex infrastructures are finding proponents among both large enterprises and IT vendors.
GitOps is a practice that uses Git code repositories to store all information about an IT environment, from applications to infrastructure-as-code. GitOps tools automatically sync applications and infrastructure when there are changes in Git repositories.
Argo CD is a GitOps tool created at Intuit that moved to incubation within the Cloud Native Computing Foundation (CNCF) in April. It generated buzz during the KubeCon/CloudNativeCon EU virtual event this week after Red Hat said it will participate in the open source project and integrate Argo with its OpenShift Kubernetes platform. Large enterprises with complex Kubernetes deployments in production, such as American Express, are also conducting proof-of-concept tests with Argo and other, similar GitOps tools.
The focus on GitOps reflects the maturity of enterprise Kubernetes deployments, as well as their growing complexity, said Katie Gamanji, cloud platform engineer at American Express and a member of the CNCF Technical Oversight Committee.
"Kubernetes has slowly but surely become mainstream," Gamanji said. "Kubernetes has done very well having a declarative schema … and [as] a stable layer of the infrastructure, pushes developers to think about how to improve what they deploy and how to automate it."
Kubernetes deployments now require orchestrating stacks of components, including separate networking and storage interfaces. This also necessitates coordinated, centralized automation, Gamanji said.
Katie GamanjiCloud platform engineer, American Express
Compounding this complexity – and furthering GitOps -- is a trend toward multi-cluster and, in some cases, multi-cloud Kubernetes management, which vendors such as Red Hat have begun to accommodate in tools such as OpenShift.
Meanwhile, uncertainty that lingered after Microsoft acquired GitHub in 2018 has passed, and the last 18 months have seen an explosion in CI/CD tools, most of which initiate deployments in Git, said Tom Petrocelli, analyst at Amalgam Insights.
"Git is now the de facto industry standard, even more than Kubernetes," Petrocelli said.
Argo CD vs Flux CD: a GitOps rivalry within CNCF
GitLab, founded in 2011, was an early proponent of basing all deployments on Git. Recent versions of Jenkins, such as Jenkins X, also draw on GitOps principles. But Argo CD and Flux CD, both CNCF projects specifically tied to Kubernetes deployments, have begun to carve out their own market niche over the last year.
"Red Hat has been getting requests from OpenShift customers to support Argo, even before it was a 1.0 stable project," said Brian Gracely, senior director of product strategy for Red Hat OpenShift.
The two tools already work together, but Red Hat can provide enterprise tech support, smooth integrations between Argo CD and OpenShift in multi-tenant environments and enhance Argo CD integrations with underlying cloud provider resources and services, Gracely said.
When Red Hat began to evaluate GitOps projects in late 2019, it chose Argo over Flux because a single instance of Argo CD could connect to multiple Git repositories, Gracely said. This made it easier to manage large-scale IT environments with many clusters using Argo at that time.
Flux CD plans to add multi-repo support in version 2, due out this year. But managing multiple multi-tenant clusters was still technically possible using a single Git repo with version 1 of Flux CD, according to Chris Carty, who presented at KubeCon on his experience running such an architecture as a senior systems developer at the city of Ottawa.
Carty managed multi-cluster deployments through Flux using subfolders within the Git repo and a separate Flux agent for each team. With a single repo, however, "all it takes is for one team to misconfigure something and then your deployment might fail," Carty said in the presentation. "For smaller teams I see this working really well, but once you start getting into larger enterprise situations where you have quite a few teams, it starts getting a little clunky."
Despite these early limitations, Flux CD has held its own among early adopters, though Argo CD was in the spotlight this week. Flux proponents at Weaveworks, the company that initiated the project, pointed to CNCF's Technology Radar report in June, which placed Flux and Helm in the most-recommended "Adopt" category, while Argo CD was in the less strongly recommended "Assess" category.
A deciding factor for shops such as American Express that favor Argo is the project's graphical user interface, which gives developers visibility into Kubernetes deployments without requiring them to understand the gory technical details, Gamanji said.
For other IT pros evaluating Argo and Flux, however, the UI was a potential security drawback.
"The advantage of a CLI is that we don't need to host the UI, and can do administration without exposing the UI to the internet or setting up kubeproxy every time," said Herman Banken, software engineer at Q42, an IT consulting firm based in the Netherlands that's working on a Kubernetes-based IoT cloud project for an enterprise client and evaluating GitOps tools.
Given the significant overlap between Argo and Flux, maintainers of the two projects agreed last year to collaborate on common elements of their projects via Argo's GitOps Engine. However, that agreement is now on hold, according to a Flux FAQ.
Game of GitOps: Not all can capture the crown
Competing GitOps projects within CNCF represent a microcosm of the wider, equally competitive market for GitOps and CI/CD tools, as well as the Kubernetes platforms from every major IT vendor now fighting for enterprise attention.
American Express also plans to evaluate GitHub Workflows, while other GitOps early adopters favor the approach of GitLab.
"I'm a bigger fan of 'push-style' GitOps, since testing and development feels easier," said Cristian Klein, cloud-native architect at Elastisys, a managed Kubernetes service provider in Sweden, who uses GitLab.
By contrast, Argo and Flux use a "pull-style" GitOps approach, where any change to a Git repo triggers a cluster update, Klein said. In GitLab, "When I commit a new change, a CI/CD pipeline is triggered that has the credentials to the Kubernetes API and pushes changes to the cluster."
Some GitOps proponents still swear by the market's oldest CI/CD tool, Jenkins, and say projects such as Argo and Flux aren't mature enough yet for enterprise production.
"Our industry currently lacks a truly mature CD tool for the cloud-native world," said Anton Weiss, principal consultant at DevOps services firm Otomato Software in Israel, in a KubeCon presentation. "Argo and Flux are looking in a very important and right direction, but we still have a lot to learn about how CD is done in a cloud-native world."
Otomato is considering building its own such tool, Weiss added.
Some industry watchers such as Petrocelli believe there are too many tools already. Red Hat, for example, will have to clear up confusion about where Argo fits into its portfolio versus Tekton, which underpins OpenShift Pipelines. Red Hat's Gracely said Tekton's strengths are mostly in CI, while Argo is in CD, but ideally, such tools should not be separate, according to Petrocelli.
The proliferation of tools is ultimately a problem the whole open source community will have to wrestle with, Petrocelli said.
"At some point, the CNCF will have to make some bets," he said. "There's no way they can continue to support all the projects they have -- they will have to make some hard decisions."