Managed Kubernetes oder Self Hosted?

Wer heute eine Plattform modernisiert, landet schnell bei derselben Frage: managed kubernetes oder self hosted? Auf dem Whiteboard wirkt beides oft ähnlich - Container, Cluster, Deployments, Skalierung. Im produktiven Betrieb trennt sich das aber sehr deutlich. Denn die eigentliche Entscheidung betrifft nicht nur Technologie, sondern Verantwortung, Risiko, Geschwindigkeit und laufende Kosten.

Für mittelständische Unternehmen ist das keine akademische Architekturfrage. Wenn Releases hängen, Patches liegen bleiben oder der Bereitschaftsdienst nachts wegen eines Control-Plane-Problems ausrückt, wird aus einer Infrastrukturentscheidung sehr schnell ein Business-Thema. Genau deshalb lohnt sich ein nüchterner Blick auf beide Modelle.

Managed Kubernetes oder Self Hosted: Worum es wirklich geht

Managed Kubernetes bedeutet, dass ein Cloud-Anbieter oder Plattformbetreiber zentrale Teile des Kubernetes-Betriebs übernimmt. Dazu gehören je nach Angebot vor allem die Control Plane, Upgrades, Verfügbarkeit kritischer Kernkomponenten und oft auch Teile von Monitoring, Networking oder Node-Management. Ihr Team konzentriert sich stärker auf Workloads, Deployment-Prozesse, Security Policies und Kostensteuerung.

Self hosted heißt dagegen: Sie betreiben Kubernetes selbst. Das kann auf eigener Hardware, in Colocation-Umgebungen oder auf virtuellen Maschinen in der Cloud passieren. Sie verantworten dann nicht nur die Anwendungen, sondern auch Cluster-Setup, Hochverfügbarkeit, Versionierung, Zertifikate, Netzwerkpfade, Backup-Strategien für den Cluster-Status und die Reaktion auf Störungen in der Plattform selbst.

Der Unterschied liegt also nicht in der Frage, ob Kubernetes eingesetzt wird, sondern wer die betriebliche Last trägt. Und genau diese Last wird in Entscheidungen regelmäßig unterschätzt.

Wann Managed Kubernetes der bessere Weg ist

Managed Services sind meist die sinnvollere Wahl, wenn ein Unternehmen schneller produktiv werden will und Plattformbetrieb nicht zum eigenen Kerngeschäft gehört. Das betrifft viele mittelständische Teams, die digitale Produkte entwickeln, aber keine eigene SRE- oder Plattform-Organisation in ausreichender Tiefe aufbauen wollen.

Der größte Vorteil ist Fokus. Ihr Team arbeitet an Anwendungen, Schnittstellen, Datenflüssen und Release-Automatisierung, statt Zeit in den Unterbau zu investieren. Ein Cluster ist dann kein Nebenprojekt mit dauerhaften Folgekosten, sondern eine belastbare Betriebsplattform.

Dazu kommt die geringere operative Komplexität. Bei einem Managed-Angebot entfallen viele typische Baustellen: Etcd-Verfügbarkeit, Absicherung der API-Server, Rollout-Strategien für Cluster-Upgrades oder das Debugging von Control-Plane-Problemen. Das reduziert nicht nur Aufwand, sondern auch das Risiko, dass kritisches Wissen an einzelnen Personen hängt.

Auch wirtschaftlich ist managed oft stärker, als es auf den ersten Blick wirkt. Zwar erscheinen Self-Hosted-Setups in einzelnen Kostenzeilen günstiger, weil keine Management-Gebühren anfallen. Realistisch betrachtet müssen aber Rufbereitschaft, Spezialwissen, Update-Fenster, Incident-Management, Automatisierung und Compliance mitgerechnet werden. Sobald diese Aufwände sauber bewertet werden, kippt die Rechnung häufig zugunsten eines Managed-Modells.

