3 typische Ursachen, warum Kubernetes-Projekte im Mittelstand teurer werden als geplant

Ich begleite mittelständische Industrieunternehmen seit Jahren dabei, ihre Java-Anwendungen von starren On-Premise-Umgebungen auf Kubernetes zu heben. Fast in jedem Projekt taucht früher oder später dieselbe Frage auf: Warum kostet das am Ende mehr, als der ursprüngliche Business Case vorgesehen hat? Aus meiner Erfahrung lassen sich die Kostentreiber auf drei wiederkehrende Ursachen zurückführen.

1. Der bestehende Monolith wird unterschätzt

Migrationsprojekte werden meist auf Basis der Architektur-Dokumentation geplant — nicht auf Basis des tatsächlichen Codes. In der Praxis stecken in gewachsenen Java-Monolithen aber genau die Details, die eine Kubernetes-Migration verteuern: Session-Zustand, der bislang stillschweigend auf genau einer Instanz gehalten wurde, Batch-Jobs mit fest verdrahteten Dateisystempfaden, Cron-Trigger, die von einem einzelnen Server ausgehen, oder JDBC-Connection-Pools, die auf eine feste Anzahl langlebiger Prozesse ausgelegt sind statt auf Pods, die jederzeit neu gestartet werden können.

Jeder dieser Punkte wird meist erst während der Migration entdeckt — nicht davor. Das Team muss dann parallel zur eigentlichen Container-Migration die Anwendung nachbessern, damit sie überhaupt zustandslos und neustart-fähig läuft. Diese Nacharbeit taucht in kaum einem ursprünglichen Projektplan auf, verlängert aber Zeitplan und Budget spürbar.

2. Fehlendes Kubernetes-Betriebs-Know-how im eigenen Team

Kubernetes selbst kostet nichts — der Betrieb aber schon. Im Mittelstand kümmern sich häufig ein bis zwei Personen nebenbei um die Infrastruktur, ohne dediziertes Platform-Team. Externe Berater bauen den Cluster auf, konfigurieren Resource Requests und Limits, Autoscaling, Netzwerkrichtlinien und Ingress — aber das Wissen bleibt beim Dienstleister statt im Unternehmen.

Die Folge: Nach dem Go-Live entstehen Incidents durch Fehlkonfigurationen, die intern niemand einordnen kann, und jede Anpassung erfordert erneut externe Unterstützung. Was ursprünglich als einmaliges Migrationsprojekt budgetiert war, wird zu einer dauerhaften externen Abhängigkeit — mit laufenden Kosten, die im ursprünglichen Business Case nicht vorgesehen waren.

3. Keine Kostenkontrolle nach dem Go-Live

Aus Vorsicht werden Resource Requests und Limits während der Migration oft großzügig dimensioniert — "damit nichts ausfällt". Ohne Monitoring auf Namespace- oder Team-Ebene fällt eine schrittweise wachsende Cloud-Rechnung aber wochenlang niemandem auf, bis das Controlling nachfragt. Dazu kommen typische Nebenschauplätze: Staging- und Testumgebungen, die rund um die Uhr laufen statt sich nachts automatisch herunterzufahren, verwaiste Persistent Volumes und ein eigener Load Balancer pro Service statt eines gemeinsam genutzten Ingress.

Jeder dieser Punkte für sich ist klein. In Summe erklären sie aber einen großen Teil der Fälle, in denen die Cloud-Kosten nach der Migration signifikant über den ursprünglichen Kalkulationen liegen.

Fazit

Kubernetes ist nicht per se teuer — eine schlecht vorbereitete Migration schon. Die drei Ursachen lassen sich vermeiden: mit einer ehrlichen technischen Bestandsaufnahme des Monolithen vor Projektstart, mit dem gezielten Aufbau von Kubernetes-Kompetenz im eigenen Team parallel zur Migration statt einer reinen Auslagerung, und mit Kostentransparenz ab dem ersten Tag im Cluster statt erst nach der ersten überraschenden Rechnung.