Warum Cloud-Plattformen nie fertig sind

Das Missverständnis hinter jedem Cloud-Projekt

Es gibt eine Annahme, die sich durch fast jede IT-Planung zieht: Cloud-Projekte haben ein Ende. Eine Kubernetes-Plattform wird aufgebaut, abgenommen, und danach läuft sie einfach. Eine Azure Landing Zone wird ausgerollt, der Projektabschlussbericht wird geschrieben, und das war es.

Das Missverständnis ist nicht böswillig. Es kommt aus der Logik klassischer Projekte — Budget, Scope, Deliverable, Done. Das Problem ist: Cloud-Infrastruktur funktioniert nicht so.

Eine Kubernetes-Plattform oder Cloud-Umgebung ist nie fertig. Wer nach dem Go-Live aufhört zu investieren, hat in zwölf Monaten technische Schulden, die teurer sind als das ursprüngliche Projekt. Das ist keine Meinung. Das ist ein Muster, das wir immer wieder sehen, wenn wir in bestehende Kundenumgebungen einsteigen.

Dieser Artikel erklärt, was nach dem Go-Live tatsächlich passiert, was es kostet, nichts zu tun — und wie ein anderes Modell aussieht: ein Platform Team, das bleibt, statt eines Projekts, das endet.

Was nach dem Go-Live wirklich passiert

Die ersten Wochen nach dem Go-Live sind trügerisch. Alles läuft. Das Projektteam ist noch greifbar. Kleine Anpassungen werden schnell erledigt. Die Stimmung ist gut.

Ab Monat vier ändert sich das Bild. Das Projektteam ist im nächsten Auftrag. Fragen, die früher innerhalb einer Stunde beantwortet wurden, bleiben jetzt liegen. Cloud-Provider-Updates werden verschoben, weil niemand sicher ist, ob das Einspielen einen Produktionsausfall riskiert. Die Dokumentation, die „noch aktualisiert werden sollte“, ist schon sechs Wochen alt.

Ab Monat sieben bis zwölf tauchen die ersten konkreten Probleme auf. Niemand weiß mehr, warum bestimmte Konfigurationsentscheidungen so getroffen wurden. Security-Patches haben sich aufgestapelt. Cloud-Kosten steigen, ohne dass jemand einen klaren Grund nennen kann.

Was im zweiten Jahr passiert, ist eine logische Konsequenz: Jede Änderung an der Plattform wird zum Risiko, weil niemand mehr den vollständigen Überblick hat. Die Cloud-Plattform läuft — aber sie ist veraltet, teurer als nötig und kaum wartbar.

Das ist kein Ausnahmefall. Das ist der typische Verlauf einer Plattform ohne kontinuierliche Betreuung.

Konkrete Baustellen nach dem Go-Live

Security-Patches und CVEs: Kubernetes veröffentlicht regelmäßig Updates. Jedes Update schließt Lücken. Wer nicht systematisch patcht, akkumuliert ein wachsendes Portfolio bekannter Schwachstellen in produktiven Systemen. Container-Images veralten. CVEs werden entdeckt, aber niemand kümmert sich darum, weil kein Prozess dafür existiert.

Provider-Updates und API-Deprecations: AWS, Azure und Kubernetes selbst entwickeln sich schnell. APIs werden abgekündigt. Managed Services ändern ihr Verhalten. Kubernetes-Versionen erreichen End-of-Life. Wer eine EKS-Cluster-Version nicht rechtzeitig aktualisiert, riskiert, von AWS zwangsmigriert zu werden — zu einem Zeitpunkt, den nicht das eigene Team wählt.

Team-Fluktuation: Der Entwickler, der die Netzwerkarchitektur kennt, wechselt das Unternehmen. Der Kubernetes-Admin, der das Monitoring aufgebaut hat, geht in Elternzeit. Mit jeder Fluktuation verliert die Organisation Kontextwissen, das nirgendwo vollständig dokumentiert ist. Das ist kein Vorwurf an einzelne Personen — es ist eine strukturelle Realität in IT-Teams.

Neue Anforderungen: Compliance-Anforderungen ändern sich. DSGVO-Auslegungen werden schärfer. ISO-27001-Audits fordern Nachweise, die so bisher nicht erzeugt wurden. Ein neues Entwicklerteam braucht Zugang zur Plattform. All das sind keine Ausnahmen — das ist der normale Betrieb einer lebenden IT-Umgebung.

