GitOps is model driven automation
SE Podcast host Robert Blumen spoke with Alexis Richardson about the origins of GitOps and the separation of the front end process for landing commits and the back end for applying them. Further they explore the concept of convergent infrastructure and applying infrastructure as code to deployments. Tune in to hear how Weaveworks uses GitOps as a disaster recovery tool and helps clients in complex regulatory environments simplifying their cloud native operations.
Software delivery is a constantly changing and evolving set of practices. In recent times, GitOps has emerged as the focus of conversations in the cloud-native computing arena.
Alexis Richardson, CEO of Weaveworks recently spoke at the Software Engineering Radio podcast on the topic of GitOps. In this post, we cover key concepts and ideas as well as similarities and differences between GitOps and other related approaches to software delivery.
GitOps is model driven automation
GitOps is a solution to the management and deployment of applications in the cloud-native space. The formal definition of GitOps is that it is model-driven automation. GitOps makes operations simple for developers who care about deploying their applications and not about infrastructure operations. These developers just want to make changes to the definition of the app.
There are two types of changes to a software system - feature changes, and configuration changes. Feature changes are packaged and deployed in a container, while configuration changes are defined in YAML files in Kubernetes. These changes are made by two different teams.
Previously, when an update was required in one part of the system, the entire system would need to be updated. GitOps, on the other hand, enables a canary release pattern that allows you to change only a single cluster, or a single microservice, leaving the others untouched. If the new change is successful, you can then increase the traffic flowing to the new cluster or service.
Enable App Devs and support Platform Teams
Software delivery teams in large enterprises today are of two types - a platform team, and an application development team. The Platform team builds the platform on top of which applications are deployed. The Platform team releases updates to their platform primarily in the form of upgrades and patches. This platform may be used to run many types of applications created by multiple Application Development teams.
The App Dev team writes code to build applications - for example, machine learning applications. They may update these applications once, or a thousand times a day, and make these updates on the platform created by the Platform team. What’s key to note is that these two teams have a completely different set of priorities, objectives, and practices.
The road to GitOps
There are many hints of GitOps-like concepts in software development over the decades. Mark Burgess’ CFEngine, and Microsoft’s model-driven data center are the earliest examples of automating software development. Following that, Subversion and Git emerged alongside the concept of DevOps which put even more emphasis on automation. These developments gave way to infrastructure as code (IaaC) tools like Puppet and Chef, which have a lot in common with GitOps tools.
The first real modern GitOps solution was HashiCorp Terraform. Terraform calls itself an infrastructure as code tool. The one missing ingredient with this tool is automatic drift correction. This is core to the idea of modern GitOps tools.
Key difference: drift correction
‘Drift’ is the difference between the current state of the system, and its desired state. Modern GitOps tools like Flux CD, Flagger, JenkinsX, or ArgoCD are able to identify drift as soon as it occurs and correct the state of the system to the desired state.
Another factor is that modern GitOps tools are container-native, and built to work with Kubernetes and its ecosystem of tools. While some may find the line between IaaC and GitOps tools to be blurry, GitOps is an extension to the original term.
The 4 laws of GitOps
In an earlier blog post, we spoke about the 4 laws of GitOps:
1. Describe the entire system declaratively.
Git is the best option to describe a system completely. The next best alternative is mercurial. However, it isn’t as widely adopted, and its branching system is not as scalable as Git.
2. Version the canonical desired system state in Git.
This versioning is done not just at the top level but for each component within the system. This ensures the entire system is described declaratively.
3. Automatically apply approved changes to the desired state.
In GitOps, changes are applied using a ‘pull’ model. A GitOps tools continually polls Git repositories looking for changes. When a change is detected, it automatically ‘pulls’ the change and deploys it to a target location.
4. Ensure correctness and alert on divergence with software agents.
Going further than automatic deployments, modern GitOps tools allow you to define and enforce policies for what kind of deployments are to be accepted. Whether this is deploying only container images without CVEs, or ensuring a node has a minimum number of clusters - GitOps can take into account this complexity.
Learn more about these principles in the newly formed GitOps Working Group.
Kubernetes & GitHub are not enough
Some may think that if they use Kubernetes and GitHub they’re already practicing GitOps. However, this is not true. What’s required is a dedicated GitOps tool that can help drive state to the correct state based on how the system is declared in configuration. Similarly, while Jenkins can quicken certain manual tasks, it works only for small scale operations. At greater scale, errors of drift creep in.
GitOps is here today and tomorrow
GitOps makes a lot of things easier. We started hiring developers who were operating our SaaS and making changes to it with no training in Kubernetes…. That is supposed to be a bit of a goal for people using Kubernetes, they just want it to be boring infrastructure.
In his concluding remarks, Alexis highlights that GitOps simplifies managing complex deployments, and complex infrastructure operations.
Listen to the full podcast on the Software Engineering Radio website.
