The GitOps medicine is tooling

A couple of recent articles and some conversations with current colleagues have caused me to revisit how I think about and explain GitOps.

Steve Smith's 'GitOps is a Placebo' is critical of GitOps in several ways that I disagree with, but the most important of which is that I think the author missed a couple of things - where the industry really is in the lifecycle of continuous deployment tooling and one of the things that I think of as a key benefit.

GitOps is not a Placebo

I really disagree with the Placebo premise, however pithy it is. To adopt GitOps one must do more than follow the Continuous Delivery approach, really, really well - you have to take the actual medicine, which in this case is Argo, Flux, Atlantis etc.?Yes, one could hand-craft a GitOps implementation as Vic Iglesias describes using Jenkins in 'GitOps Demystified', but one should really not do this.?

The reason why can be found in the principles that are expressed in Wardley Mapping. Simon Wardley's approach identifies four different phases: genesis, custom, product and commodity.

The capabilities described in Continuous Delivery literature have long been implemented with organisation-specific custom solutions built around CI technologies (often by experts like Steve Smith) - but products have emerged and are starting to mature.

I'd encourage readers to look at the table themselves and consider GitOps in the light of the categories, in particular 'Publication Types', 'Market' and 'Comparison'. Steve Smith's article itself appears to be a match for 'Perception in Industry', where the discussion is a form of "this model is better than that".

If one takes Steve Smith's assertion that GitOps is nothing more than a form of Continuous Delivery, the implication, per Wardley Mapping, for those wanting to implement Continuous Delivery is that they should adopt products rather than develop custom solutions.

i.e. Take the medicine, not a sugar pill.

Separation of Concerns

Aside from the time/cost benefit of adopting a product versus developing a custom solution, for me the standout benefit that Steve Smith misses is the clear separation of concerns between CI and CD in the GitOps model.

The common approach of using the CI tool to perform CD makes it too easy for teams to make poor decisions about implementing CD, such as storing critical system/environment credentials insecurely in a CI tool.?

A GitOps product that can use service accounts and run within the infrastructure itself means a reduction in need for critical credentials to be distributed to agents and systems outside of the infrastructure boundary.

Software Supply Chain

Recent advancements in thinking about Software Supply Chain Security will lead to further changes in our collective approach - I believe the necessity for automation and standardisation can partly be met using GitOps tools.?

Most of the language in the recent discussions about Software Supply Chain Security has focused on technology and trust, but I expect this will soon regularly include the terms 'provenance' and 'lineage'.

Git itself and the commonly used Git-based workflows are an excellent foundation for establishing the patterns we'll need to deliver both provenance and lineage. GitOps, as an opinionated approach to managing infrastructure, offers itself as one of the patterns that will contribute to the emerging supply chain story.

Summary

Adopting Git-based workflows and a GitOps tool encourages desirable behaviours and processes - it's an opinionated approach that may be considered as existing within the space defined by Continuous Delivery.

Despite the common refrain "it's not a silver bullet", I don't see anyone claiming that GitOps is - and it's pretty common to see logical fallacies in negative diatribes about it.

For me, there are harder problems to solve today than deployment, looking for products and patterns that help with that is common sense. The GitOps ecosystem is an increasingly rich source of those things and I believe the approach can be foundational to improvements in securing the software supply chain.

Links

• Simon Wardley's mapping phases
• Docker: Secure Software Supply Chain Best Practices
• CNCF: Software Supply Chain Paper
• Google: Introducing SLSA, an End-to-End Framework for Supply Chain Integrity