DevOps is a combination of the terms development and operations, meant to represent a collaborative or shared approach to the tasks performed by a company's application development and IT operations teams. In its broadest meaning, DevOps is a philosophy that promotes better communication and collaboration between these teams -- and others -- in an organization. Use this guide to learn more about how DevOps works, why it's important, its benefits and challenges, prominent DevOps tools and more.
Compare GitOps vs. DevOps for modern app deployments
Despite some overlap, GitOps and DevOps differ in several important ways, especially as organizations embrace containers and application componentization.
As software development tools and practices continue to evolve, it's essential that dev teams collaborate with IT operations admins, as these admins deploy what developers design and build.
DevOps and GitOps are two approaches that blur the lines between IT ops and development tasks -- and while they share some common principles, they also have key differences.
What is GitOps, and what is DevOps?
DevOps was conceived as a pipeline mechanism, whereas GitOps is an enhanced development mechanism. Continuous integration/continuous delivery (CI/CD) and componentization have caused the two to expand into each other's territory. While GitOps is not a subset of DevOps, these approaches will likely converge in the future. Today, the differences -- and overlaps -- between GitOps and DevOps influence how organizations balance the capabilities of both.
Boiled down to essentials, DevOps:
is about culture and methodology, 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; and
involves a comprehensive toolchain.
By comparison, GitOps:
is essentially a paradigm and technique;
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, and minimizes reliance on complex scripts; and
emphasizes use of a single tool (Git).
GitOps origins: How DevOps spawned GitOps
DevOps was the industry's first attempt to create a fluid pipeline from development to operations, throughout which essential application characteristics and configuration needs are passed from one team to the next. Nearly all popular DevOps tools convert developer-created instructions into deployment steps; this is the baseline set of requirements for effective integration of development and operations.
The advent of highly componentized applications and CI/CD -- or rapid development -- raised two important points in this integration:
First, the development process itself needed a better structure for the complex multicomponent relationships inherent in new application models, wherein services and microservices become the rule.
Second, in componentized applications, the pipeline between development and operations is much more complicated, because a release is a set of component changes pushed at their own pace through the pipeline.
The logical solution for both of these challenges is to center both development and operations on a shared repository -- a single source of truth that guides all development and operations activities individually and connects them through a pipeline, and provides an audit trail as well. The Git repository has been the dominant choice to store version-controlled code; many organizations began to build an enhanced set of development tools and practices around Git. To build a similar IT operations practice centered on Git, and to pipeline the two together based on Git exchanges, is a clear choice. This is how GitOps was born.
The pipelines for DevOps vs. GitOps follow slightly different pathways to fulfill different visions.
Overarching differences in GitOps vs. DevOps
GitOps focuses on a cloud-native service or microservice software vision, which the repository centers on and describes. 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 -- and, in a growing number of cases, it's not even a requirement; Kubernetes and associated packages can serve better.
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.
It's difficult not to see containers and Kubernetes, DevOps and GitOps as a three-legged stool.
DevOps is an operations-centric vision of the pipeline that focuses from the outset on how to deploy code -- even to the extent that early tools were prescriptive, or script-focused. This aligns well with enterprises' needs when applications change slowly, and configuration changes and hardware issues happen daily. This makes DevOps a good fit for organizations that struggle with a transition to the cloud, for example, rather than with development and CI/CD issues.
Many DevOps tools expand the methodology into areas such as monitoring, configuration management and infrastructure as code. 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 vs. DevOps with containers
It's difficult not to see containers and Kubernetes, DevOps and GitOps as a three-legged stool. But neither DevOps nor GitOps are linked explicitly to containers and Kubernetes. In practice, most DevOps users do not deploy containers, and most GitOps organizations have committed to containerized software. Organizations that don't already use containers generally 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 enables IT admins to manage the coordinated deployment of multicomponent applications that all march to their own business drums. Because GitOps focuses on both developers and CI/CD, it lands at the center of the evolution of the development and operations relationship.
If that's true, then containers and Kubernetes are a natural beneficiary, because GitOps tends to be 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 much wider range of application models, but if the world is converging on containers, then DevOps' versatility is far less important.
DevOps is at risk of being cast as the proverbial "third leg." 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 explosively 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.
