What is GitOps and How Does It Guide Us to Efficiency?
GitOps is the technical implementation of a DevOps culture for automated software delivery.
As DevOps defines collaboration and culture, team structures, potential outcomes for platforms, and so forth, GitOps provides a prescriptive technical implementation of those principles to standardize industry best practices for software and infrastructure delivery.
The overarching benefit of GitOps is the commonality of interface and platform, when following industry practices, used to simplify the orchestration of application delivery. For example, a GitOps implementation today would commonly standardize on Git as the version-controlled source of truth for the declaration of the entire application environment, and Kubernetes as the common platform API to reconcile the state held within Git. As a result, developers and operators alike are afforded the ability to manage, deploy, and optimize their end-user experience and software lifecycle via a common language of understanding. This language then fully cements the concept of collaboration among disparate teams with differing skills and responsibilities.
GitOps Definition
GitOps is not regarded as groundbreaking or even new. The principles for efficient software delivery have been around for ages, however refined over time. GitOps is simply the latest named iteration based on the tools and concepts available. As such, the OpenGitOps (opengitops.dev) project has been established to formerly define the GitOps methodology within four key principles:
A system managed by GitOps must have its desired state expressed declaratively.
The desired state is stored in a way that enforces immutability and versioning, retaining a complete version history.
Software agents automatically pull the desired state declarations from the source.
Software agents continuously observe actual system state and attempt to apply the desired state.
How Did We Get Here?
I always like to relate technological iteration to broader and more relatable life scenarios, using analogies. In this instance, how we got to GitOps falls in line with the general idea of how we became a self-governed society.
Where does it start? We started with disparate communities of people all working within their specific groups, learning niche skills, speaking exclusive languages, developing unique cultures, all while working under a similar goal of general survival. The end goal was the same; only the means to get there were slightly different.
Over time, it became apparent that working together to pool knowledge of differentiated skills to accomplish similar goals was the most efficient way to guarantee a predictable outcome. Tribes became villages, villages became towns, and so forth. As each previously isolated group came together to share their methods, a shared culture grew through common tools, ethics, and languages. Through these commonalities, the establishment of large-reaching societies organically grew to form an environment where everyone contributed to a mutual outcome through understood practices such as moral guidance and ethics.
However, ethics and morality can differ among groups of people, even with shared interests and common goals. There came a point where definitions and centralized interpretations of culture became necessary to formally dictate the implementation of processes so everyone could continue to contribute to society under well understood policies. Laws and governance became a way for people to codify their shared interests and expectations.
Bringing this analogy back to GitOps, we can relate these iterations of establishing a self-governed society to how individual software organizations mature over time. As with the running of disparate communities, engineers with specific skills within organizations can become siloed, only working on their discipline, focusing only on their tightly scoped set of goals, speaking their respective languages, and using their unique tools. This can cause them to lose sight of the bigger picture, creating an environment of tossing issues over the proverbial fence to other teams, without working together or discussing common conclusions.
To increase efficiency, there needs to be collaboration and shared responsibility among teams to predictably meet their common goals of software delivery and reliability. DevOps as a practice is intended to create a shared culture among these isolated teams to widen their scope and encourage a ’look over the wall.’ To be successful, developers, application owners, and operations teams within a DevOps culture need to establish common platforms, shared interests, and understood communication methods. A cultural shift to reorganize and facilitate open collaboration for shared responsibility across disciplines is the result.
However, much like establishing a society with shared ethics and morals, there needs to be a prescriptive implementation of the DevOps culture to succeed in a long-term sustainable way that is self-governable via well understood centralized principles. GitOps provides a defined list of technical best practices to codify the culture of DevOps into a set of tangible requirements for what an efficient software-development lifecycle should be.
What is a Realistic Implementation?
Within an organization based on DevOps principles, GitOps provides the technical guidance to correlate methodology to culture by referring to the four core GitOps principles.
Using Figure 1 as a general reference architecture, we can start to tie principles to tools and platforms. Principle one provides the requirement of a declarative system allowing our teams to write desired-state configurations without manually executing imperative lists. Kubernetes is an optimal choice of platform in this regard, as it offers a centralized, declarative API that can consume our desired state and build reconciliation loops around our intention to ensure that what we want is what we get.
Kubernetes, being extensible, is also not limited to just native objects. For example, Kubernetes can be used to build cloud resources or have application context added through projects such as Crossplane or the Operator Framework, respectively. However, even if Kubernetes is the platform of choice, we still need ease of use to stand the platform up from scratch. Tanzu Mission Control provides a SaaS-based interface that allows you to use a GUI, or an API, for managing complete cluster lifecycles. Tanzu Mission Control can be used as a bootstrap point to establish our base-layer platform, while enabling Day Two capabilities, such as backups and monitoring.
Now that we have established the declarative system, on which our applications and services will be deployed, we can turn to principle two, which is to ensure our desired state is stored in a way that is easily versioned and immutable. Again, a few options meet this need; however, Git is the de facto standard for storing code in this manner. But Git alone can become burdensome to manage, and since this will be the single interface into our environment, it would be beneficial to roll it into a platform, such as GitLab, to easily manage security, pipeline automation, task tracking, developer onboarding, and so forth. In this instance, Git is being used to store our desired state, and GitLab, as a platform, will become our single interface for all management requirements.
Our desired state is version controlled and ready to be consumed by a declarative system. To adhere to the last two principles, this process of deployment must be pulled into the system and automatically and continuously reconciled to ensure the actual state always matches the desired state. In this case, Fluxv2 is our choice of tool. There are again several options; however, built into Tanzu Mission Control is the ability to automatically deploy and manage the Flux operator and agent controller to conveniently deploy Kubernetes clusters and enable them with the appropriate GitOps-based agents to continuously pull and reconcile the desired state from our centralized GitLab repositories.
The benefit of this system is in its simplicity and flexibility. For example, developers can alter the entire environment by committing changes to their GitLab repository, kicking off automated integration pipelines that merge their changes into a branch monitored by Flux agents on destination Kubernetes clusters. Once the developer’s code successfully completes whatever testing is necessary, new container images are created, Kubernetes declarative manifests are altered to reflect the new image tags, and Flux reconciles the differences and updates the running application within the intended cluster. This system of management is not limited to developers and their source code, however. As the operator model becomes more prevalent, vendors are creating specialized operators to inject application context and logic into Kubernetes controllers to make deployment and lifecyle management of complex applications an automated process. Tanzu SQL for Kubernetes is an example of this architecture. With Tanzu SQL, administrators can create customer-resource definitions, such as MySQL instances, in a declarative manner; store those manifests within their own GitLab repository monitored again by Flux; and have Kubernetes take and create entire databases. This is taking Infrastructure as Code and correlating it to GitOps principles and adding application development without creating two disparate systems, or methods, of management and deployment.
Bringing It All Together
Developers, operators, and application owners can all standardize on a single platform for their source of truth in GitLab, a single platform for running their declared state in Tanzu Kubernetes, and a single interface for interacting with the environment in Git. Through these common tools and shared interests, collaboration can occur organically while processes and procedures are codified through GitOps principles. This is the end goal. However, as with all new things, there are caveats. It takes time to mature to this level of automation and elegant simplicity, and there are plenty of instances in which this may not be 100% possible. Sterling has expertise in this field and can provide services that ensure viability and potential migration — or deployment — of GitOps-based systems to start your maturation process. Reach out to Sterling via the contact us page for more information.