ROI von Managed Services: Warum Eigenbetrieb oft teurer ist

Wer Kubernetes selbst betreibt, hat das Gefühl, die Kontrolle zu behalten und Geld zu sparen. Managed Services wirken auf den ersten Blick teurer, weil die Kosten sichtbar auf der Rechnung stehen. Beim Eigenbetrieb dagegen verteilen sich die Kosten auf Stunden, Ausfälle und verpasste Produktfeatures und bleiben deshalb oft unsichtbar. Dieser Artikel zeigt, wie eine vollständige TCO-Rechnung aussieht und wann der ROI von Managed Services die Kalkulation kippt.

Was gehört wirklich in die Kostenrechnung?

Die häufigste Fehlerquelle bei der Entscheidung Self-Hosted vs. Managed ist eine unvollständige Kostenbasis. Teams vergleichen Serverkosten mit dem Monatspreis eines Managed Service und wundern sich, warum der Managed Service teurer wirkt.

Direkte Kosten: Server, Lizenzen, Tools

Die direkten Kosten sind gut greifbar: VMs oder Bare-Metal-Server, Speicher, Netzwerk, Load Balancer, ggf. Enterprise-Lizenzen für Logging, Monitoring oder Service Mesh. Dazu kommen CI/CD-Tooling, Container-Registry und Backup-Infrastruktur. Ein mittelgroßer Kubernetes-Cluster für eine Produktionsanwendung mit zwei bis drei Knoten kommt schnell auf 400–800 € pro Monat allein für die Rechenkapazität, ohne alles andere.

Indirekte Kosten: Personal, Wartung, Bereitschaft

Hier liegt das eigentliche Problem. Ein produktionsfähiger Kubernetes-Cluster braucht laufende Pflege: Sicherheitsupdates, Kubernetes-Versionsupdates (alle drei Monate eine neue Minor-Version), Zertifikatserneuerungen, etcd-Backups, Node-Maintenance. Wer das intern betreibt, bindet DevOps-Kapazität.

Realistisch gerechnet: Ein Senior-DevOps-Engineer kostet in Deutschland inklusive Arbeitgeberanteil, Ausstattung und Overhead 80.000–100.000 € pro Jahr. Wenn dieser Engineer 20 % seiner Zeit für Cluster-Betrieb aufwendet – was bei einem einzelnen Produktionscluster konservativ ist –, sind das 16.000–20.000 € pro Jahr, die direkt dem Kubernetes-Betrieb zuzurechnen sind. Pro Monat: 1.300–1.700 €.

Dazu kommt die Bereitschaft. Wer Produktionssysteme selbst betreibt, braucht eine On-Call-Rotation. Bei kleinen Teams bedeutet das, dass dieselben Personen, die tagsüber entwickeln, nachts alarmiert werden können. Der Erschöpfungs- und Fehlereffekt dabei ist real – und schwer in Euro zu fassen, bis etwas schiefgeht.

Kubernetes selbst betreiben. Was das wirklich bedeutet

Kubernetes ist kein System, das man einmal aufsetzt und dann läuft. Es ist eine lebende Infrastruktur, die kontinuierlich Aufmerksamkeit braucht.

Der Upgrade-Aufwand, den niemand plant

Kubernetes veröffentlicht alle drei Monate eine neue Minor-Version, jede wird für zwölf Monate mit Patches versorgt. Wer nicht regelmäßig upgradet, läuft in eine Supportlücke und dann in ein Sicherheitsproblem. Ein Cluster-Upgrade in einer Produktionsumgebung ist kein Knopfdruck: Kompatibilität von Add-ons prüfen, API-Deprecations berücksichtigen, Testumgebungen upgraden, Rollback-Plan erstellen, Maintenance-Fenster koordinieren. Erfahrene Teams rechnen mit 1–2 Tagen pro Upgrade-Zyklus.

Das sind bei vier Upgrades im Jahr 4–8 Engineeringtage allein für Kubernetes-Versionsmanagement, ohne ungeplante Patches für kritische CVEs, die kurzfristig ausgerollt werden müssen.

Monitoring, Alerting, Incident Response

Ein produktionstaugliches Monitoring-Setup für Kubernetes ist kein Nachmittagsprojekt. Prometheus, Grafana, Alertmanager, Loki oder ein alternatives Log-Backend. Das Setup allein dauert mehrere Tage, die Pflege danach ist kontinuierlich. Dashboards veralten, Alerts müssen kalibriert werden, neue Services brauchen neue Metriken.

Und wenn ein Incident eintritt? Die mittlere Zeit bis zur Erkennung (MTTD) und bis zur Behebung (MTTR) hängt direkt an der Reife der eigenen Observability-Infrastruktur. Ein schlecht konfiguriertes Monitoring ist manchmal gefährlicher als gar keins, weil es falsche Sicherheit gibt.