Cloud-Kosten ohne Steuerung: Wer Cloud-Kosten nicht regelmäßig prüft, zahlt für Ressourcen, die niemand mehr braucht. Überdimensionierte Instanzen, Snapshots, die sich anhäufen, ungenutzte Load Balancer. Schleichend, aber kontinuierlich.

Die Kosten des Nichtstuns

Das Argument gegen kontinuierliche Betreuung ist oft das Budget: „Wir haben gerade kein Budget für laufende Kosten.“ Was dabei übersehen wird, ist die Kostenseite des Nicht-Handelns.

Ungeplante Incidents ohne systematische Betreuung: Störungen häufen sich und müssen einzeln behoben werden — oft unter Zeitdruck, oft teuer. Mit regelmäßiger Plattformpflege sinkt die Zahl ungeplanter Incidents spürbar, weil Ursachen adressiert werden, bevor sie eskalieren.

Verpasste Cloud-Kosteneinsparungen: Wer Cloud-Kosten nicht regelmäßig reviewed, zahlt für Ressourcen, die niemand mehr braucht, und lässt Optimierungspotenzial ungenutzt. Über ein Jahr summiert sich das zu einem relevanten Anteil der Cloud-Rechnung.

Das Risikobild: Ein kritischer Security-Incident, ein Compliance-Verstoß oder eine ungeplante Migration wegen End-of-Life eines Kubernetes-Releases können erheblichen Schaden verursachen — finanziell und operativ. Das sind keine Panikmache-Szenarien, sondern reale Folgen, wenn systematische Wartung ausbleibt.

Budget-Abweichungen bei reaktivem Support: Wer Cloud-Betreuung erst einkauft, wenn Probleme auftreten, zahlt Aufschläge für Dringlichkeit und kurze Vorlaufzeiten. Dazu kommen Onboarding beim Anbieterwechsel und interne Koordinationskosten — alles unplanbar und in Summe teurer als geplante Betreuung.

Die entscheidende Frage ist nicht, ob kontinuierliche Plattformbetreuung Geld kostet. Sie ist, ob das Nichtstun günstiger ist.

Das Platform-Team-Modell: Kontinuierlich statt projektbasiert

Das klassische Beratungsmodell endet mit dem Projektabschluss. Rechnung bezahlt, Abnahme unterschrieben, nächstes Projekt. Was danach passiert, ist nicht Teil des Vertrags.

Unser Ansatz geht von einer anderen Annahme aus: Die Plattform, die wir mit euch aufgebaut haben, ist kein abgeschlossenes Deliverable. Sie ist ein lebender Bestandteil eurer IT-Umgebung, der kontinuierlich gepflegt, verbessert und weiterentwickelt werden muss.

Konkret heißt das: ein embedded Platform Team, das eure Plattform kennt — weil es sie mitgebaut hat. Keine Einzel-Beauftragungen, wenn etwas eskaliert. Kein Reaktiv-Support auf Zuruf. Stattdessen hält dasselbe Team, das den Cluster aufgesetzt hat, ihn planbar und proaktiv am Laufen — Teams statt Tickets. Wir nennen dieses Modell Evolve Continuous, aber im Kern ist es genau das: euer Platform Team, das bleibt, solange es läuft.

Was das konkret bedeutet

Jeder Betreuungszyklus enthält einen systematischen Review der Plattform: Kubernetes-Cluster-Status, ausstehende Updates, CVE-Scan für Container-Images, Policy-Compliance, Cloud-Kosten-Check. Kritische Findings werden sofort adressiert, alles andere geht ins Backlog und wird im nächsten Review-Zyklus priorisiert.

Dazu kommen dedizierte Stunden für Optimierungen und — je nach Paket — Verbesserungs-Sprints von zwei Tagen, in denen substanzielle Arbeiten erledigt werden: Kubernetes-Upgrades, neue Security-Policies, Monitoring-Erweiterungen, CI/CD-Optimierungen.

Der entscheidende Unterschied zum klassischen Managed Service: Wir arbeiten agil. Direkte Kommunikation über Teams, keine Ticket-Bürokratie. Ein Problem wird besprochen und gelöst, nicht verwaltet. Change-Durchlaufzeiten von drei bis fünf Tagen über einen Change-Advisory-Board sind hier nicht die Realität — Änderungen gehen als Pull Request durch Review, nicht durch einen formalen Freigabeprozess.

