GitOps is one of the latest buzzwords to ride the waves of the “everything Ops” movement. Like most concepts associated with DevOps, the exact meaning of GitOps is in the eye of the beholder. Also, as with other DevOps-related ideas, GitOps can be either a powerful way to manage configurations more effectively or a methodology that teams end up pursuing dogmatically for its own sake--and applying to situations where other approaches would work better.
Let's take a look at what GitOps means and how to leverage the concept effectively.
The Multiple Meanings of GitOps
Part of the reason why I say that GitOps can be merely a meaningless buzzword is that--like the meaning of DevOps itself--it is defined in different ways by different people.
Probably the most classic definition of GitOps is exemplified by this Twistlock article (which--full disclosure--I had a hand in editing): GitOps is the use of Git to provision infrastructure and manage software deployments. The driving idea here is that although Git was designed primarily to be a tool for managing application source code, it can also be used to control the configuration files that surround application deployments.
The Cloudbees definition of GitOps is grounded in this same idea. However, it focuses more on how GitOps can help developers perform tasks that were traditionally managed by IT Ops engineers. From this perspective, the point of GitOps becomes uniting developer and IT Ops teams to achieve DevOps.
Weaveworks incorporates this concept into its definitions of GitOps, one of which states that GitOps represents "a path towards a developer centric experience for managing applications." However, Weaveworks has a second, narrower definition of GitOps: "an operating model for Kubernetes and cloud native."
In short, then, GitOps could mean anything from simply using Git for tasks other than source-code management, to a strategy for making developers into IT engineers, to a way to manage Kubernetes.
Is GitOps Declarative Configuration Management by Another Name?
Lurking behind all of these definitions of GitOps (although not all of them use this term) is the concept of declarative configuration management. Declarative configuration management means using configuration files to govern the way infrastructure is provisioned or applications are deployed. The core idea is that developers or IT Ops engineers can write configuration files that define how an environment or application should behave, and those settings are then automatically applied.
This approach is the opposite of imperative management, which involves manually configuring each environment or application to meet a desired set of parameters.
Declarative configuration management is not at all a new concept (here's a discussion of declarative configuration from 2009, for example). In this sense, part of me suspects that GitOps is nothing more than a new buzzword for an old idea, or an attempt to bring the concept of declarative configuration management into the DevOps age.
That said, GitOps does at least stand apart from earlier approaches to declarative configuration management in that it centers on a specific tool. (That tool is Git, of course, which is also not at all new--it dates to 2005. However, until a few years ago, it hadn't been widely used for the purposes of declarative configuration management). Git introduces collaboration and version-control features that were not present in earlier approaches to declarative configuration management.
In short, then, I don't think that GitOps is as radically new of a concept as some folks would like to believe. It's really just declarative configuration management by a new name. Still, there are some specific facets of a Git-based approach to this concept that are novel.
Getting the Most out of GitOps
Regardless of how you choose to think about what GitOps means or the extent to which it represents a new idea, actually leveraging GitOps to improve day-to-day operations requires more than just trying to store all of your configuration data in Git and calling yourself a GitOps expert.
Instead, I'd suggest the following as best practices for GitOps.
1. Know GitOps' limits.
GitOps (and declarative configuration management in general) offer important advantages. They make configurations easier to automate and scale because you can write a configuration once and apply it as many times as you want. They also promote greater consistency in configurations.
This does not mean, however, that GitOps is the right approach for every situation under the sun where software or infrastructure has to be configured in some way. For example, if you have lots of different types of environments, each of which needs to be configured in a unique way, GitOps may lead to more complications than it is worth because you will need to maintain different files in Git for each environment.
Likewise, managing secrets (like passwords and encryption keys) in a GitOps-based workflow can be challenging because storing secrets inside a Git repository is not secure. There are ways to manage secrets securely using key management services that run alongside Git, but you have to decide if that extra complexity is worth the benefits that GitOps confers.
2. Know Git's limits.
Along similar lines, it's important to understand what Git itself just can't do well. It can be tempting to think that the goal of GitOps is to use Git just for the sake of using Git, even in situations where other tools would be a better fit. That's a mistake.
For example, consider attempts to use Git not just for managing configurations, but also as a communication tool. Sometimes, developers do this by assuming that every change they make to a configuration within a Git repository will be noted by everyone else, and will in that way provide constant visibility into the entire software delivery process. That's only true if everyone is actually watching Git pull requests closely, which is not always the case.
In other words, while it's good and well to use Git as a centralized tool for managing configuration, it's a mistake to think that it can also centralize communication--or, for that matter, replace other parts of developers' tool sets.
3. Proofread your code.
Proofreading code in configuration files may seem tedious and basic, but it is critical if you do GitOps.
One of the inherent risks of declarative configuration management is that when everything is defined in code, a single typo can have pretty serious consequences. Those consequences may go unrecognized until your configuration has been pushed into production and something breaks.
For this reason, it's especially crucial when using GitOps to code carefully and check for typos. This issue isn't as serious with imperative management, in which case you usually know right away if something doesn't work as expected because you are manually implementing it and watching it go live.
4. Don't let GitOps Kill the IT Ops engineer
As noted above, some definitions of GitOps emphasize the practice as a way for developers to use what they know best--code--to take over infrastructure and application management roles, which were traditionally performed by IT Ops engineers.
That's good and well if it means that developers can play a more active role in configuration management, and thereby collaborate more effectively with IT Ops engineers.
But GitOps can be misused toward a different end, which is to replace IT Ops entirely by having developers do the work that IT Ops would traditionally have performed.
Don't do that. Not only will you probably end up overextending your developers, but you'll also deprive yourself of the infrastructure and application management expertise that IT Ops brings to the table. Just as it's a huge mistake (as Jeff Knupp wisely observed a number of years ago) to let DevOps kill developers, it's wrong to let GitOps kill IT Ops engineers.
Conclusion
GitOps is a great way--in many cases, at least--to manage infrastructure and application deployments in a more efficient and reliable way. But it's not a magic bullet, and it's not the right fit for every situation. Evaluate your needs carefully before jumping on the GitOps bandwagon.
