How to Get the Most out of GitOps – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s InApps.net learn How to Get the Most out of GitOps – InApps in today’s post !
Read more about How to Get the Most out of GitOps – InApps at Wikipedia
You can find content about How to Get the Most out of GitOps – InApps from the Wikipedia website
Jordi Mon Companys
Jordi is product parketing director at Weaveworks. He’s an open source product specialist, community builder and public speaker. He is an OpenUK and PMM Alliance ambassador and is based in London.
GitOps is an operating model for Kubernetes applications and clusters. It centralizes and automates much of the configuration workload, monitoring and correction of inconsistencies on an ongoing basis. It does so by storing all operational information in a version control system like Git, rather than just using Git for application code. In combination with Kubernetes’ inbuilt automation features and some additional monitoring software, GitOps makes for reduced operational complexity, faster deployment of new features and better security throughout the delivery pipeline.
If the worst happens, rolling your application back to a previous version can be achieved in minutes, rather than hours — even if it means destroying the cluster and rebuilding it from scratch. This is a superpower almost every organization needs, because in a world where practically every company is a software company, the better you are at delivering your software, the more competitive you will be.
Just as Kubernetes was accepted as the best way to do cloud native applications, GitOps is gaining recognition as the best way to do Kubernetes.
For these reasons, GitOps is now being adopted all over the world. Just as Kubernetes was accepted as the best way to do cloud native applications, GitOps is gaining recognition as the best way to do Kubernetes. Yet not all GitOps implementations are created equal. The extent to which you commit to GitOps dictates the degree to which you will enjoy its benefits.
This is not simply a case of rival vendors with differing feature sets; most GitOps components are open source, after all. What differs is the level at which you are prepared to adopt the best practice. It’s a spectrum. The greater your commitment, the more benefits your organization will enjoy.
So how do you know where you sit on the spectrum? As with so much in the technology world, there’s a model. As a GitOps vendor, we at Weaveworks developed the GitOps Maturity Model. It identifies four levels of GitOps adoption, from implementing the prerequisite components to large-scale, organization-wide adoption.
The GitOps Maturity Model
The idea of maturity models is not new. Thoughtworks author Martin Fowler describes a maturity model as “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.” In short, it tells you where you are now and, crucially, where you should aim to go next.
Based on years of experience working on real-world GitOps deployments, the GitOps Maturity Model reflects the journeys made by the organizations that get the most from GitOps.
Level Zero: Prerequisites
That journey typically begins at Level Zero (L0). Technically, this is not full GitOps at all, hence the zero. While it denotes that an organization has undergone some level of digital transformation — moving to the cloud and using containerized infrastructure, for example — it should be seen as a point on the journey toward GitOps. An organization might be storing configuration information for at least one application in Git, which means they can deploy faster and benefit from a degree of repeatability. But crucially, they are yet to make use of the continuous reconciliation features of GitOps.
Level One: Core GitOps
At Level One (L1), it’s a different story. The system is continually checking for differences between the application running in production and its desired state, as described in Git. Should any drift be detected, the system will fire off alerts to operations staff. This degree of automation boosts deployment frequency as well as visibility and auditability of operations — critical in regulated industries and for any business that deals with customer data. It also helps reduce costs and mean time to recovery (MTTR).
Level Two: Enterprise GitOps
Level Two (L2) takes things further. Now the whole gamut of GitOps automation features are in effect across the entire environment. Ops teams can manage multiple clusters across different regions, zones or even clouds. That in turn allows developers to focus fully on creating new features that add business value without risk of breaking things as they progress from development to production. Ops teams, meanwhile, can focus on governance, risk and compliance protocols, easily scaling up cluster infrastructure without the need to hire new staff. For many organizations with enterprise needs, this level constitutes full GitOps.
Level Three: Scaled GitOps
Level Three (L3) is about massive scale. Here, whole fleets of clusters are managed through GitOps, resulting in consistency across the fleet, clear enforcement of policy and greater development velocity. Organizations at this level benefit from application portability across multiple clouds, along with the ability to run thousands of clusters across cloud and on-premises infrastructure. Clearly this level of automation will not be appropriate for everyone, however fleet management is essential for some. One real-world example is Deutsche Telekom’s Das Schiff project, designed to consistently deliver 5G workloads to thousands of edge clusters.
Putting the Model Into Practice
GitOps is gaining momentum. The Cloud Native Computing Foundation’s GitOps Working Group is now steering its development, with contributions from members including Microsoft, Amazon, GitHub, Codefresh and Weaveworks.
In part, its success is due to the fact that GitOps is not purely a technology. It is a group of technologies accompanied by a set of processes and best practices. And it has a crucial additional benefit: The technologies involved are for the most part technologies that people already use. Developers know Git. DevOps and platform teams know Kubernetes. So in a sense, GitOps is not a new thing; it is just a new way to do things. And they happen to be things that practically every organization needs to do.
The GitOps Maturity Model is, in essence, a set of signposts. If you want to make the most of GitOps, they will point you in the right direction. But they are not the main driver of success with GitOps. That comes down to a set of clear, proven business benefits and the fact that most teams already possess most of the skills they need to put it to work.
For more information, read the white paper, “The GitOps Maturity Model – 4 Evolutionary Steps to Continuous Delivery,” or watch the on-demand webinar, “Your Path to GitOps Maturity“
Photo by Jakayla Toney from Pexels.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.