Déjà-vu im Cluster
Es gibt Momente, da schaut man in ein Kubernetes-Setup
und fühlt sich plötzlich wieder wie 2008.
Viele Abkürzungen.
Viele Standards.
Viele Schichten.
Und ein leises Gefühl von:
Das ist beeindruckend.
Aber ist das alles nötig?
In den 2000ern hieß das JavaEE.
Manchmal mit OSGi.
Manchmal mit einem Server, der länger startete als die eigentliche Anwendung.
Heute heißt es Kubernetes.
Und GitOps.
Und zehn Dinge, die man zusätzlich „einfach noch“ braucht.
Die Namen ändern sich.
Das Muster bleibt.
Enterprise will alles lösen
JavaEE wollte Enterprise-Anwendungen standardisieren.
Lifecycle.
Deployment.
Transaktionen.
Messaging.
Dependency Injection.
Alles geregelt. Alles formalisiert.
Kubernetes will dasselbe.
Nur für die Cloud.
Pods.
Deployments.
Services.
Controllers.
Operatoren, die Operatoren betreiben.
Beide Systeme sind nicht falsch.
Sie sind nur sehr gründlich.
Vielleicht zu gründlich.
Deklarative Magie
OSGi hatte diese besondere Art von Magie.
Bundles sollten sich finden.
Dynamisch laden.
Wieder starten.
Ganz elegant.
Bis man zum ersten Mal herausfinden musste,
warum ein Bundle „nicht resolved“ ist.
GitOps fühlt sich manchmal ähnlich an.
Man beschreibt einen gewünschten Zustand.
Ein Controller sorgt dafür,
dass die Realität sich anpasst.
Theoretisch wunderschön.
Praktisch bedeutet es oft:
Eine YAML-Datei.
Die von einem Tool transformiert wird.
Das von einem anderen Tool generiert wurde.
Das von einem Controller angewendet wird.
Der irgendwann etwas tut.
Und wenn es nicht funktioniert,
debuggt man nicht Code.
Man debuggt Zustände.
Die Tool-Kaskade
JavaEE hatte alles.
EJB.
JPA.
JMS.
JTA.
CDI.
Spring als Gegenbewegung.
OSGi als Modularitätsversprechen.
Karaf als Runtime für das Ganze.
Ein Baukasten,
der alles kann.
Und deshalb sehr viel verlangt.
Kubernetes hat ebenfalls alles.
Helm.
Kustomize.
ArgoCD oder Flux.
CRDs für jede Idee.
ServiceMesh,
weil Netzwerk jetzt plötzlich auch Architektur ist.
Alles ist modular.
Alles ist ersetzbar.
Alles ist optional.
Und nach drei Monaten ist nichts mehr optional.
Der alte Reflex
Beide Welten teilen denselben Reflex:
Wenn die Welt komplex ist,
bauen wir ein System,
das alles abbildet.
Für alle Fälle.
Für alle Teams.
Für alle Eventualitäten.
Das klingt vernünftig.
Bis man merkt,
dass man 80 % der Möglichkeiten nie nutzt,
aber 100 % der mentalen Last trägt.
Komplexität wird nicht reduziert.
Sie wird nur organisiert.
Die eigentliche Parallele
JavaEE ist nicht gescheitert,
weil es schlecht war.
Es war nur oft überdosiert.
Ein schlanker Stack
war hervorragend.
Zu viel davon
war anstrengend.
Kubernetes ist nicht anders.
Pods.
Deployments.
Services.
Ein klarer GitOps-Flow.
Das funktioniert.
Was es kippen lässt,
ist nicht das Werkzeug.
Sondern der Wunsch,
die gesamte CNCF-Landscape
gleich mitzuinstallieren.
Komplexität ist sozial
Die spannendste Parallele ist keine technische.
Sie ist sozial.
Frameworks wie JavaEE
und Plattformen wie Kubernetes
entstehen aus demselben Wunsch:
Wir wollen Ordnung.
Für alle.
Für alles.
Das führt zwangsläufig zu:
Ein paar wirklich guten Ideen.
Ein paar übertechnisierten Lösungen.
Ein paar Workarounds für die übertechnisierten Lösungen.
Und etwas dunkler Magie.
Der Rest ist Kultur.
Was man wirklich lernen kann
Die Lektion aus JavaEE war nie:
„Keep it simple.“
Sie war:
Nutze das Minimum,
das dein Problem löst.
Nicht das Maximum,
das der Standard erlaubt.
Für Kubernetes gilt das genauso.
Wer es schlank hält,
gewinnt:
Weniger Moving Parts.
Weniger Überraschungen.
Bessere Debuggability.
Ein klareres mentales Modell.
Wer alles einführt,
nur weil es existiert,
baut sich seinen eigenen Applikationsserver.
Nur diesmal in YAML.
Das kleinere Werkzeug
Kubernetes ist nicht das Problem.
GitOps ist nicht das Problem.
Genauso wenig wie JavaEE damals.
Das Problem ist der alte Traum,
Komplexität durch noch mehr Struktur
vollständig beherrschbar zu machen.
Vielleicht ist die eigentliche Kunst
nicht, das mächtigste Werkzeug zu wählen.
Sondern das kleinste,
das noch reicht.
Und den Rest bewusst nicht.