Die Voraussetzung für Evolve Continuous

Bevor wir eine Plattform kontinuierlich betreuen können, müssen wir sie kennen. Deshalb ist Evolve Continuous für uns die natürliche Fortsetzung eines Projekts — nicht ein separater Vertrag mit einem Anbieter, der die Umgebung nicht kennt.

Für Neukunden ohne vorheriges cloudpunks-Projekt: Wir starten mit einem Onboarding-Projekt. Assessment der bestehenden Infrastruktur, Dokumentation des Ist-Zustands, Quick Wins umsetzen. Typischer Umfang: zwei bis vier Wochen. Danach: Übergang in die kontinuierliche Betreuung.

Die drei Varianten

Nicht jede Plattform braucht dasselbe Maß an Betreuung. Evolve Continuous gibt es in drei Varianten, die sich nach Komplexität und Änderungshäufigkeit der Plattform richten.

Continuous Platform — für Kubernetes-Umgebungen

Für Kubernetes-Cluster auf EKS, AKS, GKE, Rancher oder OpenShift. Monatliche Cluster-Health-Checks, Security-Patching, Update-Management, Monitoring-Optimierung. Der Fokus liegt auf dem, was eine Kubernetes-Plattform gesund hält: saubere Updates, gepatchte Images, funktionierende Observability.

Continuous Cloud Environment — für Landing Zones und Cloud-Infrastruktur

Für AWS- oder Azure-Umgebungen, die über eine Plattformarchitektur hinausgehen: Landing Zones, Multi-Account-Strukturen, Netzwerkarchitektur, Cloud-Security-Posture. Regelmäßige Reviews des Security-Scores, Rightsizing-Empfehlungen, Compliance-Checks, Kostenoptimierung.

Continuous Modern Workplace — für Microsoft-365-Umgebungen

Für Microsoft-365-Umgebungen mit Entra ID, Intune, Defender und Compliance-Anforderungen. Regelmäßige Reviews von Conditional-Access-Policies, Endpoint-Compliance, Security-Incidents, Lizenzoptimierung.

Die Paketstruktur im Überblick

Evolve Continuous gibt es in drei Paketen, die mit Umfang und Komplexität der Plattform mitwachsen. Das Essential-Paket umfasst einen monatlichen Review, ein festes Optimierungs-Budget und einen schriftlichen Report. Das Professional-Paket enthält zwei Reviews pro Monat, einen vierteljährlichen Verbesserungs-Sprint und dediziertes Fehlerbehebungs-Budget. Das Enterprise-Paket für Multi-Cloud- und Multi-Cluster-Umgebungen schließt wöchentliche Reviews, monatliche Sprints und einen dedizierten Technical Account Manager ein. Den konkreten Zuschnitt und die Konditionen stimmen wir auf eure Plattform ab.

Mindestlaufzeit: sechs Monate. Kündigung: drei Monate zum Monatsende.

Zwei Muster aus der Projektrealität

Das Muster ohne Betreuung

Wir kommen in eine Kundenumgebung, die vor anderthalb Jahren von einem externen Dienstleister aufgebaut wurde. Der Kubernetes-Cluster läuft auf einer Version, die seit Monaten End-of-Life ist. Container-Images in Produktion haben bekannte CVEs, die in keinem Scan-Ergebnis je aufgetaucht sind, weil kein Scan-Prozess existiert. Die Kosten für Cloud-Ressourcen sind über das Jahr spürbar gestiegen, ohne dass jemand eine Erklärung dafür hat. Die Person, die die Plattform kannte, hat das Unternehmen verlassen.

Was jetzt ansteht: kein einfaches Update, sondern ein Notfall-Migrationsprojekt. Kubernetes-Version anheben, Images rebuilden, Security-Policies durchsetzen, Kosten aufräumen. Das dauert Wochen, kostet mehr als die gesamte Betreuung der letzten anderthalb Jahre gekostet hätte — und verursacht unplanmäßige Downtime-Risiken.

Das ist kein Extremfall. Das ist ein Muster.

Das Muster mit kontinuierlicher Betreuung

Dieselbe Ausgangssituation, aber mit Evolve Continuous: Kubernetes-Versionen werden proaktiv angehoben, bevor sie End-of-Life sind. CVE-Scans laufen monatlich, kritische Findings werden im nächsten Review-Zyklus adressiert. Cloud-Kosten werden quartalsweise reviewed, Rightsizing-Empfehlungen umgesetzt. Wenn ein Mitarbeiter das Unternehmen verlässt, ist das Kontextwissen in Dokumentation und Code gebunden — nicht nur in einzelnen Köpfen.