Für Teams mit hohem Release-Druck ist das besonders relevant. Wer mehrere Umgebungen betreibt, CI/CD standardisieren will und gleichzeitig Security- und Audit-Anforderungen erfüllen muss, profitiert davon, wenn die Plattformbasis zuverlässig und planbar bereitsteht.

Typische Einsatzfälle für managed

Managed Kubernetes passt gut, wenn Workloads cloudnah sind, wenn die Skalierung schwankt oder wenn Time-to-Market wichtiger ist als maximale Eingriffstiefe in jede Schicht des Clusters. Auch bei wachsendem Produktgeschäft ist es oft der vernünftigere Weg, weil Betrieb standardisiert und schneller professionalisiert werden kann.

Gerade bei SaaS-Plattformen, E-Commerce-Systemen oder API-zentrierten Architekturen zählt weniger, wer die Control Plane selbst installiert hat, sondern ob Deployments sicher laufen, Services ausfallsicher erreichbar sind und Kosten transparent bleiben.

Wann Self Hosted sinnvoll sein kann

Self hosted ist nicht per se die falsche Entscheidung. Es gibt klare Szenarien, in denen ein eigener Betrieb strategisch oder technisch sinnvoll ist. Das gilt vor allem dann, wenn regulatorische Anforderungen, Spezialhardware, Netzwerktopologien oder sehr spezifische Integrationen gegen ein Standard-Managed-Angebot sprechen.

Wenn ein Unternehmen bereits eine starke interne Plattformmannschaft hat, Prozesse für Incident Response etabliert sind und Kubernetes-Kompetenz operativ vorhanden ist, kann self hosted mehr Gestaltungsspielraum bringen. Das betrifft etwa Sonderanforderungen an Bare-Metal-Performance, Edge-Szenarien, stark isolierte Umgebungen oder Infrastrukturen, die bewusst unabhängig von bestimmten Cloud-Providern betrieben werden sollen.

Self hosted kann auch dann attraktiv sein, wenn die Umgebung sehr stabil, langfristig planbar und hoch standardisiert ist. In solchen Fällen lässt sich die Plattform mit genügend Know-how wirtschaftlich betreiben. Die Voraussetzung ist allerdings, dass dieser Betrieb bewusst als Produkt verstanden wird - mit klaren Zuständigkeiten, Automatisierung, Patch-Management, Backup-Tests, Observability und dokumentierten Betriebsprozessen.

Was nicht funktioniert: ein Self-Hosted-Cluster als vermeintlich günstige Bastellösung neben dem Tagesgeschäft. Genau dort entstehen die teuersten Risiken.

Die versteckten Kosten bei self hosted

Viele Entscheidungen für Self Hosted werden mit Kontrolle oder Kosteneffizienz begründet. Beides kann zutreffen, aber nur unter sauberen Rahmenbedingungen. Die eigentlichen Kosten liegen selten in den VMs oder der Hardware, sondern im laufenden Betrieb.

Ein Cluster braucht Lifecycle-Management. Versionen müssen geplant aktualisiert werden, Add-ons müssen kompatibel bleiben, Zertifikate laufen ab, Security-Lücken müssen kurzfristig geschlossen werden. Dazu kommen Themen wie Ingress, DNS, Secret-Management, Netzwerkpolicies, Storage-Klassen, Logging, Alerting und die Frage, wie Störungen außerhalb der Anwendungslogik erkannt und behoben werden.

Je geschäftskritischer die Plattform ist, desto höher wird der Anspruch an Hochverfügbarkeit. Dann reicht kein Setup, das irgendwie funktioniert. Dann braucht es belastbare Betriebsmodelle, klare SLAs, Eskalationspfade und regelmäßige Tests von Restore- und Recovery-Szenarien. Genau an diesem Punkt wird Self Hosted organisatorisch anspruchsvoll.

Für Entscheider ist deshalb eine einfache Frage hilfreich: Möchten Sie ein Produkt bauen - oder zusätzlich eine Plattformorganisation betreiben? Wenn Letzteres nicht Teil der strategischen Planung ist, wird self hosted schnell zum Engpass.

