Pros and cons of GitOps: Why more companies should use GitOps?
DevOps took the tech world by storm. It's hard to imagine a modern development team not taking advantage of its best practices in shaping the deployment process. However, this doesn't mean that everything has stayed the same here.
In fact, DevOps has changed quite a lot since its inception, and it continues to evolve together with the demands of development teams. We have recently witnessed the emergence of brand-new trends such as NoOps, AIOps, and GitOps.
In this article, we're going to take a closer look at the last one, GitOps, and show you what it is, what value it brings to development teams, and the challenges you should know before jumping on the GitOps bandwagon.
What is GitOps?
GitOps is an operational framework that has one goal: to take DevOps best practices used in application development and apply them to the process of automating the infrastructure.
By DevOps best practices, we mean activities such as collaboration, compliance, Continuous Integration/Continuous Delivery, and version control. All of the things that help teams to deliver new digital products quickly and smoothly.
GitOps aims to take this to the next level by applying the same principles and approaches to infrastructure automation. But why is it worth your attention?
Why do teams use GitOps?
To explain the value of GitOps, let's take a step back and start with DevOps.
Most of the time, teams develop modern applications with speed and scale in mind. That's why companies with a mature DevOps culture can deploy code into production dozens if not hundreds of times per day. They achieve this by using best practices such as code review, version control, and robust CI/CD pipelines that help them to automate processes like testing and deployment.
The primary value of DevOps was that it automated significant parts of the software development lifecycle (SDLC). However, it left out one part - the infrastructure.
Activities such as provisioning, managing, and maintaining the infrastructure remain to a large extent manual. These processes require the time and effort of specialized teams. And considering the demands infrastructure needs to meet today, it has become clear to teams that automation is a must-have. Modern infrastructure needs to be flexible and scalable. It should help teams to efficiently manage the resources required for frequent deployments.
GitOps emerged in this context: it promises to automate the process of provisioning infrastructure. Infrastructure teams that practice GitOps can use configuration files stored as code - this is what Infrastructure-as-Code (IAC) is all about. These configuration files generate the same infrastructure environment every single time it's deployed - just like an application source code that always generates the same application binaries every time you build it.
How does GitOps work?
GitOps works well thanks to a combination of two things: an Infrastructure-as-Code system and a CI/CD pipeline.
To get things working the GitOps Way, teams need to create a special mechanism. A system working under GitOps has two types of repositories: the environment repository and the code repository of the application.
- Environment repository – There's only one repository like that in the system. It includes the environment configuration code, which manages the commands and creates the environment. This repository is at the core of the IAC approach. This is the repository into which the developer needs to push the file with the code working as instructions for deployment.
- Code repository of the application – This is the regular GitHub repository that development teams use in their everyday work.
The other component is the CI/CD pipeline. But how do we connect these repositories with the CI/CD pipeline? How can our CI/CD tools know that changes were applied to either the environment or code repository given that everything is based on code now? This is where GitOps offers two types of deployment processes.
Push-based deployment
This is a traditional deployment strategy used in DevOps and with the help of various CI/CD tools. In GitOps, a push-based deployment is simply about pushing code to the repository that goes into the build pipeline. If the code aims to change the environment configuration, the environment repository will be updated. This change will trigger the CI/CD pipeline. Some of the most common tools used for push-based deployments are Jenkins, TeamCity, Travis, and CircleCI.
Push-based deployment is a method familiar to development teams today, but it presents one serious limitation: it's a one-way road. Any change in the environment repository will trigger the deployment pipeline and infrastructure. But if anything happens to the infrastructure itself, we can't really do much. The only thing teams can do to deal with this issue is to manually analyze the infrastructure's state and the current state of the environment repository once in a while. But this isn't a good solution – it only adds more work to DevOps teams.
That's why GitOps doesn't recommend push-based deployments. Fortunately, there's an alternative approach you can use here.
Pull-based deployment
A pull-based deployment works like a push-based deployment with one key difference - it also includes an operator. An operator is a tool that can update infrastructure and monitor it for any unintended changes on a regular basis.
You probably know where we're headed with this. The operator can identify any difference between the deployed infrastructure and your desired infrastructure. Moreover, it acts accordingly to the environment repository in an automatic manner, so there's no need to involve the DevOps team.
The operator can trigger the deployment pipeline for changes but also reach it directly, monitoring it for differences between the deployed and desired state. It can even write the same in the environment repository.
Benefits of adopting GitOps
Easier collaboration on infrastructure changes
Since every single change goes through the same change/merge process of requests, review, and approval, it allows senior engineers to dedicate their attention to other tasks outside of the critical infrastructure management.
Better access control
You don't have to give team members credentials to all of the infrastructure components. All the changes are fully automated, and only the CI/CD tools need access to it.
Faster time to market
Execution via code is much faster than the manual work that consists of pointing and clicking. All the test cases are also automated and repeatable. This helps teams to deliver a stable environment quickly and speed up the overall development process.
Mitigating risk
Since every change to the infrastructure is tracked using merge requests, you can easily rollback all the changes to the previous state. This is how GitOps helps to protect your infrastructure.
Lower costs
By automating the infrastructure definition and testing, you get to eliminate a large volume of manual work. For starters, this is bound to make your development team more productive and happier. Moreover, you will reduce downtime thanks to the built-in revert/rollback capability. Automation also helps infrastructure teams to improve their management of cloud resources that can translate directly into slashing your cloud bill.
Fewer errors
In GitOps, infrastructure definition is repeatable and codified. This makes it less prone to human-made mistakes and errors. Moreover, you can identify them by using code reviews and collaboration in the merge request. This offers teams the opportunity to correct errors long before they make it into production.
Transparency
Since the Git version control system is familiar to everyone in the team, any authorized user can open the platform and review all the changes easily. Such transparency is incredibly useful for new team members who need to get up to speed quickly and understand the overall infrastructure and operations happening prior to joining the team.
Easier rollbacks
Before GitOps, rollbacks were difficult because maintaining the previous version and compatibility of the system was a hard nut to crack. With GitOps, you can roll back to the previous state if something goes wrong in your new state – and you can do that in just a few clicks.
Faster environment duplication
For a team that follows traditional methods of infrastructure development, duplicating the environment for any purpose requires a lot of time and effort. Thanks to GitOps, you can use the IAC approach and duplicate the environment quickly for other teams or regions. Everything will be saved as code inside the repository anyway.
Excellent security
GitOps allows only authorized users to access the environment and apply any changes to it. Moreover, it has proven to be very secure against any malicious attacks or threats like attempts to access repositories with sensitive data.
Easy to audit
When your infrastructure team wants to analyze the changes that were applied to the environment – including how they were implemented and which events were executed at what time - all they need to do is get the logs. All the logs for such scenarios will be available, and your team won't need any external tools. This makes the auditing process much easier and straightforward.
Challenges of GitOps
Applying changes in any kind of collaborative project is always tricky. And GitOps is no exception to that rule.
GitOps represents a process change that requires a lot of discipline from all the participants and commitment to switching their approach. It's essential that teams formalize and write everything down.
While GitOps allows for greater collaboration, it also comes with some new responsibilities. For example, in the GitOps approval process, a developer can apply changes to the code, create a merge quest, an approver merges these changes, and then the change is finally deployed. This might seem tedious and time-consuming to engineers who are used to making fast and manual changes.
GitOps works well if team members record what is happening in merge requests and issues. They might be tempted to edit something directly in production or just change code manually. This will be difficult to suppress, but the fewer attempts at cowboy engineering happen in the team, the better GitOps will work for you.
GitOps is definitely worth your attention
Even when considering the challenges GitOps poses on infrastructure and teams, it's still an approach you should consider if you'd like to take your DevOps practices to the next level. You don't need to write any code differently. And all you need to get started is to have an infrastructure that you can manage with declarative Infrastructure-as-Code tools.
DevOps brings about a cultural change in an organization. It's a proven approach that helps teams work better and faster. DevOps and GitOps share many principles like self-service infrastructure and automation. If you're already actively employing DevOps techniques, implementing a GitOps workflow will be even easier.
If you're looking for expert advice for bringing your DevOps up to speed and in line with the current trends, get in touch with us. At Maxima Consulting, we have been supporting companies across various sectors, from investment banking to renewables, with our expertise, and our specialists know what it takes to make teams successful and productive.