Keine dramatischen Notfall-Projekte. Keine Überraschungen im Cloud-Kostenreport. Keine technischen Schulden, die sich unbemerkt aufgetürmt haben.

Die Arbeit ist nicht verschwunden. Sie findet statt — aber geplant und in kleinen Schritten, statt als teurer Feuerwehreinsatz.

Wann Evolve Continuous Sinn macht — und wann nicht

Das wäre ein schlechter Artikel, wenn er nur für Evolve Continuous argumentieren würde. Also klar gesagt: Es gibt Situationen, in denen Evolve Continuous nicht das richtige Modell ist.

Evolve Continuous passt, wenn:

• Die Plattform produktiv läuft und weiter gepflegt werden soll
• Kein internes Cloud-Engineering-Team aufgebaut werden soll oder kann
• Planbare monatliche Kosten wichtiger sind als maximale Flexibilität
• Proaktive Wartung höher priorisiert wird als „wir kümmern uns, wenn etwas kaputt geht“
• Die Arbeitskultur agil ist: direkte Kommunikation, schnelle Entscheidungen, pragmatische Zusammenarbeit

Evolve Continuous passt nicht, wenn:

• Ihr ein internes Team aufbaut, das Vollzeit für die Plattform zuständig sein soll — dann ist externe Betreuung Overhead
• Ihr eine sehr stabile Plattform mit minimalen Änderungen betreibt und T&M-Beauftragung günstiger wäre
• Eure Arbeitskultur prozessorientiert ist: formale Change-Prozesse, Ticket-System als primärer Kommunikationsweg, lückenlose Audit-Trails als Anforderung. In diesem Fall ist cloudopserve, unser Partner für strukturierten Managed-Betrieb, die bessere Wahl
• Ihr 24/7-Operations mit Minuten-SLAs braucht. Evolve Continuous arbeitet innerhalb normaler Arbeitszeiten, keine Rund-um-die-Uhr-Bereitschaft

Der Unterschied zwischen Evolve Continuous und cloudopserve ist keine Frage von Features oder Preis. Er ist eine Frage der Arbeitskultur. Wie kommuniziert ihr? Per Teams und Standup — oder per Ticket-System mit Freigabeprozess? Die Antwort bestimmt, welches Modell passt. Wir beraten ehrlich, welches das ist — auch wenn es bedeutet, einen anderen Anbieter zu empfehlen.

Fazit: Plattformbetrieb ist kein Projektabschluss

Cloud-Plattformen sind keine Projekte mit einem Ende. Sie sind lebende Systeme in einer sich verändernden technischen Umgebung. Security-Lücken entstehen. Provider-APIs werden abgekündigt. Teams wechseln. Anforderungen entwickeln sich.

Die Frage ist nicht, ob Wartung und Weiterentwicklung Ressourcen kosten. Die Frage ist, ob diese Ressourcen geplant und strukturiert fließen — oder ungeplant und teuer, wenn Probleme eskalieren.

Ein embedded Platform Team ist unser Modell für die planbare Variante — bei uns Evolve Continuous genannt. Proaktiv, agil, dasselbe Team, das die Plattform kennt. Keine Reaktiv-Feuerwehr, kein Ticket-Overhead — direkte Zusammenarbeit, solange es läuft.

Wenn ihr gerade ein Kubernetes-Cluster oder eine Cloud-Umgebung aufgebaut habt — oder bald abschließt — lohnt es sich, das Gespräch über die nächste Phase zu führen. Nicht als Verkaufsgespräch, sondern als ehrliche Einschätzung: Was braucht eure Plattform nach dem Go-Live, und welches Modell passt dazu?

Passende cloudpunks-Leistungen

• Kubernetes — Container-Plattformen aufbauen und über den Go-Live hinaus gesund halten
• Platform Engineering — Self-Service-Plattformen, die Developer-Teams unabhängiger machen
• Landing Zone — Das saubere Fundament für alles, was nach dem ersten Projekt kommt

Unverbindlich über eure Plattformsituation reden →

Wir schauen uns an, wo ihr steht, und sagen euch direkt, ob und wie kontinuierliche Betreuung für euch Sinn macht.