When I think of the tech world, two things come to my mind – tech people love automation and coining portmanteaus (it’s when you combine two words to create a new one). Just look at words like email (electronic + mail), blog (web + log), or malware (malicious + software) to understand what I’m thinking of.
GitOps is a perfect illustration since it combines both automation and a well-crafted portmanteau. Created by blending words git and operations, GitOps is a relatively new approach to automate infrastructure provisioning.
In this interview, we will speak with Stepan Slyshov, our accomplished DevOps engineer, to explore the core principles and benefits of GitOps, examine the challenges associated with its implementation, and compare it with traditional DevOps practices.
What is GitOps? How does it work?
“GitOps is a set of best practices that can be applied to the whole development workflow, including deployment. It involves tying everything to Git source, which is software that developers commonly use to track changes in code and files.
Similar to how development teams use Git to store application source code, applying the GitOps approach allows operations teams to use Git repositories to store the configuration files that define the desired state of the infrastructure as code. Whenever a new change needs to be implemented, a pull request is made which triggers the execution of the CI/CD pipeline to modify or provision the infrastructure.
Depending on your platform and the software in use, you can mix and match various tool combinations in your GitOps. Here are some examples for different CI, CD and cluster resource generation/sync:
Overall, GitOps is truly a developer-friendly approach since it allows teams to use familiar software development tools to manage application and infrastructure changes.”
What are the key principles and concepts behind GitOps?
“GitOps revolves around the idea of having a single source of truth – a Git repository. At its core, it has three essential concepts:
-
Infrastructure as a code (IaC). In the GitOps model, your entire infrastructure is versioned and stored in a Git repository that tracks all changes made to files over time. This chronological traceability of changes helps greatly in troubleshooting failed deployments, auditing for compliance and security, rollbacks and recoveries if problems emerge.
-
Pull requests or Merge Requests. They are used to implement changes or updates. Every change is viewable and must be verified and approved before going to production. This ensures maintaining version history and allows development teams to collaborate via comments and reviews.
-
CI/CD pipelines. The GitOps approach automates all the updates reflected in the code using continuous integration and continuous delivery. Any changes made to the Git repository trigger the CI/CD pipeline, which automatically deploys approved and merged updates to the desired Kubernetes cluster or target environment. In this way, deployment changes are broken down into smaller chunks that are frequently pushed and tested, instead of waiting for a large release to be shipped to test and monitor changes.”
What tools and technologies are commonly used to build an effective GitOps environment?
“As you can see, GitOps cannot be implemented using a single platform or application. Building an efficient GitOps environment requires a combination of tools and technologies that facilitate version control, infrastructure management, and CI/CD.
Among the most commonly used tools are of course Git, which is the heart of GitOps; container orchestration platforms, both cloud and on-premises, like Kubernetes or Openshift; deployment tools like ArgoCD and FluxCD; and Kuberenetes-oriented utilities like Helm, Kustomize, Werf or Jenkins X.”
What are the major advantages of implementing GitOps in a software development workflow?
“Applying GitOps can benefit both operations teams and companies that want to produce high-quality software faster. Based on my personal experience, I’d like to highlight the following GitOps advantages:
-
Enhanced change management and security by centering workflows around Git. Having the application, infrastructure, deployments, and security policies stored in a single location helps to increase the manageability of all resources significantly. In addition, Git provides robust access control and permission management features, ensuring that only authorized individuals can make changes.
-
Greater transparency, reliability, and stability. GitOps provides a clear audit trail, change history, and the ability to track and review modifications made to the system. This version-controlled infrastructure approach makes it easier to audit changes and roll back to the previous stable state of the system within minutes if a problem occurs.
-
Consistency across all environments. In Gitops, you can take advantage of containers and microservices and define all environments as code using a single model for deploying the environment.”
What are some drawbacks or challenges you’ve encountered when implementing GitOps?
“While GitOps offers many benefits, it also presents a certain number of challenges for developers when implementing or operating the GitOps workflow. Some of these challenges include:
-
Discipline is a must. Since we rely on code everywhere, discipline from everyone involved is crucial for an effective GitOps workflow. It works well only when everyone on the team makes sure to write everything down. The less editing in production or sneaky manual changes in code, the better GitOps works for you.
-
GitOps can be time-consuming. With complex environments/infrastructures, changes can take more time due to having a lot of different repositories and approval processes.
-
GitOps often requires extra tools. As mentioned before, GitOps is not a single framework, but rather a set of practices that involve the use of several tools. The key to a successful GitOPS workflow is to find tools that are compatible and integrate well with each other. For instance, aside from Git and CI/CD tools, you will often have to integrate additional tools for tasks like secret management or authentication as they are often not supported natively.
-
Git is not always a single source of truth. While the goal of GitOps is to have a single source of truth in the Git repository, the reality of container-based deployments introduces container registries as an additional component. Despite the automation efforts, there are still moments when the container image in the registry or the one deployed does not correspond to the declaration we have in the code.”
How does GitOps differ from traditional DevOps practices? Would you say that GitOps complements or replaces DevOps practices?
“GitOps can be viewed as a part of DevOps, a way to implement some of its main goals and principles with an emphasis on Git and the use of specific tools. Although both approaches share common goals, I think that two key differences set them apart:
-
Main focus. While GitOps is more focused on automation and leveraging certain tools, DevOps puts more emphasis on collaboration between different people/departments when performing their tasks.
-
Tools and Technologies. GitOps is associated with using Git, containers, clusters, and technologies like Kubernetes. In contrast, DevOps isn’t bound to particular technologies and can be applied to any kind of infrastructure.
Ultimately, I’d say that these approaches complement each other, but deciding which one will play better in your scenario depends on the project needs and priorities of your organization.”
Are there any areas where traditional DevOps practices may have an edge over GitOps?
“Well, there are some scenarios where traditional DevOps practices may be a better fit. Logically, GitOps will not be the best choice if your workloads do not involve Kubernetes or containerized applications in general. In addition, GitOps relies on human-driven changes by creating pull requests, and their manual review and approval processes. Therefore, if there is a need for programmatic updates and automated commits to create pull requests or resolve conflicts, GitOps may not be an ideal option. In these cases, extra tooling or custom complex scripting may be necessary to handle these scenarios.”
Based on your experience, what advice would you give to teams looking to adopt GitOps in their workflows?
“If you’re considering implementing GitOps, it’s crucial to make sure everyone understands what it means and keeps away from direct manual changes. Having alerts for any manual interference with your infrastructure, particularly in production and staging environments, is essential – especially if you’ve only recently transitioned to GitOps.
Given that you’re likely working with Kubernetes, it makes sense to incorporate tools such as Helm and ArgoCD/Flux in your workflow. They can save you a lot of time in the long run through their templating features and offloading the deployment stage to a specific CD tool that is specifically designed to work with Kubernetes. As an added bonus, the visualization capabilities of Argo are particularly impressive.”
Thank you, Stepan, for sharing your valuable insights on GitOps and comparing it with DevOps.
To sum it all up, GitOps is a relatively new framework that has its pros and cons and is applied for managing and automating infrastructure and application deployments. Traditional DevOps practices and GitOps are not mutually exclusive and their coexistence can be beneficial to organizations. Deciding whether to combine both approaches or select the most suitable one for your case will hugely depend on the specifics of a certain project, automation needs, and team preferences.