The GitOps Journey
GitOps principles defined by the CNCF GitOps Working Group.
But where does GitOps fit into an IT strategy? In my opinion GitOps should be the centerpiece of every modern IT strategy!
The GitOps journey takes the hype surrounding GitOps to build a solid, automation-focused, long-term sustainable IT strategy. A strategy that uses standard "GitOps" tools together with our own developments to navigate the deep waters between DevOps chaos and widening the Dev-Ops gap towards true hands-off operations where the Dev or Ops question is mostly irrelevant as we all use the same common automation and tooling.
GitOps is the natural evolution for DevOps practices.
Challenges of every IT Strategy
Many IT strategies differ in wording but talk about the same thing: We have to automate our processes, become more efficient and effective, manage to deliver more IT with less people or cost, adopt new technologies etc. This is typically surrounded by catch phrases like digitalisation, BizDevOps, Public Cloud computing, API-first-strategy and others.
But in the end, this all boils down to a few very simple - and old - points:
- significantly increase standardisation
- reduce procedural waste
- reduce the cost of change and the cost of maintenance
- automate everything
- use cloud computing
Why are we not so successful in our endeavour to achieve these goals? I believe that there are various organisational and technical challenges that work against us:
- Applications need to be maintained longer and longer, increasing the cost of maintenance:
- We create many more new applications than retire old applications, IT is still building up.
- Using external innovation like the one found in cloud computing in existing applications is very often too expensive (as it requires significant reengineering or re-architecting) so that we keep the old stuff "as is".
- We typically underestimate the long tail of creating and having an application, and we initially optimize for quick and cheap application development over low maintenance costs.
- Most applications use outdated development and operations practices:
- Dev and Ops practices evolve much faster than our application lifecycles - but we can easily adopt new practices only for new applications and tend to keep the old practices for old applications.
- Modern Dev and Ops practices are highly integrated with a focus on automation, idempotency and changes that are only eventually consistent but not necessarily instant. Applications need to be designed specifically for these practices to fully benefit from them, changing the architecture of existing applications is often not feasible.
- Regulatory and policy compliance becomes more expensive:
- IT regulation became much more strict over the last decades, the risk of non-compliance became much more a business risk.
- Manual compliance checks don't scale with the amount of applications and the frequency of changes delivered by "agile" IT organisations.
- Higher degrees of data and process integration require implementing IT compliance as part of an application, compliance on the Ops level is no longer good enough.
- Automating compliance checks would be a solution, but developing such automation is seen as prohibitively expensive.
In the end it is like the rabbit and hedgehog story: No matter how much we IT people work, it seems like we never manage to catch up.
Focus on our IT teams
I think that to solve this problem we need to take an holistic approach that optimizes a company and its processes and platforms for the IT teams tasked with creating and maintaining IT solutions:
Our IT teams find themselves at the crossroads of organisational requirements and technical limitations. I am sure that the more we optimise everything for them, the more our IT teams will be able to deliver great IT solutions. Some ideas:
- Standardise IT tooling so that teams don't need to solve so many problems that are not related to their core product or feature.
- Provide acceptable means of compliance so that IT teams can rely on the fact, that using the standard tooling makes the team also to be compliant with their requirements.
- Simplify policies to reduce the cost and effort of being compliant
- Provide budgets for compliance to reduce team's motivation to avoid being compliant and to enable global optimisation for compliance
- Think of policies as code to enable automated compliance validation
- Strive for true hands-off operations to automate all manual processes
In the end, it's all about automation.
Automation to the Rescue
In an ideal world all our IT and organisational processes would be highly automated, perfectly integrated and running smoothly without human intervention. In reality, we stumble from IT project to IT project, build new IT platforms before the previous IT platforms where finished or had enough time to yield large returns and the evil cycle starts all over.
Why? Because we don't put automation and long-term sustainability at the top of our priorities!
And from there on it is always a slippery road down where one bad compromise follows the next one. Where we decide to "do one more thing manually" or "let's automate this later" or "we cannot automate this policy" and in the end the manual tasks stand in the way of efficient processes and the lack of integration between different silos require many manual tasks. The evil circle repeats itself.
Hands-off operations is - in my humble opinion - the best goal that we can set for ourselves to keep the focus on automating everything. It ensure that we continue to ask ourselves "how can I avoid doing that manually" and to design everything for automation.
Yes, true hands-off operations is probably still not attainable right now, at least for normal enterprise IT departments. But the vision of true hands-off operations helps us to stick to an automate everything mission and that in turn helps us to stay focused on reducing many or all of the factors mentioned above that hold us down.
What actually is hands-off operations? In short, it means "don't do it yourself", specifically
- No manual changes in production
- Dev & Ops have same permissions in production: None by Default
- Automate the hard stuff:
- Compliance & governance
- Distributed rolling upgrades
- Backup & Disaster Recovery
- Everything in your stack
- Test Driven Everything
- Standardized Tooling
Comparing this with common GitOps definitions or the goals of typical GitOps tools I see a lot of overlap: Essentially GitOps tools want to solve these problems, too. GitOps tools all come with a promise of "no manual operations" and significantly reduce the need for people to have production permissions.
Ideally we would employ GitOps practices everywhere:
With GitOps concepts we could describe an entire IT world entirely in declarative descriptions and hand off operations to software agents.
In practice however, standard software tools are not yet that sophisticated. But we can start now at the top of our stack, e.g. for applications running on Kubernetes. There the tools like ArgoCD, Flux v2 and many others are already production ready and used successfully in many organisations. In the layer below a single Kubernetes namespace there are also tools for managing Kubernetes tools and even Cloud infrastructure environments. The more we go down in the stack, the less the tools are production ready or feature complete.
Nevertheless, since there are virtually no negative side effects to GitOps practices, I recommend strongly:
Adopting GitOps practices drivesautomation as the solution for many IT strategy requirements.
I'll be speaking about this topic also at the GitOps Con Europe 03.05.2021.
Further GitOps reading:
- How did GitOps get started? An interview with Alexis Richardson
Alexis shares his GitOps story on my blog - video & transcript.
- Finger Weg - GitOps läutet die Ära des automatisierten IT-Betriebs ein, iX 4/2021 Titelstory mit Grundlagen zu GitOps und Motivation zu GitOps im Unternehmenseinsatz