Should You Do GitOps?
What is GitOps?
GitOps is a paradigm that handles infrastructure changes the same way as code changes. It applies Dev-world concepts of moving changes through a pipeline, until they are finally promoted to production, to infrastructure.
The concept makes perfect sense. The trend in the past few years is to handle infrastructure the same way as software, despite the fact there is actual physical equipment (compute, network, storage..) under the surface. No one wants to think about bare metal anymore, and with the incredible progress in programmable infrastructure and infrastructure as code (IaC), it is finally possible to represent infrastructure state with code and forget about the physical stuff (even easier when using public cloud). The next step is to therefore handle changes to this infrastructure state the same way we handle changes in application code.
GitOps started from kubernetes - the concept is more straightforward when using container technologies where the abstraction of applications from infrastructure is built-in. But the same principals can be applied to non-kubernetes implementations and provide similar advantages.
Why is GitOps Good?
Using GitOps provides us with the same advantages we get when using these practices for software in general: a single source of truth for infrastructure state, and streamlining of the process of changing infrastructure state. On paper it gives a list of very desirable effects - better dev experience, auditing, security, consistency, reliability etc.
What Still Needs Fixing in GitOps
What I don't like about the way GitOps is implemented today is that it makes no effort to connect between Dev and Ops. On one hand, it says that infrastructure is handled the same way as applications. On the other hand, it doesn't reflect the relationship between infrastructure and applications. They each get their own pipeline, as if they are two completely separated things. While the original purpose of GitOps was to make infrastructure changes accessible for developers, in practice it can also be used to perpetuate Dev and Ops silos. Applications are nicely abstracted from the infrastructure thanks to containers, so GitOps can be done by Ops and Dev can focus on the applications. Why is that bad? Because when there are problems in the environment they could be application problems or infrastructure problems, and we need to explore two different change pipelines to figure out what went wrong. This takes us back to the world of finger pointing and blaming.
Bringing Applications and Infrastructure Together
One of the most interesting things that we're working on at Quali is figuring out this problem. Our conclusion was that we need a logical unit to represent the relationship between the applications and the infrastructure. We are following two rules:
- The applications MUST be abstracted from the infrastructure (we have developed features to make it happen even if the application is not containerized). We don't want any monolith structures.
- The logical connection between applications and infrastructure MUST be kept, despite the abstraction. This is done with an entity that we call "Environment", and is a first class citizen.
The Advantages of Logically Bundling Applications and Infrastructure
When we use Environments to logically bundle applications and infrastructure, we can return to a single change pipeline. What really moves in the pipeline is not just applications and it's not just infrastructure. It's both of them, bundled together as environments.
When we bundle applications and infrastructure we get additional advantages. We can use the same bundle all the way from pre-production to production, and create a pipeline of discrete changes.
Having the Environment entity as a first class citizen makes it easy to streamline self-service for developers and for machines (e.g. CI/CD tools). It makes it possible to provide a single pane of glass to troubleshooting both infrastructure and application issues. It makes it easier to standardize services like secret management and compliance policies. Finally (but very importantly) it makes it possible to connect between infrastructure consumption and the business use case. As much as we want to "hide" the infrastructure, it's a critical component that eats up our budgets and has to be properly governed. Using environments makes it very straightforward to connect the applications and infrastructure to the business use case, without overhead.
So, if you're thinking about GitOps - it's worth checking out SaaS options like the one we're building for handling application environments that could save you a lot of time and trouble.