In the world of DevOps, new terms and tools emerge regularly. Often announced as revolutions, they are however very quickly forgotten to be replaced by new phenomena. Nevertheless, some of them remain, like GitOps.
First of all, let’s remember the objective of DevOps: to unify the development and operations teams through automation, management and monitoring, with the aim of accelerating and optimizing the production chain and delivering the application more quickly. DevOps is a set of tools, best practices and methods.
To understand how we got to GitOps, we need to understand a concept that has been around for a few years and that represents the latest big revolution in the DevOps world: infrastructure-as-code. This practice simplifies the management of IT infrastructure and facilitates consumption by teams. To make this concept as simple as possible:
Ops teams write infrastructure models (Linux, Windows, etc.) in standardized files;
The Dev teams use the files written by the Ops teams, attaching a configuration file to customize the infrastructure they need;
The symbiosis of the two files allows the provisioning of the requested infrastructure and gives birth to a new file, unique, serving as an identity card for the environment created.
In short, three files contain all the information needed to create a single environment. GitOps makes it possible to store these files in a repository and to monitor their evolution.
This approach, which could be formulated as “Infrastructure as Code + CI/CD + Merge Request” allows for better productivity by accelerating development and deployment, while improving the stability and reliability of the cloud infrastructure.
But how do you take full advantage of GitOps? What are the benefits? And finally, what differentiates this approach from DevOps?
GitOps, the cloud cookbook
The actions required to deploy and configure cloud infrastructure and applications are stored in files. One could imagine a recipe book, which the tools will read and execute in order to obtain a cloud in an expected state.
To change the expected state (e.g. change the version of a tool, add a user or secure applications), developers and administrators will modify these files. As soon as these changes are “pushed”, i.e. decided to be part of the “expected state of the cloud”, tools will detect these changes and execute the necessary actions to make the cloud platform conform to these expectations.
It’s not about the tool, it’s about the goal
The GitOps paradigm serves several purposes:
Limit downtime: whether there is an outage, an update to be performed, maintenance, or the deployment of a new solution, an unavailable platform prevents teams from working or even customers from accessing services. By automating the deployment, configuration and testing of a cloud platform, and letting the tools orchestrate the operations, we ensure rapid execution and delivery with a much higher quality. In short, a stable and functional platform with much shorter downtime.
Limit errors: writing actions and configuring tools allows you to have a single source of truth, to be able to track changes and therefore to set up testing, quality and approval procedures upstream. It is no longer necessary to wait until an error has been deployed to realize that something is wrong.
Secure state and agility: Because the state of an infrastructure is stored in a version control system, there is only one place to look for the overall state of the environment. In the event of a problem, you can revert to an older version quickly and accurately. Similarly, a patch for a critical security flaw can be applied, tested and validated in a matter of moments.
The most important thing is to be able to deploy and replicate an infrastructure, an environment, simply and iso.
GitOps is very different from DevOps
GitOps and DevOps approaches share common principles, tools and goals. While DevOps encourages a cultural change in the way operations and developers collaborate, GitOps offers a set of tools and best practices to optimize collaboration between the two teams, allowing each to work with their own code and repositories, but with the common goal of working together.
In summary, the benefits of implementing GitOps practices are significant, including tracking changes (who, what, when?) and rollback in a quick and easy manner; ease of management for complex projects and large teams; and a repository that contains all of the code, configurations, inventory and status of the environment. A single source of truth. On the other hand, it will also be important to strike the right balance between efficient processes and the complexities of team tracking and enforcement.