TechTarget.com/searchitoperations

https://www.techtarget.com/searchitoperations/tip/Compare-GitOps-vs-DevOps-for-modern-app-deployments

GitOps vs. DevOps: What's the difference?

By Stephen J. Bigelow

Admins deploy what developers design and build, so dev teams must collaborate with IT operations admins as software development tools and practices evolve.

GitOps and DevOps are two approaches that blur the lines between IT ops and development tasks. They share some common principles, but there are some key differences.

What is DevOps?

DevOps is a set of practices, processes and tools that create a fluid pipeline for the continuous development of software applications from concept through development and testing to deployment.

DevOps is a development paradigm that is iterative and agile, so it lets organizations build out a product as a rapid series of steps and updates over time. Each iteration flows quickly through a well-established pipeline of recurring steps, including design, building, testing, deployment and monitoring.

Where a traditional waterfall project might take years from start to final release, a DevOps project might first appear in months -- even weeks -- and evolve through updates that might arrive every few weeks or even every few days.

The essentials of DevOps can be distilled down to the following aspects:

• Revolves around culture and methodology just as much as techniques and tools.
• Maintains a disconnect between steps associated with development and steps tied to operations.
• Emphasizes deployment with hooks to development, especially in tools.
• Relies on scripts and parameters that must be managed.
• Involves a comprehensive toolchain.

DevOps advantages

The practices, speed, culture and tools needed for a successful DevOps environment can be a challenge to maintain. But DevOps promises numerous benefits for developers and businesses:

• Greater velocity. Projects created with DevOps get to market faster. This can boost market share and generate revenue faster than traditional product development paradigms.
• More responsiveness. The small iterations that DevOps embraces allow for faster changes. Teams can change project requirements more easily as the project matures.
• Easier innovation. Small iterations embody smaller risk. Organizations are more willing to risk new ideas and test creative solutions to product needs. Failures are easily undone in subsequent iterations.
• Better quality. Frequent smaller updates allow for more comprehensive testing to ensure software performance and stability. This improves product quality.
• Automation. DevOps relies on high levels of automation to shepherd each iteration through the pipeline to deployment. This enhances development consistency and reduces human error.
• Erasure of silos. The speed and iterative nature of DevOps erases silos and requires excellent communication and collaboration across development and operations.

DevOps use cases

DevOps can be applied to almost any type of software project in any market vertical. The choice to use DevOps or other agile development paradigms are driven by four broad needs:

• You need a working product quickly. A business that needs a bare-bones product in the market quickly and can build on that successful product over time might use DevOps to drive the project and deliver faster releases than traditional development methods.
• Your product's features change. DevOps uses an iterative approach that allows for new ideas, features, and functions. Many of these might not have even been in the initial design.
• You need better product testing. Every iteration undergoes testing before release. This means software is tested more frequently than products developed using traditional methods. There are fewer bugs in each release, bringing better software reliability and quality.
• You want stronger and more integrated teams. Better communication from business teams to developers and from testers to operations staff yields clearer product goals, stronger designs, more reliable deployments, and more comprehensive testing and bug resolution.

What is GitOps?

DevOps' weak spot is deployment. The operations aspect of DevOps often requires some manual intervention from developers. GitOps acts as an extension of DevOps, which focuses on the repository as a single source of truth (SSOT) for the code and for software-defined infrastructures.

DevOps was conceived as a pipeline mechanism, whereas GitOps is an enhanced development mechanism. Continuous integration/continuous delivery (CI/CD) and componentization are the causes for DevOps and GitOps to expand into each other's territory.

GitOps has these key characteristics:

• Loosens restrictions between steps tied to development and operations sequences.
• Is repository-centric, with configuration files and resource deployment parameters centralized in the same place as application source code.
• Emphasizes rapid development and complex changes.
• Minimizes reliance on complex scripts.
• Emphasizes use of a single tool: Git.

GitOps advantages

Although GitOps and DevOps share a common objective with many overlapping ideas and practices, GitOps adopters and practitioners hope to reap a variety of benefits:

• Improved velocity. Developers can use code skills across the entire development cycle when they apply code-based practices to infrastructure provisioning and deployment. This speeds development and deployment, and it can yield notable efficiency improvements when teams ship frequent updates -- perhaps several times per day.
• Improved security. When developers put repository control at the center of the development cycle, it can simplify the overall toolchain. This lowers the potential attack surface and enhances security. Revert to previous versions to address security and functional problems. This can minimize downtime and accelerate problem remediation.
• Extended automation. Improve end-to-end automation from compilation and testing through deployment and monitoring. This improves efficiency in new iterations, reduces human error, and handles troubleshooting and problem remediation.
• Better practices. GitOps builds on development pipelines to add best practices for repository use along with automation files and other infrastructure as code (IaC) files. Establish a common repository to provide a SSOT for code and infrastructure. The record-keeping features of repository platforms support collaboration and enhance transparency across the software development life cycle.

