In this review, we will have a look at what is GitOps and we will review why it should matter to you. In the previous post, we uncover how you can quickly build an automated CICD pipeline, now let’s review this concept in a deeper level.
1. What is GitOps?
GitOps is a new method of Continuous Deployment that uses Git as a single source of truth for declarative infrastructure and applications, providing them both revision and change control. Here are some other ways to interpret what is GitOps:
- A set of practices to manage infrastructure and applications using Git
- Using Git everywhere from development to deployment
- A paradigm or a set of practices that empowers developers to perform tasks in IT operations
This is how GitOps looks like in a development process:
- Code: Application code and Pull/Merge Request on Git (Github / GitLab etc).
- Build (CI Pipeline): Write declarative build pipeline code such as yaml in Git to build and automate your builds (GitHub actions / Circle CI / GitLab CICD Pipeline / TravisCI)
- Provision (Infrastructure as code): Write Cloudformation template (in AWS, yaml format), Ansible Playbook (yaml) for a terraform file (HCL language, yaml format) in Git to provision a cluster such as Kubernetes or compute instances on cloud (EC2 / GCE / AzureVM)
- Deploy: Write a deployment manifest (yaml format) for Kubernetes or other resources depending of the type of application / packages / artifacts / container images for ECS / ECR / ElasticBeanStalk etc.
2. GitOps history
Back in 2017, Alexis Richardson at Weaveworks described the GitOps pattern, mainly a way to do Kubernetes cluster management and application delivery. Since then, GitOps concept has been growing steadily and globally.
Two recurrent tasks in operating and managing computer systems are software development and infrastructure configuration:
- The infrastructure part prepares computing resources such as servers, storage and load balancers.
- The software deployment part is the process of using a specific version of a software application and making it run on the computing infrastructure.
Managing these two processes is the main goal of GitOps.
3. GitOps vs DevOps
These 2 concepts are strongly linked to one to another but they are significant differences between GitOps and DevOps.
Something to keep in mind that is DevOps is mix of development, operational, tools and culture that helps organisation to develop, improve system / software at a faster pace of delivery. On the other side, GitOps is tied to Git tool only.
GitOps builds and iterate on ideas drawn from DevOps and Site Reliability Engineering that start with Martin Fowler’s comprehensive Continuous Integration overview in 2006.
| DevOps | GitOps | |
| Focus | Automation and frequent deployments | Correctness, doing DevOps perfectly |
| Flexibility | More open, less strict | Stricter and less open |
| Approach | A culture that focuses on CI/CD | A technique and process that uses the tool Git to manage: – infrastructure provisioning – software deployments |
| Main Tool | CICD Pipeline | Git |
| Other Tools | Cloud configuration as Code | Kubernetes Separate CICD Pipelines Infrastructure as Code |
| Accuracy | Focus less on accuracy | Accuracy in mind |
4. GitOps challenges
GitOps is a process change that will demand and require discipline from all teams and participants and a commitment to build things in a new way. With any collaborative effort, it is important for teams to write everything down.
GitOps enables greater collaboration, however, that’s not necessarily something that comes easily from individuals or organisation. The approval process means that developers make modifications to the code, create a merge request, an approver merges these changes and the modification is deployed. The whole sequence add “change by committee” part to the infrastructure, which can be time consuming and tedious for people who are used to make quick manual changes.
At the end, it is important for everyone in the team to record what’s really going on, in merge request and issues more specifically. The attraction to add, edit something on the fly in production or change resources is always an obstacle / habit hard to suppress at first. The less manual changes, the better GitOps practices will work.
5. Why GitOps should matter?
GitOps Is quite important because, by declaring your infrastructure as code, it allows traceability of modifications made to an environment. It also enables easy rollback, recoverability and self-healing using a single that most of developers are familiar with: Git.
Developer Benefits of GitOps
In a traditional operations model, infrastructure management is performed by a specific team within a company. The main problem of this approach is in its scalability, this team will quickly become a bottleneck, no matter how many members it has. Regardless of process, that barrier would introduce a lot of friction and discourage the team from proactively offering infrastructure changes. GitOps aims to break the barrier by automating and making it self-services.
Another advantage is to perform code review which lead to fewer preventable outages. Code reviews provide also the following additional benefits:
- Teach and share knowledge.
- Consistency in design and implementation
- Team cohesion and collaboration
Operational Benefits of GitOps
One of the more prominent example to merge from the DevOps movement is the model of declarative systems and configurations. In another way, with declarative models, you describe what you want to achieve, opposite to how to get there.
GitOps also provide observability to operations. Observability is the possibility to examine and describe the current running state of a system and be alerted on unforeseen conditions. By storing your desired state into one system (Git) and regularly comparing that desired state with the running state, you unlock a new dimension of observability. Finally, GitOps grandly speed the process up for Auditability and Compliance processes.
Regarding Disaster Recovery, GitOps aids in the recovery of the infrastructure environment by storing these declarative specifications of the environment under source control as a source of truth.
