Getty Images/iStockphoto
Evaluate the GitOps model for your organization
For some organizations, GitOps leads to faster, higher-quality software delivery -- but for others, DevOps or NetOps is a better fit. Learn what factors your team should consider.
For longtime developers, software architects and development managers, modern practices present almost an embarrassment of riches. We've gone from largely nonsystematic practices to multiple systems, often with slightly different goals.
Although GitOps is currently highly popular and publicized, it's only one example of an emerging development model -- and it's hardly the only approach to software delivery. As with many things in IT, it's important to avoid jumping on a trend.
New tools tend to get publicity and attention, but you risk having to reverse a move down the line if you adopt the GitOps model without making sure it fits your organization's needs. To determine whether GitOps is right for your organization, compare it with other development approaches and keep the following factors in mind.
Comparing GitOps with other development approaches
Everything assigned the ops suffix is related to operations, including the integration of IT operations with development.
DevOps is the seminal concept here. The DevOps approach is based on the idea that a combination of practices and tools can support the effective transformation of a need for a new software project or change into a deployment that addresses an organization's needs.
The advantage of GitOps lies in its singularity. Companies that already use Git as a version control system for software development can easily adopt the GitOps model. The question organizations face is whether this advantage really puts GitOps in the lead compared with the various other development and deployment models.
GitOps vs. DevOps
In practice, DevOps is vast and loosely defined, with so much variance in implementation that it can be challenging for organizations to understand. DevOps is also arguably short on the dev piece, meaning that its focus has been more on the operations side.
GitOps realizes the DevOps goal of operations integration by applying many of the principles of infrastructure as code (IaC). The GitOps model uses repository pull requests, which signal changes in software, to address infrastructure changes and the relationships between software and infrastructure.
Unlike GitOps, DevOps doesn't mandate a specific repository process or deployment model. Although it's possible to build noncontainerized applications with GitOps, the majority of GitOps organizations use containers, which carry the configuration declaratives with the images. In contrast, DevOps deployments might use Ansible, Chef or Puppet rather than a container orchestrator such as Kubernetes.
GitOps vs. NetOps
Another ops that's a bit orthogonal to both DevOps and GitOps is NetOps: the processes associated with the network configuration and connection needed for an application.
In theory, teams taking a NetOps approach could also pull declaratives from a Git repository. But today, it's uncommon to integrate network configuration with application deployment and infrastructure setup because network connectivity is normally set statically to provide uniform connectivity.
How does GitOps affect CI/CD pipelines?
The best strategy for comparing the GitOps and DevOps models is to start with the standard CI/CD pipeline.
A traditional CI/CD pipeline pulls new code from a repository, builds a deployment image, and then updates deployment and orchestration with the new code. The shortcoming of this approach is that the configuration and parameterization needed at the deployment level is separate from the code, so there is no single source of truth.
With GitOps, the only change in the process is that the declaratives needed for deployment are also stored in and pulled from the repository with Git to control the infrastructure state. In the general CI/CD model, those declaratives are separate, with a greater focus on development and testing of the code in the repository.
When is GitOps the right choice?
Given all this, when does adopting the GitOps model make sense? There are both positive and negative signs an organization can look for.
When to use the GitOps model
Signals that GitOps is appropriate include a focus on containers for hosting. The majority of happy GitOps users work with containers and Kubernetes. If your organization neither uses nor is considering containers, GitOps might not be the right fit.
Another positive indicator is the importance of IaC in your operation. If your application changes regularly require changes to the deployment declaratives, GitOps will likely be helpful. But if most application changes don't involve infrastructure configuration, then the benefits of GitOps will be limited.
When not to use the GitOps model
A negative GitOps indicator is a strong focus on microservice deployment and extensive componentization. Organizations building cloud applications from microservices and stateless operation tend to standardize deployment requirements to use resources most efficiently. In such cases, GitOps is less useful.
A second negative signal for GitOps is a strict requirement to support a different repository model for the development portion of the application pipeline. Having multiple repositories in a process intended to ensure a smooth transition from development to deployment is almost always a mistake. If there's no practical way to change your repository strategy to Git, look at other IaC options.
Tips for successful GitOps adoption
Even where GitOps is a good approach, adopting the model isn't likely to be the only step required to ensure development and operations integration.
Unlike DevOps, which includes a development ingredient, GitOps focuses on deployment declaratives. It should be supplemented by development-side CI/CD tools to create a complete pipeline for software changes and their transition to deployment. Some GitOps toolkits include some or all of these related development-level elements, but it's not guaranteed.
If you decide GitOps is right for your organization, you still must choose whether to use it in a push or pull model:
- The push form of the GitOps model pushes development changes to clusters as they're released.
- The pull version of the model relies on operations to pull models into clusters when changes are available, subject to application schedules.
There's considerable debate over which approach is best, but the general consensus is that the pull approach prioritizes production conditions and limits the level of access to the repository across the pipeline.
Choosing the right GitOps tools
Successful GitOps adoption depends on selecting the best tools. It's generally best to start your tool review with the complete Git-based CI/CD offerings and then focus on more targeted tools when these broader tool sets don't suit your pipeline needs.
GitLab offers tools in the form of a full delivery platform that also covers the CI/CD development portion of the pipeline, and it's often a good idea to review these first. Harness is another popular commercial delivery tool for the full pipeline.
Many Kubernetes users like tools such as Argo and Flux to integrate GitOps with Kubernetes. Codefresh offers an Argo-based SaaS tool, and Rafay's GitOps service is another SaaS option to manage the GitOps-to-Kubernetes flow.
