Die neue Plattformkrise ist organisatorisch
Katrin Peter 5 Minuten Lesezeit

Die neue Plattformkrise ist organisatorisch

Weniger starre Systeme. Weniger monolithische Abhängigkeiten. Schnellere Deployments. Mehr Automatisierung. Mehr Skalierbarkeit. Mehr Portabilität.

Cloud Native sollte viele Probleme klassischer Enterprise-IT lösen.

Weniger starre Systeme. Weniger monolithische Abhängigkeiten. Schnellere Deployments. Mehr Automatisierung. Mehr Skalierbarkeit. Mehr Portabilität.

Und technisch betrachtet hat genau das auch funktioniert.

Kubernetes, Infrastructure-as-Code und GitOps haben die Art verändert, wie moderne Plattformen gebaut und betrieben werden. Infrastruktur lässt sich heute reproduzierbar bereitstellen, Anwendungen können dynamisch skaliert werden und Deployment-Zyklen haben sich dramatisch beschleunigt.

Trotzdem entsteht gerade in vielen Unternehmen ein neues Problem.

Viele moderne Plattformen werden bereits während ihres Aufbaus operativ unwartbar.

Das Interessante daran ist, dass diese Systeme äußerlich oft hochmodern wirken. Sie laufen auf Kubernetes, nutzen GitOps, bestehen aus Microservices und sind vollständig containerisiert. Auf Architekturdiagrammen sehen sie aus wie der Gegenentwurf zu klassischer Legacy-IT.

Operativ verhalten sie sich allerdings zunehmend wie genau das.

Denn die neue Legacy entsteht heute nicht mehr primär durch veraltete Technologie. Sie entsteht durch unkontrollierte Komplexität.


Die neue Legacy ist nicht alt — sondern überoptimiert

Klassische Legacy-Systeme waren häufig historisch gewachsen. Über Jahre wurden Prozesse erweitert, Schnittstellen ergänzt und Sonderfälle eingebaut, bis irgendwann kaum noch jemand das Gesamtsystem vollständig verstand.

Cloud-Native-Plattformen entwickeln heute erstaunlich ähnliche Eigenschaften — nur deutlich schneller.

Der Unterschied ist lediglich, dass die Komplexität diesmal nicht langsam über Jahrzehnte entsteht, sondern oft bereits während der ersten Skalierungsphase moderner Plattformen.

Denn moderne Cloud-Native-Architekturen bestehen längst nicht mehr nur aus Containern und Kubernetes-Clustern. Sie bestehen aus immer mehr Kontrollschichten, Abstraktionen und operativen Teilsystemen, die miteinander interagieren.

GitOps-Systeme steuern Deployments. Operatoren verwalten Datenbanken. Admission Controller erzwingen Policies. Service Meshes beeinflussen Netzwerkverhalten. Security-Layer greifen tief in Runtime-Prozesse ein. Observability-Plattformen erzeugen zusätzliche Telemetrie- und Kontrollpfade.

Jede einzelne dieser Komponenten löst reale Probleme. Genau deshalb werden sie eingeführt.

Das Problem entsteht nicht durch einzelne Technologien. Das Problem entsteht durch ihre Wechselwirkungen.

Denn moderne Plattformen entwickeln heute häufig schneller Komplexität, als Organisationen überhaupt in der Lage sind, nachhaltige Betriebsmodelle dafür zu etablieren.


Kubernetes reduziert Infrastrukturkomplexität — und erzeugt gleichzeitig neue Systemkomplexität

Das eigentliche Paradox moderner Plattformarchitekturen besteht darin, dass Kubernetes klassische Infrastrukturprobleme tatsächlich erheblich vereinfacht hat.

Provisionierung ist standardisierter geworden. Deployments sind reproduzierbarer. Skalierung funktioniert dynamischer. Infrastruktur lässt sich deklarativ beschreiben.

Gleichzeitig verschiebt Kubernetes einen erheblichen Teil der Komplexität auf eine andere Ebene.

Früher bestand Infrastruktur primär aus relativ klar definierten Systemen: virtuelle Maschinen, Netzwerke, Datenbanken und einige Deployment-Prozesse. Moderne Plattformen bestehen dagegen zunehmend aus dynamischen Kontrollsystemen, deren Verhalten sich aus unzähligen Interaktionen ergibt.

Dadurch verändert sich auch die Art der Komplexität.

Klassische Infrastruktur war häufig kompliziert, aber relativ deterministisch. Moderne Plattformen sind dagegen hochgradig dynamisch. Ihr Verhalten entsteht oft erst aus der Kombination unterschiedlichster Komponenten, Operatoren, Policies und APIs.

Genau deshalb werden viele Plattformen organisatorisch irgendwann schwerer beherrschbar als technisch.


YAML wird zur neuen Enterprise-Abstraktion

Besonders sichtbar wird diese Entwicklung bei Kubernetes-Konfigurationen selbst.

Cloud Native versprach deklarative Infrastruktur. Tatsächlich erleben viele Unternehmen inzwischen jedoch eine explosionsartige Zunahme operativer Konfigurationskomplexität.

