A lot has been written about GitOps since its release by Weaveworks more than a year ago as a “single source of truth for the whole system” for using Git for Kubernetes deployments on the cloud.
Aptly described by Alexis Richardson, Weaveworks co-founder and CEO, as “90% best practices and 10% cool new stuff,” GitOps largely offers a framework for DevOps CI/CD deployments on Kubernetes. This was something very often seen as missing among the many Kubernetes management distributions on offer—hence, its popularity.
The tool is obviously not of use for organizations that have not adopted Kubernetes, but in many ways has enabled organizations’ DevOps to more efficiently take advantage of Kubernetes by running Git in a more disciplined and focused way.
“The idea behind GitOps is to maximize the time developers spend on productive coding versus worrying about working with the latest source code, merging their saved code back into the repository and continuously supporting problems that come up during the application build process,” Torsten Volk, an analyst for Enterprise Management Associations (EMA), said.
GitOps offers DevOps a way to use its version control capabilities to archive changes to application deployments in a way that allows them to be recalled at a later time. This can come in handy when an architecture fails and it is necessary to access and reinstate a previous version of an application deployment or update prior to the incident. All changes are tagged and archived in a way that each developer knows when and how their changes to an application were changed.
“Ideally, each developer would check in their code and receive a link to the running application with his or her latest changes applied, as well as with all the other changes that were checked into the repository,” Volk said.
The Adoption Checklist
Volk offered the following elements he said DevOps should have in place before adopting GitOps:
— All infrastructure and application configurations, including databases, middleware and machine learning models, need to be defined as code, Volk said.
“Everyone must accept the basic concept that code is only complete when all components for a successful build are checked into Git,” he said. “CLI-driven, ad hoc deployments are no longer acceptable.”
— The DevOps group has to be able to detect changes to application code that previously might have been able to bypass Git. There must be thus be a process in place to bring these changes back under GitOps control, Volk said.
“The IT Ops/DevOps teams need to make operational changes to the app exclusively via changes to the code checked into Git,” he said. “This means that tasks such as scaling, failover, creating maintenance windows, etc. as well as urgent troubleshooting tasks have to run through Git. The latter is especially tricky, as the enterprise will not accept longer mean time to detect (MTTD) and mean time to repair (MTTR) due to GitOps.”
— Declarative management practices have to be used in Dev and Ops. “This has proven to be a critical roadblock,” Volk said. “Kubernetes developers, as part of Dev and Ops, still often prefer the control of imperative management over the promise of defining their desired end state and letting the software deal with how to get there.”
For DevOps teams that have the prerequisites in place as described above to use Git to run Kubernetes deployments on the cloud, then GitOps deserves at least a look. However, for those organizations that adopt GitOps for the right reasons, it is not designed as a one-size-fits-all solution and organizations will need to modify it to fit their needs. Its implementation, for example, will almost certainly different compared to how Weaveworks described its functioning after using it for two years to run Kubernetes and Prometheus telemetry databases on a cloud platform.
DevOps will, thus, need to be actively involved in GitOps deployment and maintenance to make sure it meets organizations’ individualized needs. When first describing GitOps, Weaveworks’ Richardson wrote: “Fair warning: this is what works for us, and dear reader, you may disagree.”
— B. Cameron Gain
