GitOps & Platform Engineering: Die Internal Developer Platform, die wirklich genutzt wird

TL;DR

• Eine Internal Developer Platform kostet laut Studien rund 4,2 Millionen Euro und 18 Monate Arbeit — mit 5–10 Jahre erfahrenen Engineers — und trotzdem umgehen 64 % der Engineers die Plattform.
• Warum? Plattformen werden oft von Infrastruktur-Leuten für Infrastruktur-Leute gebaut — nicht für die Entwickler. Und GitOps wird als „Tool-Deployment" missverstanden, statt als Kultur und Prinzipien.
• Die vier GitOps-Prinzipien — declarativ, versioniert & immutable, pull-basiert, kontinuierliche Reconciliation — machen Plattformen vorhersagbar und skalierbar.
• Git ist nicht die Single Source of Truth — OCI ist die Source of Intent: Moderne GitOps skaliert auf tausende Cluster über OCI-Artefakte statt roher Git-Repos.
• Progressive Delivery (Blue-Green, Canary) und Disaster Recovery per Repoint gehören zum Betriebsmodell, nicht zum Extra.

Warum so viele Plattform-Projekte scheitern

Plattform-Engineering klingt nach der Zukunft — aber die Zahlen sind ernüchternd. Wer eine eigene Internal Developer Platform baut, investiert rund 4,2 Millionen Euro und 18 Monate mit einem Team aus 5–10 Jahre erfahrenen Engineers. Und am Ende umgehen 64 % der Engineers die Plattform trotzdem.

Das ist kein Einzelfall, sondern das Symptom eines systematischen Fehlers: System-Engineers bauen mit Infrastruktur-Mindset für Infrastruktur-Leute. „Backstage deployen" ist nicht gleich „Internal Developer Platform bauen" — Backstage ist ein Framework, das integriert werden muss. Wenn die Plattform den Alltag der Entwickler nicht löst, finden die Entwickler Wege daran vorbei — egal wie teuer sie gebaut wurde.

Die gute Nachricht: Der Weg zur erfolgreichen Plattform ist bekannt. Er führt über GitOps-Prinzipien und über eine Plattform, die für die Nutzer gebaut ist.

Die vier GitOps-Prinzipien, die Plattformen skalierbar machen

Die Reise von „Local Ops" über „Pipe Ops" zu agent-basiertem GitOps hat vier Prinzipien, die Plattformen vorhersagbar und skalierbar machen:

Diese vier Prinzipien sind die eigentliche Kultur von GitOps. Wer nur ArgoCD installiert, aber weiter manuell in den Cluster eingreift, hat kein GitOps — er hat ein Tool. Und ohne Kultur werden die Tools umgangen, wie die 64 %-Bypass-Rate zeigt.

Der Sicherheits-Vorteil des Pull-Modells

Der Pull-Ansatz ist der wichtigste Sicherheitsvorteil von GitOps: Der Agent zieht den gewünschten Zustand — es gibt keinen Inbound-Zugriff und keine Credentials im Cluster. Das funktioniert auch hinter Firewalls und in regulierten Umgebungen. Wer Deployments per Push in den Cluster treibt, öffnet dagegen eine Angriffsfläche, die GitOps strukturell vermeidet.

Git ist nicht die Single Source of Truth — OCI ist die Source of Intent

Ein verbreiteter Irrglaube: „Git ist die Single Source of Truth." In der Praxis stimmt das nur eingeschränkt:

• Git ist großartig für menschliche Kollaboration — Reviews, History, Branching.
• OCI ist für immutable Artefakte und echte Skalierung als Distributions-Layer gebaut.
• In der Praxis werden Images und Helm-Charts von außen gezogen, Controller manipulieren Zustände — Git war nie die volle Wahrheit.

Moderne, „gitless" GitOps funktioniert so: CI/CD hydriert Manifeste, legt sie als Artefakte in OCI-Registry, und die GitOps-Engine zieht sie daraus. Das skaliert auf tausende Cluster — während rohes Git bei 10, 100 oder 15.000 Clustern an seine Grenzen stößt.

Architektur-Muster für Multi-Cluster-Setups

Bei Skalierung über mehrere Cluster stellt sich die Frage nach der Steuerung. Drei Muster haben sich etabliert:

Hub & Spoke

Zentrale Steuerung, ein Single Pane of Glass. Aber: In regulierten Umgebungen riskant, weil der Hub hohe Privilegien konzentriert.

Dedicated Instance pro Cluster

Bei Banken und Versicherungen üblich — jeder Cluster hat seine eigene GitOps-Instanz, Isolation ist maximal.

Hybrid / Agent-basiert

Leichte Agents in den Spokes (z. B. auf AWS EKS), der Hub reconcilt — pull-basiert, hinter Firewalls, ohne Inbound-Credentials. Das ist der empfohlene Kompromiss aus Sichtbarkeit und Sicherheit.

