By now you’ve probably heard of GitOps and, if so, you may still be wondering what it means. It probably won’t help if I tell you GitOps doesn’t necessarily involve Git (no, really), nor does it require Kubernetes, the orchestration engine with which it’s regularly paired.
Confused much? Well, try this: GitOps is a way to enable a developer-centric experience for managing applications, as Weaveworks, the company that coined the term “GitOps,” might say. Put more bluntly, it’s a way to give developers even more control over their work. Think of it as DevOps on steroids, or DevOps taken to its natural conclusion.
That conclusion? To empower developers to take on a much larger role in the operations of their applications, all while also making the lives of ops professionals significantly better, too.
In the beginning was Git
Linus Torvalds might be best known as the creator of Linux, but Git, the distributed version control system of his invention, is arguably even more important. Torvalds has said that “Git proved I could be more than a one-hit wonder,” but this is an understatement in the extreme. While there were version control systems before Git (e.g., Subversion), Git has revolutionized how developers build software since its introduction in 2005.
Today Git is a “near universal” ingredient of software development, according to studies pulled together by analyst Lawrence Hecht. How “near universal?” Well, Stack Overflow surveys put it at 87 percent in 2018, while JetBrains data has it jumping from 79 percent (2017) to 90 percent (2019) adoption. Because so much code sits in public and (even more in) private Git repositories, we’re in a fantastic position to wrap operations around Git.
To quote Weaveworks CEO Alexis Richardson, “Git is the power option, [and] we would always recommend it if we could, but it is very wrong to say that GitOps requires expertise in Git. Using Git as the UI is not required. Git is the source of truth, not the UI.” Banks, for example, have old repositories sitting in Subversion or Mercurial. Can they do GitOps with these repositories? Yes. In fact, some elements of GitOps began to appear as early as the 2000s.
But for most companies, much of the time, the reliance on Git is what makes GitOps such a fascinating advance on DevOps, and a big, near-term opportunity.
Ops of the Kubernetes kind
Oh, and Kubernetes, too. Why Kubernetes? While different container orchestration engines can be used, Kubernetes is the industry default. According to Weaveworks, GitOps is two things:
- An operating model for Kubernetes and cloud native. It provides a set of best practices to join up deployment, management, and monitoring for containerized clusters and applications.
- A path towards a developer-centric experience for managing applications.
Maybe you don’t need Kubernetes for everything, but many organizations are turning to it as an essential aspect of how they deploy software. And yet far too many are flying blind on their Kubernetes clusters. How so? According to Cornelia Davis, CTO at Weaveworks, while IT has had various tools in place (e.g., config management, discovery, etc.) to try to track what was going on within and across systems, to a large extent much wasn’t known, which is why patch management has proved so hard.
“Moving to Kubernetes didn’t make IT magically less blind,” Davis says. “They carried the problems they already had forward into Kubernetes.”
Or as Richardson put it, “How do you know if you update Kubernetes that it’s in the correct state? Do you get told if it’s in the wrong state? The answer is no. [Developers] have no idea. They are flying blind.” As such, Kubernetes users are “frozen” because they’re stuck with clusters they’re scared to update.
Enter GitOps.
A true DevOps (GitOps!) experience
The GitOps model cures such Kubernetes paralysis, without requiring developers to become Kubernetes gurus. It does so by using automated directors to deploy changes to a Kubernetes cluster to bring it back into line with a declarative model of the desired state, according to Richardson:
What if everything in the cluster were updated via a model? If you install some agents into your cluster that look at current state and compare it to the model, you can then make changes to force it to conform to the model. You’re not updating them directly - you’re updating the models. Along the way you get continuous integration, progressive delivery, etc.
Weaveworks describes this in more detail but I also like Redmonk analyst James Governor’s summary:
- Provisioning of AWS resources and deployment of Kubernetes is declarative.
- The entire system state is under version control and described in a single Git repository.
- Operational changes are made by pull request (plus build and release pipelines).
- Diff tools detect any divergence and notify you via Slack alerts; and sync tools enable convergence.
- Rollback and audit logs are also provided via Git.
It’s an approach that sounds great for developers and the application teams they may serve. But what about the platform engineering team, the folks we often call “ops” and who have particular responsibility for security, compliance, cost management, and more?
For ops, GitOps drives huge value through repeatability. Need to bring an availability zone back up? The platform engineering team knows that because everything is modeled, they can just run the reconcilers to bring things back in line with the models. Coupled with Git’s capability to revert/rollback and fork, the ops team gains stable and reproducible rollbacks, not to mention Git’s security benefits and more.
GitOps, in short, just might be what DevOps has long aspired to be: a great way for developers to take on more of the operational burden for their apps, even as platform engineering (ops) is better able to tackle their roles.