DevOps vs GitOps (be aware of buzzwords)
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.
According to the article. DevOps is essentially:
- “about culture and methodology, as much as techniques and tools;
- maintains a disconnect between steps associated with development, and steps tied to operations;
- emphasizes deployment with hooks to development, especially in tools;
- relies on scripts and parameters that must be managed; and
- involves a comprehensive toolchain.”
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:
- “a paradigm and technique;
- loosens restrictions between steps tied to development and operations sequences;
- is repository-centric, with configuration files and resource deployment parameters centralized in the same place as application source code;
- emphasizes rapid development and complex changes, and minimizes reliance on complex scripts; and
- emphasizes use of a single tool (Git).”
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:
- First, the development process itself needed a better structure for the complex multicomponent relationships inherent in new application models, wherein services and microservices become the rule.
- Second, in componentized applications, the pipeline between development and operations is much more complicated, because a release is a set of component changes pushed at their own pace through the pipeline.”
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.
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)