Managed Kubernetes oder Self Hosted bei Sicherheit und Compliance

Sicherheit ist kein Argument, das automatisch für eine Seite spricht. Beide Modelle können sicher betrieben werden, beide können Schwachstellen haben. Der Unterschied liegt wieder in der operativen Reife.

Managed Kubernetes reduziert oft die Angriffsfläche im Bereich der Control Plane und beschleunigt sicherheitsrelevante Updates. Das ist ein klarer Vorteil, vor allem wenn interne Kapazitäten begrenzt sind. Gleichzeitig bleiben Themen wie Mandantentrennung, IAM, Container-Härtung, Image-Scanning, Secret-Handling und Netzwerksegmentierung weiterhin in Ihrer Verantwortung.

Bei self hosted haben Sie mehr direkte Kontrolle, aber auch mehr Pflichten. Wer volle Kontrolle will, muss sie auch ausüben können. Das ist bei Audits, Dokumentationspflichten und forensischer Nachvollziehbarkeit kein kleiner Unterschied. In regulierten Umfeldern kann self hosted richtig sein - aber nur, wenn Governance und Betrieb zusammenpassen.

Die eigentliche Entscheidungslogik für den Mittelstand

In vielen mittelständischen Unternehmen ist die wichtigste Frage nicht, welches Modell technisch eleganter ist. Entscheidend ist, welches Modell die bessere Kombination aus Verfügbarkeit, Geschwindigkeit und wirtschaftlicher Steuerbarkeit liefert.

Wenn ein internes Team klein ist, aber geschäftskritische Systeme betreut, spricht vieles für managed. Wenn Produktentwicklung beschleunigt werden soll, ist weniger Plattformlast fast immer ein Vorteil. Wenn dagegen besondere Infrastrukturvorgaben bestehen und der Betrieb organisatorisch sauber aufgestellt ist, kann self hosted tragfähig sein.

Pragmatisch betrachtet sollte die Entscheidung an vier Punkten hängen: vorhandene Betriebskompetenz, regulatorische Rahmenbedingungen, geforderte Flexibilität und echte Vollkosten über mindestens drei Jahre. Wer nur auf die offensichtlichen Infrastrukturkosten schaut, entscheidet oft zu kurz.

Ein weiteres Kriterium ist die Störungsfähigkeit des Unternehmens. Nicht jede Organisation kann oder will nachts Control-Plane-Incidents behandeln, Upgrade-Probleme analysieren oder Netzwerkfehler in der Cluster-Ebene eingrenzen. Dann ist es vernünftig, Verantwortung gezielt abzugeben, statt sie formal zu behalten und praktisch nicht abdecken zu können.

Ein pragmatischer Weg statt Grundsatzdebatte

Die Entscheidung muss nicht ideologisch sein. In der Praxis funktionieren hybride Modelle oft gut. Manche Unternehmen starten mit Managed Kubernetes, standardisieren Deployments, Security und Observability und prüfen erst später, ob einzelne Workloads aus guten Gründen in ein eigenes Setup gehören. Andere betreiben bestimmte sensible Umgebungen self hosted und nutzen für weniger kritische oder dynamische Anwendungen bewusst Managed Services.

Wichtig ist, dass das Betriebsmodell zur Realität des Teams passt. Kubernetes belohnt keine Prinzipientreue, sondern saubere Verantwortung. Wer das klar trennt, reduziert Risiken und schafft die Grundlage für verlässliche Releases, stabile Plattformen und kontrollierbare Kosten.

Genau an dieser Stelle zeigt sich der Unterschied zwischen einer technischen Installation und produktionsreifem Betrieb. Ein Cluster ist schnell erstellt. Eine Plattform, die unter Last, bei Audits und in Störungen überzeugt, entsteht erst durch gutes Engineering und disziplinierten Betrieb. Wer managed kubernetes oder self hosted bewertet, sollte deshalb nicht fragen, was theoretisch möglich ist, sondern was unter realen Bedingungen dauerhaft tragfähig bleibt.