Wait, Do We Need to Hold Up on GitOps? – InApps Technology 2022

Earlier this year, Thoughtworks Radar issued a striking verdict on GitOps. The Radar, which brings a panel of expert opinions to bear on developer tools, techniques and more, declared GitOps a “Hold,” meaning teams should “proceed with caution.”

For years now, blogs, webinars and white papers have opined that GitOps is the Next Big Thing, yet here a respected voice in the field is saying to tread carefully. So what gives? Do we need to pump the brakes? Is GitOps just a lot of unwarranted hype? Or is there a missing piece of the puzzle here? As in so many things, the answer is: It’s complicated. GitOps can be transformative for some teams, but it’s not a one-size-fits-all solution.

A GitOps Refresher

It’s worth pausing to briefly define GitOps, because underneath a deceptively simple moniker lies a whole-cloth reframing of the software development and delivery paradigm.

The purpose of GitOps is to create an operating model for continuously developing and delivering software in a system with a “single source of truth,” that is, a definitive, declared state toward which the system converges. Typically, this means using Git in conjunction with Kubernetes, the declarative and convergent nature of which is well-suited to the job.

With the powers of version control and container orchestration combined, every change to a system configuration may be observed, monitored, traced and used to trigger some other programmatic action. All the metadata associated with a Git commit follows every modification, and every modification can be tracked or rolled back, which dramatically lowers the risk of making changes in the first place. In theory, it’s an “undo” button for everything.

And that gets at the point and appeal of a single source of truth. You write code to the single source, and the system converges to the ideal. You fix a bug in that one spot, and the system converges again. The idea has an almost mythic appeal, but the tangible benefits are clear too: Teams can deploy much more frequently. Debugging, likewise, ought to be much swifter, with only a single codebase to inspect. If a change to the system causes a crash, recovery is a rollback away.

So with all of these benefits, it sounds like it’s time to plop the whole world into a Git repository, right?

When the Model Meets the World

The viability of GitOps is ultimately going to depend on the context in which you’re trying to apply the model. And this is a question with a lot of dimensions:

• Does your team have the skill and time to make the transition?
• Do you have idiosyncrasies in your data center that you need to accommodate?
• How about your application use case? Are you working with monoliths or legacy systems that probably aren’t going to go gently into version control?

These are the kinds of questions that arise when a beautiful operating model comes up against a messy world. One specific version of the context question presents perhaps the most widely-discussed challenge in implementing GitsOps: How should a team propagate changes from one environment to the next? Say, from a QA environment to production?

It’s not an unsolvable problem, but it often means adding more tools to the mix, or using multiple branches in a pattern that introduces opportunities for configuration drift. More and more, folks who are thinking about GitOps note that this multibranch approach should be avoided, and indeed it seems to lie at the crux of Thoughtworks Radar’s hesitance.

GitOps for Me, Maybe for Thee

You can see how the Radar reached its conclusion. At present, “GitOps” is a big tent with a lot of exploratory implementations of a big, beautiful idea. While we can find some general community consensus on more and less successful approaches to the model — and branching to accommodate multiple environments is definitely on the less successful side of the ledger — we don’t have a set of detailed, definitive best practices. OpenGitOps is a step toward that end, establishing general principles and terms, but it hasn’t yet gotten down into the nitty-gritty.

However, we shouldn’t over-extrapolate from a “Hold” verdict. “Proceed with caution” means just that: You don’t want to rush in without expertise and a firm, specific idea of how your organization will make the transition, and how your organization specifically will benefit. We need to be thoughtful in our implementation and understand the complexities up front.

GitOps is meant to scale and not suffer from vendor lock-in. It’s an operating model that is going to be easiest living on top of managed infrastructure as code, such as (ahem, shameless plug) Mirantis Flow. Some teams have the requisite expertise and agility to define an operating model and work in a single environment. If they’re so inclined, they should consider GitOps a go. Other organizations that like the idea in principle may find that their specific environment and needs just aren’t conducive to it. Still others may want to achieve that single source of truth, but need an infrastructure partner to help make it happen.

In the end, the important thing is to make sure the benefits align with your use case. It’s easy to become enamored of an elegant idea (I’m still over here flying the flag for static site generators), but the key is to ensure that the model fits in your context and is suited to your purposes. By definition, a “Hold” on the Thoughtworks Radar is a technique that is “interesting” and to be approached “with a degree of care,”  in contrast to “Adopt,” which suggests that something should be a de facto standard for the industry. That sounds about right, but care isn’t a stop sign. Look at your applications, look at your infrastructure and if it makes sense for your team, commit away.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Mirantis.

Photo by Alan Cabello from Pexels.