As companies started adopting cloud-native technologies to make software development and deployments as easy as possible, new approaches emerged. One of the most notable approaches is GitOps. As Kubernetes is becoming the standard tool for container orchestration, GitOps is gaining popularity as a default approach to performing Kubernetes-related deployments. GitOps is still new, but it has enormous advantages. Furthermore, we see some GitOps misconceptions making the rounds—so today, we’re going to bust them.
When the term DevOps was coined in 2009, it seemed like just another buzzword. But we’re seeing the reality of the last decade, where nearly every company on earth wants to embrace DevOps principles to achieve their goal of speeding up the software delivery process. We bring DevOps up because it’s a good example of a term worthy of the buzz, and since all GitOps is DevOps, it’s even more topical. As some folks want to pass off GitOps as just another buzzword, let’s explore why it’s worth the hype.
In addition, the 2021 DORA report’s findings revealed that the GitOps approach and principles are crucial to top-performing teams. ArgoCon, a virtual conference centered on GitOps held in 2021, was a massive success with many excellent speakers and attendees worldwide. Moreover, search interest for the keyword 'GitOps' increased exponentially last year.
Kelsey Hightower, a widely respected leader in cloud computing, tweeted: "GitOps is the best thing since configuration as code." Finally, last year’s AWS Container Security Survey revealed that 64.5% of respondents already employed GitOps. All of this indicates that GitOps is much more than a buzzword—it’s here to stay and poised to dominate the software world.
This is by far the biggest of all GitOps misconceptions. GitOps is not just for Kubernetes-related deployments. GitOps is an approach suited for any infrastructure automation type workflows, from Kubernetes to cloud vendors—or even hand-rolled shell scripts. You can do both infrastructure automation and application deployments with GitOps. Furthermore, GitOps can be applied to anything with a declarative text format as the infrastructure, such as Terraform.
GitOps and Kubernetes are like BFFs: they go well together, but they can exist without one another. By maintaining the core principle of GitOps—maintaining Git as the single source of truth, this approach can be applied to any workflow.
DevOps is a cultural phenomenon. It’s an approach to bridging the gap between Dev and Ops teams by increasing collaboration and eliminating silos. GitOps can be seen as a subset of DevOps that boosts collaboration between Dev and Ops by using Git as the single source of truth. There are a plethora of tools that fall under DevOps, and Git is one of them. In simple terms, GitOps streamlines application deployments.
Differentiating DevOps and GitOps doesn't make sense, as we already know that only the companies on the DevOps path embrace GitOps to enrich and enhance their development process. We can summarize it as such: All GitOps is DevOps, but not all DevOps is GitOps.
GitOps is not just Git. If this was the case, then we’d all be doing GitOps already! In GitOps, all of our configuration files and artifacts are stored in a source control repository. You need a CD tool that hosts an agent-like system in your cluster to scan the actual and desired state. Whenever a drift or change happens with a commit by developers, the agent detects this change and pulls them to keep the states even (actual and desired).
GitOps is more than Git; it works on solid principles, such as a single source of truth, declarative description, detecting drifts/differences, changes through pull requests, and automated change approvals.
GitOps is misunderstood by some people because they think it’s all about using Git, as discussed above. Some also believe that CI/CD already uses the GitOps model, but that's also not true. CI/CD uses the push model, where the developer pushes the code to the source code management system (SCM), which triggers the CI server that tests and builds the code. Then, the application's Docker image is created and pushed to the Docker registry.
It all starts with a push process, which is against one of the core principles of GitOps. In GitOps, all changes are done through the pull model because of security concerns. A pull-based approach is preferred, and is considered safe because no external client can access the cluster; all of the updates coming from inside are trusted. A push-based approach is not recommended since cluster credentials are inside of the build system.
GitOps is still new and evolving. It has the potential to disrupt the cloud-native space. If you plan on employing Kubernetes and have a solid software delivery goal, then make sure to have GitOps in your workflow—and not just to automate the infrastructure and application deployments.
Both developers and enterprises love GitOps for its added advantages, such as increased collaboration, simple workflow, improved stability, compliance, and resiliency that automates your infrastructure and deployments.
We hope the GitOps misconceptions listed above will guide you in the right direction with your GitOps journey. Don’t forget to sign up for your free Harness GitOps beta today.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.