GitOps is a term that never fails to awaken my curiosity. Let’s be clear – it is a purely marketing term, looking to capitalize on using git as a focal tool to orchestrate a software deployment and delivery system. In spite of the superficial underpinnings, I admire the overall technology. A lot.
As an ops engineer not too familiar with Git, you just need to know 6 commands – git init, git add, git commit, git status, git log, git revert – to harness the power of GitOps.
— Janakiram MSV (@janakiramm) November 1, 2021
This tweet, which summarizes the biggest advantages of the GitOps paradigm, is an eye-opener. Learning more about GitOps makes me very reflective about the way in which PaaS tools have evolved. This article is a collection of my thoughts and observations from having used these tools over the years.
A Quick Introduction to GitOps
The sense in which GitOps has been named is rather different from the way in which the term DevOps has come to be. There’s no notion of a “Git” team, whereas there is a “Dev” team. GitOps comes from the git tool used for source control and maintains revisions of all the source code of the application. It can also collocate infrastructure needs and deployment requirements in a declarative syntax since these are typically flat files. Therefore, to make a system that can build and deploy software in an automated fashion, using version control as a focal point to define a single source of truth – that is my understanding of what GitOps is. It has many distinctions from DevOps. DevOps effectively subsumes GitOps as one potential implementation of the ideas laid out within its overarching principles.
GitOps can never equal DevOps
The reason is – DevOps principles are founded on the basis of resolving a seemingly inextricable problem. DevOps principles are formulated in order to bring about convergence among two traditionally orthogonal groups of engineers.
On the one hand, there are application developers from where the ‘Dev’ comes. These are engineers who are responsible for designing and programming the applications. Their success was traditionally measured in terms of the features they were able to build into the application, in other words, velocity. The second group is of IT operators – you guessed it, from where the ‘Ops’ suffix comes. These engineers are responsible for the stability and reliability of the applications at run time. In short, the quality with which the application functioned.
Schematically, these two groups did not have any common focus. This led to enormous confusion within organizations, especially larger ones. This created difficulties for users/customers, ultimately resulting in losses for the businesses because of bad practices.
GitOps Success Factors
The present success of GitOps can be attributed to, in my opinion, two chief factors.
- The growing importance of viewing source code as a single source of truth.
- The independent success of the Infrastructure-as-Code paradigm.
Making use of the git version control as the interface for deploying and managing applications is a gratifying move. GitOps, therefore, is a side effect of solving everything from an engineering vantage point. It builds upon the fundamental principle that “All the artifacts required to specify and maintain infrastructure are text files, ergo can be maintained in a version control system.”
There is little doubt about the ubiquity of source control and its maturity and utility. Git provides a wonderful abstraction for developers. Putting the source code at the center of the development and deployment pieces as the single source of truth is a great way to implement DevOps strategies.
The Truth About Ops in GitOps
The “Ops” suffix has always been about operating runtimes and keeping systems functional in production. The artifacts were once simple binaries. Today, they are typically containers that are deployed to a runtime and scheduled and managed. The “Ops” half of the lifecycle is managed using a “git operator”, which ensures that the state of the system is reflected accurately.
Staging instances consisting of the deployment artifact, environment configurations, and workflows that will allow managing these comprise the plane of operations.
Historically, Ops has always been about generating a runtime. In the past, it was about supplying a binary.
Currently, it has evolved into containers. At the core of the ops thought process, it is three pieces that make up the mechanism
- Application Source Code
- A Build mechanism
- CI/CD pipeline
The (Inverted) GitOps Pyramid
Let us examine a few examples of paradigms that do precisely this.
- Netlify
I highlight Netlify as an example of one of the many tools available for deploying software. In one of his talks, the company CEO, Mathias Biilmann, highlights “emergence of Git-centered workflows with modern build tools and static sites generators” as a founding principle of Netlify. Other examples include Vercel (formerly Zeit) and Next.js. There are tools that are specific to other languages besides JavaScript too. The common factor that needs highlighting here is near-zero Ops.
Caveat: Static websites
- Heroku
Heroku is the shining star among git-centric workflows. The Heroku folks pioneered a workflow where you handed the source code off to an abstract platform which ultimately took care of the deployment of the application. It works across all major programming languages by using Buildpacks. Heroku is designed to work with a limited number of services. Its biggest handicap is the inability to port the Heroku-experience across a developer’s choice of infrastructure.
Caveat: 12-factor apps
- Cloud Foundry
Cloud Foundry built an independent platform to mimic the Heroku experience, but its open source nature made it a fantastic choice for enterprises. The popularity of Cloud Foundry among large companies is high because of its extensibility and overall security posture. Nothing comes close to providing a platform for managing releases, orchestrating deployments, and performing lifecycle management of applications. Except perhaps OpenShift, which is another stellar example of enterprise-grade, open-source, general-purpose PaaS done right.
Caveat: Opinionated design
- Infrastructure-as-Code
This is slightly different from the other categories, in the sense that it isn’t a single product or tool. It is a broad discipline where managing the infrastructure happens by using configuration files that reside along with the application source code itself. IaC supports both declarative as well as imperative approaches. It improves the developer/operator experience greatly by (a) providing a git-based interface to managing the run time and (b) supports complete automation of build and deployment.
Caveat: Governance
Challenges And The Future
GitOps, like any good piece of technology, gets me to raise a few questions.
- Git, as a version control protocol, has its own share of problems when used for collaboration. How does GitOps handle this compounding nature of risk?
- How is incident management handled, git-natively, when using GitOps?.
- How would multi-tenancy work? At an ‘application’ level? A ‘branch/trunk/fork’ level? What about merges and conflicts?
- How is it possible to add stateful components and services to applications when they are being deployed?
In addition to answering these questions, I would love to see GitOps practitioners come forward and share their experiences more broadly. Specifically, I’d love to hear stories from their war rooms about handling scaling issues, such as setting up infrastructure alerting, healing corrupt disks and disappearing host machines. That contrasts with talk about getting code deployed, which dominates the conversation right now.
Challenge accepted?
