IT organizations regularly face the challenge to deploy a multicomponent application on distributed resources across multiple hosting environments. To avoid a descent into anarchy, teams turn to GitOps.
GitOps is a way to apply version control to all of the deployment parameters and configuration settings necessary to run a complex application. The name combines Git, a popular and open source version control technology, with ops, for IT operations, and signifies that there is a single source of truth for resource deployment information related to said complex application.
Software developers popularized version control when confronted with the task to modernize features and fix bugs in distributed applications, while also maintaining the production version in a stable state. Through version control technologies and application lifecycle management (ALM) practices, developers keep APIs and workflows that bind components to each other in harmony. However, software version control is not enough to ensure production stability for these rapidly evolving applications.
IT organizations rely on parameters and configuration files to set up virtual hosts on which applications run. Even if the APIs and workflows of a given application match up, a mistake in parameterization and configuration can break how it deploys and operates. Each new version of software components typically requires new versions of parameters and configuration files. In continuous development and delivery setups, various versions of application components update independently but must stay in sync in production.
To bring version control into the deployment phase of ALM, a GitOps approach dictates that the application source code, operating parameters and configuration instructions all undergo centralized control with a repository and tracked changes.
How a repository works
Git offers a version-aware storage mechanism for code and registers when users withdraw the code for changes and when they introduce modified code.
Version control in source code is usually managed by a repository. Git offers a version-aware storage mechanism for code and registers when users withdraw the code for changes and when they introduce modified code. Git features enable the user to declare a goal state for an application or piece of code and measure its current state against that goal.
Declarative statements hold it all together
Storing all this data in a repository is a useful step, but it doesn't guarantee that the code, parameters and configuration data associated with an application are consistent.
Instead of just cataloging independent but logically related materials, GitOps adherents use the repository to hold declarative statements about the components, applications, resources, dependencies and anything else that relates to the way the application is developed, changed, tested and deployed. These statements -- typically written in a human-readable YAML format -- are processed to create the specific scripts, packages and data sources used for operations, including orchestration and management. Since the parameters and configuration descriptions are derived from the declarative YAML statements, they are consistent. A declarative configuration management tool or related DevOps system can cross-validate the declarations continuously. With the goal state declared and enforced with DevOps tools, teams cannot easily create invalid or illogical states of applications. In this way, GitOps should reduce failures for complex applications in production.
The case for GitOps
Shared microservices are a good example of modern distributed application development and deployment practices that demand a GitOps approach. Development teams increasingly use microservices across application boundaries. The practice facilitates code reuse, reduces development time and errors, and improves consistency in application behavior. However, these shared microservices are in the development and deployment path of multiple applications at once. There's a major risk that one application's change will dictate alterations to one or more shared services, which can affect other applications. One change to a microservice carries the danger of broken applications. With GitOps as a single source of truth, the team can continuously review the API, parameter and configuration requirements for each application. When a change of the nature described here affects a goal state, the declarative tool recognizes and flags it.
Containers, cloud evolution feed complexity
GitOps also helps to address complexity created by advances in monitoring, event generation and service connection in container technology, as well as hybrid and multi-cloud services. These tools exist to monitor and manage conditions and workflows in the operating environment. For stable operations, they mean new things to parameterize and synchronize with the rest of the application platform tools. To achieve operational efficiency improvements, we almost always have to structure the platform toolkit to do everything in a standard way, and that standardization falls apart unless all the pieces are synchronized.
The term GitOps' similarity with DevOps is no accident. DevOps is a way to deploy, scale, move and repair applications with scripts and parameters rather than manual work. However, DevOps maintains a disconnect between steps associated with development and the sequence of steps for operations. Operations, which typically starts with an executable code test and covers production deployment and monitoring setup, must be followed exactly, or the live code will break. Therefore, DevOps as a practice generates scripts and parameters that must be managed, and in GitOps, this information is managed in the same place as application code. GitOps isn't a replacement for DevOps or for any other specific tool or step in the development and operations cycle. Instead, it aims to group source code and deployment instructions into a harmonized single source of truth. Consistent, controlled versions of the application and its deployment information enable stability in a DevOps process.
