It’s been roughly ten years since the term ‘DevOps’ was first coined, and there has since been a flurry of ‘____Ops’ buzz words that have laid claim across the industry. You know, FinOps, ChatOps, DevSecOps …. just to name a few. One of the latest Ops-suffixed phrases to gain traction is, of course, GitOps.
Let’s look at what GitOps is, what it isn’t and whether it’s something you should look at implementing in your organisation.
The low-down on GitOps
GitOps isn’t a ‘thing’ but rather a way of working, or set of principles, intended to give developers the power to automate Kubernetes infrastructure and deliver applications with speed and scale. At first glance, it’s fairly straightforward. GitOps is very much oriented around using a version control system (such as Git) to house all the code for your infrastructure, and then uses automation to apply it alongside any changes that are made.
Principles of GitOps
According to Weaveworks, whose founder is attributed with first coining the term, there are four pillar principles to successfully implement GitOps.
- Declaratively describe the entire system
- Version the canonical desired system in Git
- Automatically apply approved changes to the system
- Use software agents to alert on divergence and ensure correctness
At this point you might be asking yourself the question, ‘wait, isn’t this just spelling out infrastructure as code?’ And you wouldn’t be wrong … at least sort of.
IAC vs. GitOps
Infrastructure As Code (IAC) has been around for a long time — a quick Google search will return the usual suspects of Terraform, Ansible, Chef, etc… It could be one of the main reasons a new term was coined, there simply wasn’t enough room for the next evolution of IAC to exist in the same space, which is essentially what we have now with GitOps. And, in fact, Priyanka Sharma, General Manager at CNCF, says that the GitOps workflow concept was effectively created by “everyone who successfully did infrastructure-as-code.”
There are a few elements that set GitOps apart from IAC:
1. GitOps focuses on containers as the deployable artefact. These are then scheduled through an orchestration layer such as Kubernetes, a style of infrastructure as code designed with the cloud native era in mind.
2. GitOps uses merging and pull requests to deploy Kubernetes. These are processes developers are familiar with bringing the whole workflow closer to them.
3. Confusion starts to arise when you need to manage many layers. For example, creating the underlying infrastructure for Kubernetes might consist of multiple linked repositories and databases. Layer on even more declarative YAML for GitOps processes, and you run the risk of having far more configuration code than lines of application code.
When your config code outweighs your application, you need to ask the question: Is it delivering enough value for the effort involved? Where do you draw the line?
Enter: Cloud Providers
It might be natural to look to the cloud providers to shift responsibility of the underlying infrastructure in the form of EKS, AKS and GCP.
This is a great start to simplifying GitOps adoption and will hugely reduce the amount of underlying infrastructure code that needs to be managed. So, you can get on with delivering the unit of value in the form of applications without worrying about everything sitting underneath it.
Although the cloud providers simplify the underlying infrastructure, there is still a lot of complexity that needs to be managed, such as configuring VPCs for your clusters, setting up node groups and handling autoscaling — just to name a few. Spread this over a couple of cloud providers and you end up with a host of complexities. At this point you might want to consider a platform to remove another layer, abstract some of the complexity away and further simplify GitOps adoption.
Should you be using GitOps?
Without a doubt, GitOps is an incredibly powerful practice to manage Kubernetes and modern cloud infrastructure.
But the decision on whether or not to start using it in your own organisation should ultimately come down to what you need to manage and how much you want to manage. If you can abstract enough complexity and infrastructure layers away, GitOps could be your new best friend or, alternatively, leave you with mountains of code to manage.
How to simplify GitOps with Kore
Kore Operate is a cloud-native platform that abstracts away a lot of the complexities, and knowledge needed, to set-up, run and manage Kubernetes clusters. To showcase how Kore can simplify GitOps, here’s a demo utilising the Kore Operate platform to self-serve multi-cloud Kubernetes clusters and build, promote and deploy an application using a full GitOps pipeline.