GitOps use cases

GitOps has four main uses that are beneficial to organizations:

• Better efficiency. Use GitOps to bring code-based control to the infrastructure to reduce human errors in infrastructure tasks, improve the consistency and predictability of operational environments, offer comprehensive version tracking and documentation, and security and compliance for the business.
• Focus on infrastructure. When the version of the provisioned infrastructure is just as important as the versions of the components involved in the given build, GitOps might yield more benefits to the business.
• Scalability. Use GitOps to provision and release resources as traffic demands shift. This can be important for cloud-based infrastructure management where businesses pay for the resources used. In this context, GitOps can be well-suited to cloud performance and cost management.
• Troubleshooting and disaster recovery. IaC ensures that workloads are deployed to well-understood and documented infrastructures. When trouble or disaster strikes because of change, the infrastructure and its workload can easily roll back and redeploy using previous known versions documented in the GitOps environment.

Differences between DevOps and GitOps

DevOps and GitOps represent independent, standalone approaches.

GitOps focuses on a cloud-native service or microservice software vision. The GitOps approach is declarative rather than prescriptive. It defines a goal and then operates to achieve it. DevOps drives deployment and redeployment steps through integration with that same repository. Thus, in a true GitOps model, DevOps is a subsidiary tool to GitOps processes.

DevOps accepts both declarative and prescriptive approaches. It fits well with monolithic application models as well as with applications that have limited componentization. Enterprises can also apply DevOps just as easily to VM and bare metal deployments as they can to containers.

Many DevOps tools expand the methodology into areas such as monitoring, configuration management and IaC. But there are few tools designed to support the development process, which suggests that DevOps remains focused on operations even as CI/CD changes the game.

GitOps relies on a repository as the development foundation to provide an SSOT to manage both code and infrastructure. This tends to reduce the number and diversity of tools in the GitOps environment.

DevOps uses a broader assortment of tools, including repositories, version control systems, Jenkins, Ansible, Docker, Kubernetes and Terraform for IaC support.

DevOps	GitOps
Declarative or prescriptive.	Declarative.
Well-suited to monolithic application development.	Suited to cloud-native and microservices application development.
Focuses on automation of agile or continuous pipelines.	Focuses on IaC.
Uses more and varied tools in the toolchain.	Uses fewer tools in the toolchain.

Choosing between DevOps or GitOps

Neither DevOps nor GitOps link explicitly to containers and Kubernetes. In practice, most DevOps shops do not deploy containers, and most GitOps shops commit to containerized software.

Organizations that don't already use containers shouldn't consider GitOps. But organizations that are making a new commitment to containerized applications shouldn't ignore it.

GitOps is developer-centric, which is appropriate for CI/CD, a process that lets IT admins manage the coordinated deployment of multicomponent applications that all function in nonstandard ways. Because GitOps focuses on both developers and CI/CD, it lands at the center of the evolution of the development and operations relationship.

Containers and Kubernetes are a natural beneficiary of this because GitOps is used a lot in container-based development, and Kubernetes is the de facto container ecosystem centerpiece. Containers frame the model for distributed applications, and Kubernetes then works within that model. DevOps supports a wider range of application models. But if the world is converging on containers, then DevOps' versatility is far less important.

GitOps can feed DevOps, but not the other way around. IT admins can adapt DevOps to a containerized environment, but orchestration practices can collide with the formidable and expanding Kubernetes ecosystem. Ultimately, DevOps and GitOps have overlapping goals, but each is being used in its own application and infrastructure framework. If the container and cloud-native world is the future, then GitOps and the Kubernetes ecosystem are the future too.

Organizations should select DevOps when the focus is on process automation, collaboration and improved interaction between development and operation groups using a diverse array of tools.

GitOps might be the preferred choice when the focus is on automating and managing the deployment infrastructure. GitOps can be better suited to security and disaster preparedness. This is because organizations have close and well-documented control over the infrastructure limit access to approved group members as well as detailed record-keeping, which allows for confident rollbacks to previous application or infrastructure versions.

Ultimately, the decision to adopt DevOps or GitOps will depend on the unique needs of the business and the software projects in development.

Stephen J. Bigelow, senior technology editor at TechTarget, has more than 20 years of technical writing experience in the PC and technology industry.

Tom Nolle is founder and principal analyst at Andover Intel, a consulting and analysis firm that looks at evolving technologies and applications first from the perspective of the buyer and the buyer's needs. By background, Nolle is a programmer, software architect, and manager of software and network products. He has provided consulting services and technology analysis for decades.