DevOps vs GitOps
Most firms do not have viable or efficient Development-Operations processes. From managing code to integrated branch-trunk strategies, through to integrated testing and rollbacks, the ‘pipelines’ in most firms are immature. There is therefore some needed scepticism when, yet another buzzword or acronym is introduced into the dictionary of programming. GitOps is now being forwarded to ameliorate some of the issues with DevOps. The problem for most firms is that changing buzzwords resolves nothing; and not understanding current issues with the development-operations process is unlikely to be resolved by trying a different chain of processes.
The Claim
According to the article. DevOps is essentially:
There is nothing wrong with the above list. DevOps is based around Agile principles which are mainly organisational and cultural in their challenges. It demands automation and proper use of standard tooling.
According to the article, by comparison, GitOps is essentially:
The only real difference I see with DevOps is the use of Git as the central code repo.
According to the article however, there are some important differences between the 2 approaches.
GitOps origins: How DevOps spawned GitOps
“DevOps was the industry’s first attempt to create a fluid pipeline from development to operations, throughout which essential application characteristics and configuration needs are passed from one team to the next. Nearly all popular DevOps tools convert developer-created instructions into deployment steps; this is the baseline set of requirements for effective integration of development and operations.
The advent of highly componentized applications and CI/CD — or rapid development — raised two important points in this integration:
Both of the above are correct. But what does GitOps offer which is different? According to the article, the revelation is a shared repository.
“The logical solution for both of these challenges is to centre both development and operations on a shared repository — a single source of truth that guides all development and operations activities individually and connects them through a pipeline, and provides an audit trail as well. The Git repository has been the dominant choice to store version-controlled code; many organizations began to build an enhanced set of development tools and practices around Git. To build a similar IT operations practice centered on Git, and to pipeline the two together based on Git exchanges, is a clear choice. This is how GitOps was born.”
This is not new. You can centralise your code repo in any number of Cloud-native repositories (CodeCommit) or open-source (SVN on EC2). So, the above is hardly adding value.
Buzzword Bingo
The article maintains – erroneously – that DevOps is focused on Operations. This is rather specious. DevOps is primarily a dev approach and in reality, the real issues are always with Operations. In fact, the article’s assertion is backwards. The main focus of DevOps is Dev and the ‘forgotten man’ is usually Operations. Integrated testing is for example, a major area of weakness in DevOps, along with the Ops model. In the real world, Developers will only support a deployment for a finite period before they move on to either build new functionality or apply their skills on another project. The Operational-run book model is often missing, and the costs associated with operational management over the long-term usually unaccounted for.
The bottom line is that promoting GitOps will not solve your problems with DevOps. Buzzwords and jargon do not replace IT engineering.
(note: the Gitops pipeline fits into the DevOps pipeline, they are not exclusive nor unique, so the above diagram is wrong)
