3 GitOps Myths Busted
It is highly probable that organizations will not be able to achieve an effortless shift to deployment and management of applications and Kubernetes environments anytime soon. Kubernetes remains a complex and challenging platform to manage and implement, despite its widespread use and adoption in cloud native deployments.
The reduction in complexity is not primarily due to Kubernetes itself, but rather depends on the tools, processes, and culture surrounding it. The intricate structure of Kubernetes, involving nodes and clusters, contributes to its complexities.
This is where GitOps comes into play as the de facto process for deploying applications to cloud native environments.
According to GitLab, GitOps is “an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.” It is built on the open source git version control software.
A more precise and consensus-lead description of GitOps has been released by OpenGitOps — a GitOps working group under the CNCF App Delivery SIG. It consists of a set of open source standards, best practices and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps. It describes GitOps Principles as:
- Declarative: A system managed by GitOps must have its desired state expressed declaratively.
- Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
- Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
- Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.
However, even with GitOps, challenges persist in managing Kubernetes deployments and associated tasks, emphasizing the need for improvements.
In this article, we will explore some of the issues that remain with GitOps and are currently being addressed — and more specifically, associated myths.
The goal is to make cloud native deployments and management less complex over time. While we may not have an easy button for Kubernetes deployments in the near future, GitOps will continue to play a crucial role in simplifying the process.
“The aim is to enhance the accessibility and manageability of cloud native deployments, reduce the complexities associated with Kubernetes and enable smoother operations,” said Alexis Richardson, founder and CEO of Weaveworks, who first coined the term GitOps. “This will happen through continuous efforts and advancements in GitOps thanks largely to the open source community and projects such as Flux.”
Myth: Be wary of tools that expressly enable GitOps because GitOps can be done with nothing more than standard continuous delivery tools that support Git-based automation.
While this assumption has been propagated in the past, it is very easy to disprove. Counter arguments include how the Cloud Native Computing Foundation equates graduated open source Flux and Argo CD — the two leading platforms for GitOps — as GitOps enablers. Both are now considered critical components of cloud native infrastructure, as they join the graduated ranks of Kubernetes itself, Prometheus and Envoy.
Both also offer features that are continually improving GitOps processes and security. To wit, Flux version 2 GA ensures Kubernetes clusters remain synchronized with configuration sources beyond Git repositories and include OCI repos as first class, according to Flux’s documentation. This means anyone can now use OCI repos like ECR or Dockerhub as a scalable and secure cache for signed artifacts. This places Flux firmly in the camp of tools addressing the software supply chain.
Also in this version 2, Flux introduces multitenancy support and the ability to sync an arbitrary number of Git repositories, addressing long-standing user requests. The tool is also purpose-built to leverage Kubernetes’ API extension system and seamlessly integrate with core components like Prometheus within the Kubernetes ecosystem.
Flux v2 is developed with the GitOps Toolkit, which consists of composable APIs and specialized tools tailored for building Continuous Delivery solutions on Kubernetes.
“Flux is everywhere now and pulling far ahead of the alternatives. The integration with OCI, cosign, policy and tools like Terraform mean that every serious platform has to build on Flux, while others, such as GitLab and Azure, have already done so,” Richardson said. “With Weaveworks open source dashboard, supported catalog and management extensions customers have a go-to for paid support.”
Is #GitOps popular? According to CNCF survey 84% of respondents were in some phase of adoption with over half adopting it seriously. https://t.co/jg0SKEdb12 pic.twitter.com/iZWT53L9IA
— Dan Garfield (@todaywasawesome) January 31, 2023
In a nutshell, successful GitOps adoption is heavily contingent on GitOps enables such as leading Flux and Argo CD while the implementation of culture changes and processes are also essential. Indeed, the transition toward GitOps is all about trusting the pull-based paradigm of continuously applying gradual changes to the overall application stack, Torsten Volk, an analyst for Enterprise Management Associates (EMA), said.
“This requires a shift toward a declarative paradigm where new code defines what it needs to run optimally and a universal controller automatically ensures that all of these requirements are met. The cultural shift toward enabling developers to write declarative instructions for deployment, operation, and upgrade of their own code is the key challenge when it comes to adopting GitOps,” he said.
Myth: Picking either Flux or Argo CD would lead to building a GitOps silo.
When it comes to these tools, each team might have distinct inclinations. Developers may lean towards Flux, while operations teams could prefer specific features of Argo CD. This diversity in preferences is entirely normal within an organization.
Now, the question arises: Can there be a harmonious integration between these tools for the organization?
The answer is yes, there can indeed be a marriage between Flux, Argo CD, and other tools within an organization. By carefully assessing the specific needs and workflows of each team, it is possible to create a seamless collaboration among these tools, ensuring a more efficient and effective overall process.
Both Flux and Argo CD take advantage of the history available in Git to make it possible to easily audit the change history or revert back to previously working versions before a breaking change was applied. However, Flux’s and Argo CD’s workflows and extensions are different.
Open source Flamingo, the Flux subsystem for Argo introduced shortly before KubeCon + CloudNativeCon last year, integrates Flux into Argo CD for what Weaveworks, the company behind Flamingo, said offers a “seamless” GitOps experience with Kubernetes clusters.
“Argo CD is a user-friendly toolkit for easily defining sophisticated deployment pipelines while Flux is fully focused on its simple, controller-based and fully automated approach of deploying and managing application stacks based on standard Kubernetes APIs,” Volk said. “Adding Flux controllers to the nice Argo CD UI could be a nice step forward in making Argo CD more scalable while simplifying the usability of Flux.”
In a practical way, Unnati Mishra, a working member the technical staff at VMware, described how having Flux and Argo CD simultaneously “could be difficult,” but it is possible “to integrate them to some extent for seamless integration.”
“If an organization is currently using one of the tools and wants to switch to the other, they can do so gradually by onboarding new projects or teams to the selected tool while continuing to use the current tool for ongoing projects until those projects are prepared for migration,” Mishra said. “They can even be given their own isolated Kubernetes clusters if there are multiple teams or projects inside the organization that each need a different set of tools. Each team will be able to select the tool that best suits their needs without harming the others in this way.”
Myth: The false promises about scaling with GitOps.
It is highly likely that as your organization embarks on its cloud native journey, there will come a point where scaling to multiclusters becomes necessary. For instance, developers may need to work on and test applications before making pull requests without having direct access to the production code, of course, for applications running in production on Kubernetes.
Moreover, in certain scenarios, a team might manage multiple clusters and distribute workloads among them to ensure sufficient fault tolerance and availability. For example, when running a machine learning training workload, the team might increase the number of replicas or cluster replicas to meet specific demands.
Additionally, different clusters may be deployed across various physical locations in cloud environments, whether on Amazon Web Services, Azure, GCP and others, requiring separate tools and processes to align with geographic mandates, legal restrictions, compliance requirements, and data access policies.
For the above needs, this writer has heard that a Kubernetes deployment platform, that covers CI/CD, and management of clusters is all that is needed. Sure, GitOps would be nice to have, but it is not essential, or if adopted, its cultures and Git repository-centric philosophy without specific GitOps tools such as Flux or Argo are needed, this writer has heard. The counterarguments are numerous, including the issue of drift that plagues multiple clusters, where GitOps and GitOps tools are instead able to retain the golden standard of application code that remains immutable so that any change, however small, made to a cluster is immediately flagged.
In the field, over 80% of organizations are running multiple, sometimes dozens, of Kubernetes clusters in production, Volk notes. These clusters are often differently managed by the tools available by AWS, Azure, GCP, VMware, Red Hat and others, as mentioned above. “To stay on top of these differences there needs to be a unified layer for consistently applying changes across all clusters. The controller-based approach that interfaces with standard Kubernetes APIs can make this happen, but at the same time needs custom integrations with the opinionated parts of the different cloud environments through GitOps is essential,” Volk said. “For example, providing an Amazon RDS database instance requires very different code from deploying that same database to Azure Database Services.”
Indeed, scaling Kubernetes without GitOps is a bad idea, says Selvi Kadirvel, a platform architect and engineer at Elotl. GitOps is considered an essential part of the solution to the tremendous increase in the scale and number of Kubernetes clusters within organizations, Kadirvel said. For example, another critical trend to handle scale is the expansion of the GitOps paradigm from Kubernetes application deployments to the infrastructure layer for both on-premises and cloud resources, Drift detection and reconciliation GitOps offers “will serve us well when applied uniformly to lower layers of the software stack,” Kadirvel said.
At the same time, just as the Kubernetes scheduler abstracts decisions on where your “pods” should be running given the multitude of nodes of different types available within a single cluster, the emerging field of multicluster orchestrators will enable platform teams to manage the large number of Kubernetes clusters that companies are having to maintain, Kadirvel said. These are unique from cluster life-cycle management platforms such as OpenShift, Mirantis, Nutanix Kubernetes Engine and Rancher, Kadirvel said.