Helm-Charts erzeugen zusätzliche Abstraktionsschichten. Kustomize-Layer erweitern bestehende Konfigurationen weiter. Operatoren erzeugen dynamisch neue Ressourcenmodelle. CI/CD-Systeme manipulieren Deployments zur Laufzeit.

Irgendwann entsteht eine Plattform, bei der zwar theoretisch alles deklarativ beschrieben ist — praktisch aber kaum noch nachvollziehbar bleibt, welche Konfiguration tatsächlich produktiv aktiv ist.

Das erinnert zunehmend an frühere Enterprise-Welten, in denen XML-basierte Integrations- und Konfigurationssysteme irgendwann komplexer wurden als die eigentlichen Anwendungen, die sie orchestrieren sollten.

Nur diesmal passiert dieselbe Entwicklung mit YAML, CRDs und Kubernetes-APIs.


Operatoren lösen Probleme — und erzeugen gleichzeitig neue Plattformdynamiken

Besonders spannend ist dabei die Rolle von Kubernetes-Operatoren.

Operatoren gehören zu den mächtigsten Konzepten moderner Plattformarchitekturen. Sie ermöglichen es, komplexe Betriebslogiken direkt in die Plattform zu integrieren und automatisiert auszuführen.

Genau dadurch entstehen jedoch zunehmend Systeme, deren Verhalten nicht mehr einfach linear nachvollziehbar ist.

Denn moderne Plattformen bestehen heute häufig aus einer Vielzahl voneinander abhängiger Kontrollsysteme. Datenbank-Operatoren interagieren mit Backup-Operatoren. Security-Policies beeinflussen Netzwerk-Policies. GitOps-Systeme triggern neue Reconcile-Loops, während Runtime-Komponenten gleichzeitig dynamisch Ressourcen verändern.

Dadurch entwickeln Plattformen zunehmend emergente Eigenschaften.

Das bedeutet: Das Verhalten der Plattform ergibt sich nicht mehr nur aus einzelnen Komponenten, sondern aus ihren komplexen Wechselwirkungen.

Und genau dort beginnt moderne Plattformkomplexität gefährlich zu werden.

Denn emergente Systeme sind schwer vorhersehbar, schwer reproduzierbar und organisatorisch extrem anspruchsvoll.


Die eigentliche Gefahr ist organisatorische Fragilität

Die kritischste Entwicklung moderner Plattformen liegt deshalb nicht allein in technischer Komplexität.

Die eigentliche Gefahr entsteht dort, wo Plattformen organisatorisch schneller wachsen als die Teams, die sie kontrollieren sollen.

Neue Technologien lassen sich heute extrem schnell integrieren. Nachhaltiges Betriebswissen entsteht dagegen langsam. Dokumentation bleibt oft fragmentiert. Verantwortlichkeiten verschwimmen. Wissen konzentriert sich auf einzelne Spezialisten.

Das Ergebnis sind Plattformen, die technisch hochmodern wirken, organisatorisch aber zunehmend fragil werden.

Viele Unternehmen merken das erst relativ spät. Nämlich genau dann, wenn kritische Systeme faktisch „unantastbar" werden, Migrationen scheitern oder Plattformteams beginnen, immer größere Teile ihrer Zeit ausschließlich mit Plattformbetrieb statt mit eigentlicher Produktentwicklung zu verbringen.

Und genau an diesem Punkt entsteht moderne Legacy.

Nicht weil Technologie veraltet wäre. Sondern weil Komplexität die organisatorische Beherrschbarkeit überholt.


Plattformreife entsteht nicht durch mehr Technologie

Genau deshalb wird die wichtigste Fähigkeit moderner Plattformteams künftig vermutlich nicht sein, möglichst viele neue Cloud-Native-Technologien zu integrieren.

Die entscheidende Fähigkeit wird sein, Komplexität aktiv zu begrenzen.

Denn Plattformreife entsteht nicht dort, wo möglichst viele Abstraktionen, Operatoren und Plattformschichten kombiniert werden.

Plattformreife entsteht dort, wo Systeme langfristig:

  • nachvollziehbar,
  • standardisiert,
  • reproduzierbar
  • und organisatorisch kontrollierbar

bleiben.

Viele Unternehmen optimieren ihre Plattformen heute auf maximale technische Flexibilität.

Dabei verlieren sie häufig genau das, was Plattformen langfristig eigentlich liefern sollen:

operative Stabilität.

Und genau deshalb erzeugt Cloud Native gerade in vielen Organisationen eine neue Generation Legacy-Systeme.

Nicht weil Kubernetes oder Container schlechte Technologien wären.

Sondern weil moderne Plattformen inzwischen schneller komplex werden, als Unternehmen lernen, sie nachhaltig zu beherrschen.

Ähnliche Artikel

Kubernetes v1.36:

Wie Staleness-Mitigation Controller endlich deterministischer macht Kubernetes ist eine …

29.04.2026