A Look at GitOps for the Modern Enterprise – InApps 2022

GitOps is a modern cloud native approach to continuous deployment that leverages the Git version control/source control system as a single source of truth for all configuration, infrastructure, and operational procedures. In this approach, the changes are automated through the source control system itself. GitOps is considered as an evolutionary approach towards infrastructure as code.

What sets GitOps apart from other approaches is, it centralizes the development and operations process so that you have a singular path using the method of a single source of truth.

GitOps grants:

• Improved developer productivity and experience by saving time and effort. By pushing code, not containers.
• Increased speed with continuous deployment automation.
• Improved CI/CD endurance since it provides an easy tracking mechanism.
• Highly available and cost-efficient with low downtimes.
• Higher security since Git used as a single source of truth.
• Consistency and uniformity of end-to-end workflows.
• More robust workflow since Git is used to track and manage changes.

GitOps acts as an integral part of DevOps, automating the development process and speeding up the release processes. It leverages the strength of automation to lessen the necessity for manual human intervention throughout application lifecycle management.

DevOps and GitOps might share a mutual goal; the distinction can be made by saying DevOps is a cultural philosophy, whereas GitOps is more of a modern cloud native approach tied to specific tools. DevOps is not linked to any tools or roles as such.

With GitOps, there is a better division of processes. Git provides an operating procedural model for Kubernetes and the whole cloud native stack. It defines a set of principles that revolve around deployment, monitoring, and the containerized clusters’ management.

In a non-GitOps workflow, you require API calls or mouse clicks to initiate the events, but in  GitOps workflow, any defined commits to Git trigger the events — builds, deployments, and other lifecycle events automatically.

GitOps aligns perfectly with the modern DevOps practices in that everything is treated as code, with the code is stored in Git. Everything originates and connects back to Git, a single source of truth. It allows you to extend your definition of everything here to include operations and infrastructure actions. Everything is observable and monitored. Environment changes are auditable via Git.

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping. https://t.co/SgUlHgNrnY

— Kelsey Hightower (@kelseyhightower) January 17, 2018

In the GitOps workflow, the system’s desired configuration is maintained in a source file stored in the git repository with the code itself. The engineer will make changes to the configuration files representing the desired state instead of making changes directly to the system via CLI.

Reviewing and approving of such changes can be done through standard processes such as — pull requests, code reviews, and merges to the master branch. When the changes are approved and later merged to the master branch, an operator software process is accountable for switching the system’s current state to the desired state based on the configuration stored in the newly updated source file.

In a typical GitOps implementation, manual changes are not allowed, and all changes to the configuration should be done to files put in Git. In a severe case, authority to change the system is given just to the operator software process.

In a GitOps model, the infrastructure and operations engineers’ role changes from implementing the infrastructure modifications and application deployments to developing and supporting the automation of GitOps and assisting teams in reviewing and approving changes via Git.

To summarize, the GitOps pipeline operates like this:

• Starts with the user (mostly the developer) changing the code in Git.
• After that, a container image is built and pushed to the container registry like the JFrog container registry.
• Then it gets updated into a config updater.
• Once the developer creates a pull request, it deploys to the concerned branch.
• Then it tests if the workflow is all correct or if there are any complexities.
• Once everything looks good, the reviewer will be able to merge it.
• After the merge, the next step is it goes to the test branch.
• Once anybody creates a pull request, it will deploy to that test branch automatically.

Possible Disadvantages with GitOps

While GitOps may seem intuitive, how feasible is it to deploy? Here are a few disadvantages:

• Scalability issues: While GitOps promises complete visibility on the workflow, it might not be true for big enterprises that have many GitOps repositories and/or configuration files. GitOps seems to work only for comparatively simple setups where a few GitOps repositories include a manageable number of configuration files.
• Risky secrets: It is not a best practice to keep/store secrets in Git repositories, which would be a natural place for them in a GitOps workflow. Once you store secrets in Git, these secrets may be remembered forever. As the repositories grow, managing and maintaining these secrets is also not viable and can be risky.
• Complex workflows: In GitOps, all the deployments are handled by the .yaml file pull request. As we start operating multiple clusters for our pipeline, each cluster will hold its own unique configuration values. The script, as we know it is imperative, cannot automatically adapt based on the environment. This indicates that a different deployment script is required for each environment. This difficulty increases as we introduce more environments — clusters and Namespaces in our workflow setup.
• Doesn’t address the full development lifecycle: The GitOps approach and tools focus only on the deployment part of an application. GitOps doesn’t help with end-to-end software development.

Conclusion

GitOps offers various benefits and has some disadvantages too. Since this approach is still relatively new, some major gaps remain, and we’re still looking out for the “big wins” in the market to point to. It is up to individual companies to experiment with the GitOps method and see how it helps alongside their tried-and-true approaches to DevOps.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog, Hightower.

Feature Image par Robert Balog de Pixabay.