The 4 Levels of GitOps Maturity
GitOps is fast emerging as the gold standard for operating and deploying Kubernetes applications and clusters. Objective measures of GitOps success are largely determined by DevOps-related metrics. These DevOps metrics include velocity, frequency of deployment and time to repair. These metrics are closely correlated with business and competitive success: Organizations that can deliver software better, compete better.
What has been lacking is an approach to help teams understand how to use GitOps effectively for their organization. This can determine—among other things—to what degree GitOps best practices and operational efficiencies have been adopted and should be adopted. To that end, the recently created GitOps Maturity Model serves as a four-stage approach that organizations commonly transition through when adopting GitOps. It can be used as a guide for organizations as they move from using GitOps to manage single clusters and applications to managing large-scale deployments of hundreds or even thousands of clusters.
According to Thoughtworks author Martin Fowler, a maturity model “is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance.” The GitOps Maturity Model, in this context, is a simple model that an organization can use to determine where it is in terms of GitOps adoption. The model runs the gamut from the most basic (i.e. storing definitions in Git and pushing with a CI system without ongoing reconciliations) to the most advanced level (the ability to rely on GitOps to scale deployments across thousands of clusters).
Leveling Up
The four stages of evolution that the GitOps maturity model represents and through which organizations commonly go as they develop and gain more value from GitOps include:
Level 0: Organizations have moved to cloud-native and containerized infrastructure, and are storing deployment configuration in git, but are not reconciling continuously. These teams can reap some benefits such as faster provisioning of infrastructure, repeatability and immutability.
Level 1: At this level of GitOps, the teams are deploying applications using GitOps and using reconciliation and drift detection to ensure that running applications are continuously in sync with the desired state as stored in git. A secure GitOps delivery pipeline allows teams to use automation and standardization to dramatically increase deployment frequency, visibility and auditability of operations as well as reduce cost and mean time to recovery (MTTR).
Level 2: At this level, an organization applies the GitOps concepts of process standardization, automation, control and security across an entire environment, including cluster creation and management. This enables benefits for the whole infrastructure and applications, allowing teams to work more autonomously. Platform operations can fulfill governance, risk and compliance protocols and scale the number of clusters without needing to grow their teams.
Level 3: At this level, an organization starts to manage fleets of clusters using GitOps to create consistency, clear policy enforcement and velocity at scale. These organizations can benefit from cross-cloud vendor choices, advanced policy models, scaled deployment, visibility and control for thousands of clusters.
Moving Beyond the Basics
In addition to evaluating where an organization is in its GitOps journey, the maturity model is also a useful tool for deciding on the next steps to improve DORA metrics. These metrics have been shown to correlate closely to business objectives and competitiveness. In many engagements, GitOps has been proven to help organizations move into the “elite” level of DORA metrics. In this way, there is a clear link between the technical benefits of GitOps and the business outcomes.
This is not to say that everyone should take the same path—some organizations may wish to jump straight into a higher level of the maturity model. Others may decide that they don’t need to progress to the higher levels. However, it is clear that the benefits of GitOps only come from Level 1 upward.
A development team may easily achieve Level 1 (“application GitOps”) using freely available open source tools for GitOps. This enables application developers and DevOps professionals to quickly configure their applications and continuously deploy and reconcile into any Kubernetes cluster from a git repository. For instance, Weave GitOps uses Flux to implement drift detection, image automation and reconciliation to ensure that the cluster exactly mirrors the chosen branch or folder in git.
In a larger organisation, the platform team can use enterprise open source tools to create and manage multiple clusters in different regions, zones or even multiple clouds. This relies on the Cluster API (CAPI), which is supported by AWS, Azure, Google, VMware and many other cloud and infrastructure providers. Changes to the cluster configuration are also reconciled in exactly the same way as applications are in Level 1. Each development team can continuously deploy and reconcile their workloads into these clusters (in other words, Level 2 includes all Level 1 benefits).
Only a few large organizations have taken this to the next step and defined multiple clusters with the same configuration to enable Fleet management. An example of this is Deutsche Telekom’s Das Schiff project, which is designed to deliver 5G workloads to thousands of edge clusters in a consistent and effective way using GitOps. However, not all organizations have this kind of need for Level 3.
Bringing It All Together
GitOps consists of highly collaborative processes with the Git repository serving as the “single source of truth” in dynamic support of CD pipelines. The benefits of GitOps are numerous and are beginning to be better understood. GitOps is also emerging as the gold standard for Kubernetes operating models among leading vendors in the tech sector. In support of GitOps for Kubernetes, Amazon, Codefresh, GitHub, Microsoft, Weaveworks and others are, for example, collaborating on its principles and technical aspects within the Cloud Native Computing Foundation’s (CNCF) GitOps Working Group.
One of the main reasons GitOps is gaining such traction is that it sits at the intersection of people, process, and technology. Because it is based on well-understood processes that already work effectively with different teams in the organization, GitOps maps well into the organization and teams culture.
The GitOps Maturity Model can be seen as the next step in support of GitOps: Helping organizations plan a more structured approach to adopting GitOps. Whether or not your organization follows the same path as the four levels of maturity describe, it is useful to understand the common progression: The reasons why deployments move through this journey and the benefits of increasing GitOps maturity.