# GitOps-Architektur-Muster (Konzept)
# Hub: reconciliert den gewünschten Zustand für alle Cluster
# Spoke-Agents: ziehen den Zustand pull-basiert, keine Inbound-Credentials
# Regulierte Umgebungen: Dedicated Instance pro Cluster für maximale Isolation

Progressive Delivery & Disaster Recovery als Betriebsmodell

Progressive Delivery

GitOps und Progressive Delivery gehören zusammen: Rolling Updates, Blue-Green und Canary werden über Argo Rollouts oder Flagger in den GitOps-Flow integriert. Der Vorteil: Release-Entscheidungen sind versioniert, nachvollziehbar und im Notfall sofort zurückrollbar — weil der gewünschte Zustand im Git/OCI liegt, nicht in der Pipeline.

Disaster Recovery per Repoint

Ein bewährtes DR-Muster in GitOps-Umgebungen: „Wenn wir länger als 30 Minuten troubleshooten, werfen wir den Cluster weg und spinnen einen neuen." Der GitOps-Repoint macht das möglich — der neue Cluster zieht denselben gewünschten Zustand und ist schnell wieder auf dem Soll-Stand. Wichtig ist die ehrliche Einschränkung: Das gilt für stateless Workloads. Für State (Datenbanken, persistente Volumes) braucht es eine eigene DR-Strategie.

AI-Agents als Bürger der Plattform

Die nächste Evolution der Internal Developer Platform ist die agentic developer platform — auf der auch AI-Agents Bürger der Plattform werden:

• AI-Troubleshooting: Agents mit vollem Kontext (Logs, Metriken, Traces) können selbst troubleshooten.
• Agentic Development: Entwickler erstellen Komponenten und CRDs direkt mit AI; die Plattform reviewt und applied.
• Config as Data: AI braucht Plain Data statt kryptischer Overlays — sonst liefert sie generische Antworten, die nicht verstehen, was du deployen willst.

Das hat eine direkte Konsequenz für den Plattform-Bau: Eine AI-freundliche Plattform ist von Anfang an „Config as Data" — klare, strukturierte Konfiguration, die ein Modell versteht. Wer Overlays und Workarounds stapelt, macht seine Plattform nicht nur für Menschen, sondern auch für AI-Agents unbrauchbar.

Die ehrliche Kostenrechnung: bauen oder managen lassen?

Die Entscheidung „eigene Plattform bauen oder Managed-Pfad gehen" ist eine Kostenfrage:

Für viele Unternehmen ist ein Managed-Pfad wirtschaftlicher — nicht weil eine eigene Plattform unmöglich ist, sondern weil der Betrieb in einer Hand liegt und die Plattform für die Nutzer gebaut wird, statt ein teures Infrastruktur-Projekt zu werden.

Fazit

GitOps und Platform Engineering scheitern nicht an der Technik, sondern an zwei Dingen: fehlendem Nutzer-Fokus (64 % Bypass) und GitOps als Tool-Stapel statt Kultur. Wer beides richtig macht, bekommt eine Plattform, die Entwickler wirklich nutzen:

1. GitOps-Prinzipien als Fundament — declarativ, versioniert, pull-basiert, self-healing.
2. OCI als Source of Intent — für echte Skalierung über viele Cluster.
3. Progressive Delivery & DR per Repoint — als Betriebsmodell, nicht als Extra.
4. AI-ready von Anfang an — Config as Data für Agents und Entwickler.
5. Für die Nutzer gebaut — sonst zahlen Sie 4,2 Mio. € für 64 % Bypass.

FAQ

Brauchen wir eine eigene Internal Developer Platform? Nur bei genügend Teams und Use Cases. Die Kosten (4,2 Mio. €, 18 Monate) sind real — oft ist ein Managed-Pfad wirtschaftlicher. Eine ehrliche Durchrechnung schützt vor dem teuren Fehlinvest.

Git oder OCI für GitOps? Git für Kollaboration, OCI für immutable Artefakte und Skalierung. Moderne GitOps nutzt beides — OCI als Source of Intent.

Wie vermeiden wir die 64 %-Bypass-Quote? Die Plattform für die Nutzer bauen: Self-Service, der den Alltag löst, Kultur & Prinzipien statt Tool-Diktat. Backstage allein ist kein IDP — es ist ein Framework, das integriert werden muss.

Ist GitOps nur etwas für große Multi-Cluster-Umgebungen? Nein. Die Prinzipien (declarativ, pull-basiert, self-healing) lohnen sich ab dem ersten produktiven Cluster — sie machen Deployments nachvollziehbar, auditable und im Notfall zurückrollbar.

Verwandte Artikel

• ArgoCD & GitOps im Enterprise-Betrieb
• Kubernetes 2026: Was sich geändert hat und wann es sich lohnt
• Multi-Cluster Kubernetes: Karmada & Cluster API
• Blue-Green Deployment auf Kubernetes