2.0 KiB
2.0 KiB
title: "The GitOps Paradox: Why Your Devs Need an API You Don't Want To Build
weight: 13
tags:
- platformengineeringday
{{% button href="https://colocatedeventseu2026.sched.com/event/2DY82" style="error" icon="calendar" %}}Sched Link{{% /button %}} {{% button href="https://github.com/ConfigButler/gitops-reverser" style="info" icon="code" %}}Code{{% /button %}} {{% button href="https://revertgitops.dev" style="info" icon="link" %}}Website/Homepage{{% /button %}}
Baseline
- We all like files, humans like them, they are easy to use and AI can use them
- Git is a good version manager
- GitOps is cool and we want to keep it
- Problem: I want to do something and now i need to create a yaml file and open a pr -> High toil
- Question: Should git always be the primary entry path for changes
- Idea: Use kubernetes api as our api server, have an operator that handels creation of manifests in git + promotions and so on and the changes to the "real" clusters are always made via gitopös
The paradox
- We shield people from the kubernetes api and force them to use git
- We build our own custom apis on top of the kubeapi anyways
- Solution: Why not go back to using the Kubernetes API (humans and robots can use it)
Principles of the reverse gitops manifest
- API first (via Kubeapi) to reuse auth, crds, status, controllers and more
- Capture intent not implementation -> Not api-only (if you can do it bi-directional) with reversible&declarative resources
- GitOps applies -> Changes are always piped through gitops for reviews, history, rollback, promotions, ...
Implemantations examples
- Use KRO as the abstraction that captures the intention
- GitOps Reverser