GitOps culture is completely different from DevOps culture
DevOps gave rise to GitOps. Yet, both are quite different when it comes to culture. Learn what the difference is and why it should matter to your organization.
The world of technology is constantly changing with rules being rewritten and laws being redefined on a regular basis. In this post, we’re going to take a close look at the differences between GitOps culture and DevOps culture, and what kind of environment we need to foster to make GitOps work.
GitOps calls for separate Application Development & Platform teams
While the State of DevOps report released by Puppet this year indicates about 80% of organizations are still in the mid-level of DevOps maturity, it also brings culture back into focus and recommends an approach to escape this middle phase. This is similar to how different members of a team have clearly delineated roles and responsibilities. Additionally, having predefined communication channels and interaction paradigms makes collaboration with external teams a lot simpler.
The first step towards having clearly defined roles and responsibilities is to split up the more ambiguous DevOps teams into Application Development and Platform teams. While this might seem like a step backward since everything about DevOps screams one team for Dev and Ops, it still works like one team but with a lot more efficiency. Unlike the traditional waterfall approach where Dev teams build and Ops teams run, here the Dev teams build and run apps while the Platform teams ensure resources are available. The Platform teams achieve this by building and maintaining a platform that is typically a collection of self-service APIs and tools.
DevOps vs GitOps - The difference
While DevOps is a culture that focuses on breaking silos and blurring the lines between Dev and Ops teams, GitOps is a specific set of processes or practices that redraws new lines to clarify roles and responsibilities. Unlike DevOps, that's focused on CI/CD, breaking silos, and team culture, GitOps is about declaring everything as code, versioning every change for better auditability, and leveraging Git as the single source of truth and control. The end goal of GitOps is to enable better automation and greater deployment velocity. While it might look like we’re splitting up teams based on roles, we’re also unifying them with Git.
This is done by ensuring all system definitions and configuration are described as code and versioned in Git. Once this is done, a GitOps agent like Flux, the basis of Weave GitOps, ensures no configuration drift occurs between Git and the production cluster. This is a big step up from traditional DevOps where you don’t have version control to deal with inconsistencies in security, components, configurations, compliance, and policies - all of which make applications difficult to manage at scale. Additionally, the ability to use Git’s version history to view the difference between each commit is invaluable as it allows for easy rollback as well as the ability to identify exactly what went wrong.
The result of great GitOps culture
In addition to deployment pipelines that roll out changes as soon as code is committed to Git, great GitOps culture allows teams to ship 30-100 times more changes per day, which translates to about 2-3 times more overall output.
While Kubernetes environments are known to be difficult to configure, especially for Admins unfamiliar with its internal workings, GitOps allows Platform Architects to use familiar tools to manage Kubernetes configuration, updates, and security policies.
The Git version history feature that we already mentioned uses strong cryptography to track and manage changes which in addition to allowing rollbacks and audits, also translates to increased stability, reliability, and consistency.
Weave GitOps enables a great team culture
Great teams are built around great communication, coordination, and collaboration. With GitOps in particular, there’s clarity around roles and responsibilities which allows teams to retain a high degree of autonomy. This autonomy is in turn enabled by Kubernetes namespaces that allow us to organize clusters into sub-clusters and create isolation between workloads while also maintaining control over them. While that may sound complicated, especially since enabling and managing Kubernetes namespaces from the command line can be tricky, to say the least, Weave GitOps has a handy solution. Weave GitOps’ Team Workspaces feature is essentially a Kubernetes namespace management service.
Workspaces create secure namespaces and then build on them by installing stacks that are cloned from Git. These stacks may feature all tools necessary for monitoring and development like Flux, Helm, Flagger, Prometheus, Grafana, and more. Workspaces also feature RBAC which allows for specific access control in addition to the ability to enforce policies across different namespaces. The built-in roles for workspaces include workspace-member, namespace-admin, and cluster-admin, with the first role having the least access and the third role the most.
Speaking of policies, Weave’s recent acquisition of Magalix puts the focus on security policies for GitOps. It enables Admins to set policies that control every part of the GitOps process from start to end. From setting policies on what is allowed and what isn’t, to reporting on violations, Magalix is able to enforce GitOps culture at ground level.
In conclusion, to make GitOps work the way it's supposed to, we need to foster a culture of precision coupled with accountability that comes from clearly defined roles. ‘Culture’ as defined by DevOps is very different from the way it is understood with GitOps. If DevOps culture was aspirational, GitOps culture is operational.
