Operations models are coming at us fast and furious these days. DevOps and DevSecOps adoption and maturity have only increasing during the pandemic. It’s now incumbent for DevOps and DevSecOps teams to get all their system configurations under the same level of control and governance as they do with their application source code and containers. That's right, it’s time for a new operations model. Say hello to GitOps!
What is GitOps?
GitOps practices empower development teams to perform traditional IT operations team tasks. As more organizations move to continuous integration (CI), continuous delivery (CD), and apply automation to their testing, delivery, deployment, and governance the more opportunities they have to implement GitOps to streamline infrastructure tasks that DevOps doesn’t necessarily automate and factor into its workflows. It also lets your teams take advantage of backend data through the application of analytics to give your stakeholders actionable insights on what’s happening up and down your pipelines and in your cloud infrastructure.
One of the many strengths of GitOps when compared to DevOps, is that it enables DevOps teams to loosen restrictions between development and operations sequences. GitOps is also repository centric with the project’s configuration files and deployment parameters residing in the same repository as the application source code. These strengths mean GitOps supports rapid development and complex changes, all the while minimizing reliance on the complex scripts that traditionally dominate such tasks. GitOps also emphasizes the use of Git, a single and often already familiar tool for developers. GitOps is gaining attention because of the complexities around configuring Kubernetes (K8s). When a Kubernetes shop moves to GitOps, they can manage their K8s configuration right along with their application source code. If they make a configuration mistake, they can roll back to their last known good configuration.
Critics of GitOps cite its lack of visibility into environments despite proponents seeing visibility as one of its strong suits. The criticism is because the data that teams see resides in a plain text format in Git which they see working for only simple configurations and setups.
Comparing GitOps vs. DevOps
We’re reaching a peak level of ops in the IT industry right now. It’s easy to get them all confused without the help of corporate marketing departments. The easiest way to distinguish between DevOps vs. GitOps is to think of DevOps as a pipeline mechanism that enhances software delivery. GitOps is a software development mechanism that improves developer productivity.
These ops models bleed together because of continuous integration/continuous delivery (CI/CD) and the componentization of software through containers.
GitOps complements an overall DevOps strategy and your toolchains. By introducing GitOps into their workflows, a DevOps team can experiment with new infrastructure configurations. If the team finds that the changes don’t behave as expected, they can roll back the changes using Git history.
GitOps and Secure Development
Many of the same contrasts between DevOps and GitOps remain in GitOps vs. DevSecOps. GitOps is developer-centric. DevSecOps is security-focused with software containers playing a growing role in how DevSecOps teams secure software during development, testing, and in production.
As DevSecOps add more security and analytics to the toolchain, teams can easily extend their security measures to secure their Git repositories. The merging of DevSecOps and GitOps should be interesting to watch.
DevOps, DevSecOps, and GitOps in the Future
Evolution is constant in the IT operations world. While some foresee that DevOps and DevSecOps will merge, GitOps will certainly continue to augment DevOps and DevSecOps toolchains and processes offer teams better tools to manage configurations, thus lifting some pressure off the Ops team so they can focus on more strategic work.