Ausfallkosten sind in den meisten Kalkulationen gar nicht enthalten. Dabei sind sie oft der größte Einzelposten: Eine Stunde Ausfall in einem E-Commerce-System oder einer SaaS-Anwendung kann tausende Euro kosten in entgangenem Umsatz, SLA-Strafen oder Reputationsschäden.

Der ROI von Managed Services richtig berechnen

Ein einfaches Modell hilft, die Zahlen greifbar zu machen.

Ein einfaches Rechenmodell

Angenommen, ein Team betreibt einen mittelgroßen Kubernetes-Cluster mit drei Worker-Nodes:

Die Zahlen sind Richtwerte und hängen stark vom Team und der Komplexität ab, aber sie zeigen, in welcher Größenordnung die Differenz liegen kann. Der ROI von Managed Services ergibt sich nicht aus dem Vergleich von Listenpreisen, sondern aus dem Vergleich echter Gesamtkosten.

Opportunity Cost: Was Ihr Team stattdessen tun könnte

Der am schwierigsten zu quantifizierende, aber oft wichtigste Faktor ist die Opportunitätskosten. Zeit, die ein DevOps-Engineer mit Kubernetes-Upgrades, Alerting-Tuning oder Node-Debugging verbringt, ist Zeit, die nicht für Produktfeatures, bessere Developer Experience oder strategische Infrastrukturprojekte genutzt wird.

Bei einem fünfköpfigen Team, das 30 % seiner Kapazität mit Plattformbetrieb beschäftigt ist, spricht man über 1,5 Vollzeitstellen. Was könnte dieses Team in der Zeit bauen? Für wachstumsorientierte Unternehmen ist das keine rhetorische Frage, es ist eine strategische.

Wann Self-Hosted trotzdem Sinn ergibt

Managed Services sind kein Allheilmittel. Es gibt Szenarien, in denen Eigenbetrieb die richtige Entscheidung ist:

• Sehr spezifische Hardware-Anforderungen, die kein Managed Provider unterstützt (z. B. proprietäre GPUs, spezieller Netzwerk-Stack)
• Regulatorische Anforderungen, die explizit physische Kontrolle über Hardware verlangen (selten, aber existent)
• Interne Kompetenzaufbau-Strategie: Wenn ein Unternehmen bewusst Plattform-Know-how intern aufbauen will und die Kosten dafür als Investment bewertet
• Sehr hohe Workloads, bei denen Self-Hosted ab einem bestimmten Scale günstiger wird – das ist aber bei den wenigsten Unternehmen der Fall

Der kritische Unterschied: Diese Entscheidungen sollten bewusst und mit vollständiger Kostentransparenz getroffen werden, nicht aus dem Bauchgefühl heraus, dass Eigenbetrieb "günstiger" ist.

Compliance und Sicherheit: Wer trägt die Verantwortung?

Ein Aspekt, der in TCO-Diskussionen selten auftaucht: die Compliance-Last. Wer Kubernetes selbst betreibt, ist selbst verantwortlich für Sicherheitsupdates, CVE-Patching, Audit-Logs, Verschlüsselung, Zugriffskontrollen und die Dokumentation all dessen, relevant für DSGVO, BSI-Grundschutz, ISO 27001 oder branchenspezifische Anforderungen.

Das bedeutet nicht nur technischen Aufwand, sondern auch Dokumentations- und Nachweispflichten. Auditoren fragen nach Prozessen, Verantwortlichkeiten und Nachweisen. Das kostet Zeit und in regulierten Branchen kann der Aufwand erheblich sein.

Ein qualifizierter Managed Service übernimmt einen großen Teil dieser Verantwortung und liefert in der Regel Zertifizierungen und Dokumentation mit. Das ist nicht nur Komfort, sondern ein echter Risikotransfer.

Fazit: Managed Services als strategische Entscheidung

Die Frage ist nicht "Managed oder Self-Hosted?", sondern "Was ist der tatsächliche Preis jeder Option und was wollen wir mit unserer Zeit anfangen?" Wer die vollständige TCO-Rechnung aufstellt, kommt in den meisten Fällen zu einem anderen Ergebnis als beim intuitiven Vergleich von Serverpreisen.

Der ROI von Managed Services liegt nicht nur in gesparten Euro, sondern in gewonnener Kapazität für Produktentwicklung, Stabilität und das, wofür das Team eigentlich da ist. Infrastruktur zu betreiben ist kein Wettbewerbsvorteil. Was darauf läuft, schon.

lowcloud bietet eine DevOps-as-a-Service-Plattform mit Managed Kubernetes im Kern auf Basis souveräner europäischer Infrastruktur ohne Vendor Lock-in, mit klaren SLAs und vollem Fokus auf Datenschutz nach deutschem und europäischem Recht. Wer wissen will, ob sich ein Wechsel rechnet, kann die eigene Infrastruktur mit einem konkreten Angebot vergleichen lassen.