is now
Editor’s note: This interview with Viktor Farcic was recorded for Coding Over Cocktails - a podcast by Lonti previously known as Toro Cloud.
What is GitOps and why is it such a big deal?
According to Weaveworks, the company who coined the term "GitOps", defining the term is two-fold.
First, it is "an operating model for Kubernetes and other cloud native technologies, providing a set of best practices that unify deployment, management and monitoring for containerised clusters and applications".
It is also "a path towards a developer experience for managing applications; where end-to-end CI/CD pipelines and Git workflows are applied to both operations, and development".
Viktor Farcic, a Principal DevOps Architect at CodeFresh, describes GitOps from a practical standpoint.
"Essentially, GitOps is all about making sure that Git is your source of truth at least for the desired state for our intentions, not necessarily for what something is, but what we want something to be." Farcic shares during an interview on Coding Over Cocktails, a podcast by Toro Cloud.
He argues that GitOps is the enforcement of the idea that, if you write code, the code needs to be in source code repository. Whilst source code repositories have evolved over time, Git is "(effectively) the only version control system we have today."
Is GitOps just Infrastructure-as-Code?
Infrastructure-as-Code (Iac) allows organisations to develop, deploy, and scale cloud applications by automating how infrastructure is provisioned. This allows DevOps teams to create and version infrastructure to avoid inconsistencies among IT environments.
While GitOps sounds very much like IaC,GitOps can be considered as an extension of IaC. It is a prescriptive style of IaC for the cloud native era, combining orchestration, observability, declarative infrastructure as code, containers, immutable infrastructure, and DevOps’ best practices.
When asked if GitOps and IaC are one and the same, Farcic has this to say:
"GitOps is becoming very popular. And then different software vendors, you know, everybody's trying to jump into that wave to get some benefits. And then we're all redefining what it is, depending on what our software does and that there is always such a conflict going with everything new and according to some points of view."
He further states that GitOps isn’t necessarily new, nor is it necessarily something that has to happen, but it is definitely something that’s beneficial.
"I don't necessarily see it as a requirement. If you would be applying those changes by receiving notifications from Git instead of you detecting changes in Git, and you would not allow anybody to do many or changes in your infrastructure, you will still get to a similar place. But it is definitely beneficial, I would say, rather than a rule to have that type of processes that are monitoring your Git repository all the time and trying to figure out what changed it." he added.
How can your organisation implement GitOps?
GitOps isn’t just one single platform that you can plug-in and implement – rather, it is a set of workflows aimed to manage your IT infrastructure through processes that they already use during development.
It requires the following core components, as illustrated in the formula below:
Let’s delve into how each component contributes into GitOps as a whole.
-
Infrastructure as Code (IaC)
IaC describes how infrastructure configuration is kept as code. Because GitOps utilizes a Git repository as the "single source of truth", you can use Git to track code management changes, as well as a Git repository (which is a .git folder), that tracks all changes made in a project.
-
Merge Requests (MRs)
Merge requests (MRs) allow for teams to work together through reviews and comments. This is also where approvals can take place. GitOps leverages upon MRs for code reviews, while also functioning as an audit log where all assignees and reviewers are indicated.
-
Continuous Integration and Continuous Delivery (CI/CD)
To automate updates on infrastructure, GitOps utilises a Git workflow with a CI/CD pipeline enacting the change when a new code is merged. GitOps automation also overwrites any configuration drift, manual changes, and/or errors, ensuring that the environment converges on the state as defined in Git.
Should you buy into the GitOps trend?
When an organisation has embraced IaC, collaborating through merge requests, as well as implementing CI/CD, then it is consequently easier for them to move into a more GitOps-focused culture.
While, as mentioned, the concept of continuously monitoring changes within a repository isn’t new, Farcic has observed some movement within the industry which may indicate the direction that GitOps is headed to.
"When we were all using Chef or Puppet for infrastructure, they had those things basically which were removed later on with Ansible and Terraform. There was a server where that would be receiving your changes stored in a code repository and continuously monitor for those drifts." he says.
Devops is now seen moving away from proprietary formats and definitions of public cloud providers, and moving towards solutions such as Terraform or Ansible for designing IaC environments for automation. There’s also Pulumi, and most recently, Crossplane.
"On one hand we have Infrastructure-as-Code that is declarative, that would be Terraform, Ansible in the past, and Crossplane that you just mentioned. On the other hand, we have Pulumi, which takes a different approach, meaning you can use your favorite programming language as long as it is supported by Pulumi to write code, basically Azure infrastructure. So, that would be one distinction and one different path that they're taking." Farcic describes.
He further explains that these tools can potentially help a lot in moving towards having self-sufficient teams using a single interface to do everything.
"On top of that, we have all the things that Kubernetes gives us: ecosystem. That is probably the biggest one right now and then plugging yet another tool, like in this case, infrastructure-as-code, into that ecosystem is potentially very good." he says.
The future is simplification
Farcic says that simplifying all of this should be the end goal.
"What I think we need the most right now is a layer on top of Kubernetes. Something that will simplify it. The reason why Docker became so popular is that they created something that is extremely user-friendly and very easy for almost everybody to learn in almost no time... I think that whole idea died over time because making something easy that will satisfy 80% of people, but will not satisfy those 20% that actually matter for those types of work, like SysAdmins and whatnot. It was bound to fail." Farcic explains.
"Then we got Kubernetes which satisfies those 20% right? It gives us all the power in the world. It allows us to do things that we could never imagine doing but it failed to make it simple. Basically, we can think of Kubernetes as cancelling the shift left movement that started a while ago, right? It cannot go left anymore because it's too complicated now. But with Kubernetes, we got that solid base. Hey, everything is possible. It is designed to be extensible, but the result of extensibility is complexity. Now we need that additional layer that will make Kubernetes transparent. " he adds.
If this simplification is achieved, Farcic predicts that many people will not even know that they’re running Kubernetes in the future – it’ll just become a transparent implementation detail that simply exists.
Coding Over Cocktails is a podcast created by Lonti previously known as Toro Cloud, a company that offers a low-code, API centric platform for application development & integration.
This podcast series tackles issues faced by enterprises as they manage the process of digital transformation, application integration, low-code application development, data management, and business process automation. It’s available for streaming in most major podcast platforms, including Spotify, Apple, Google Podcasts, SoundCloud, and Stitcher.
