Warum Kubernetes-Projekte langfristig aufwendig werden – und wie Unternehmen die Komplexität beherrschen

Im ersten Teil dieses Artikels haben wir betrachtet, warum Unternehmen den Aufwand rund um Kubernetes häufig systematisch unterschätzen. Wir haben gesehen, dass Kubernetes in erster Linie ein Orchestrierungssystem ist, dessen Aufgabe darin besteht, den gewünschten Zustand einer Container-Infrastruktur kontinuierlich durchzusetzen. Ebenso wurde deutlich, dass viele der Aufgaben, die einen stabilen Plattformbetrieb überhaupt erst ermöglichen, bewusst außerhalb des Kubernetes-Kerns liegen.

Damit stellt sich zwangsläufig die nächste Frage:

Wo entsteht der tatsächliche Aufwand im täglichen Betrieb einer Kubernetes-Plattform?

Die Antwort lautet nicht: im Cluster.

Sie entsteht überall dort, wo technische Entscheidungen auf operative Verantwortung treffen.

---

Observability: Warum funktionierende Anwendungen trotzdem ausfallen

Kaum ein Begriff hat sich in den vergangenen Jahren so stark etabliert wie Observability. Gleichzeitig gibt es nur wenige Konzepte, die häufiger missverstanden werden.

Nicht selten wird Observability als modernes Synonym für Monitoring verwendet. Tatsächlich unterscheiden sich beide Konzepte jedoch grundlegend.

Wer diesen Unterschied nicht versteht, wird früher oder später feststellen, dass eine Plattform zwar hervorragend überwacht wird – Fehler jedoch trotzdem stundenlang unentdeckt bleiben oder ihre eigentliche Ursache nicht nachvollziehbar ist.

Monitoring beantwortet bekannte Fragen

Monitoring gehört seit Jahrzehnten zu den Grundlagen professioneller IT-Betriebsprozesse.

Die Idee ist einfach.

Ein System sammelt Messwerte.

CPU-Auslastung.

Arbeitsspeicher.

Festplattenbelegung.

Antwortzeiten.

Netzwerkdurchsatz.

Anschließend werden Grenzwerte definiert.

Steigt die CPU-Auslastung über 90 Prozent, wird ein Alarm ausgelöst.

Antwortet ein HTTP-Endpunkt nicht mehr, erhält das Bereitschaftsteam eine Benachrichtigung.

Diese Vorgehensweise funktioniert erstaunlich gut – solange die Fragen bereits bekannt sind.

Genau darin liegt allerdings ihre größte Einschränkung.

Monitoring beantwortet ausschließlich Fragen, die vorher gestellt wurden.

Niemand konfiguriert einen Alarm für ein Problem, dessen Existenz noch unbekannt ist.

Verteilte Systeme verändern die Fehlersuche grundlegend

Dieses Problem fällt besonders in Kubernetes-Umgebungen auf.

Früher bestand eine Geschäftsanwendung häufig aus einem einzelnen Server.

Trat ein Fehler auf, meldete sich ein Administrator auf genau diesem System an, analysierte Logdateien und identifizierte die Ursache meist innerhalb kurzer Zeit.

Cloud-native Anwendungen funktionieren völlig anders.

Eine einzige Benutzeranfrage durchläuft heute häufig eine Vielzahl voneinander unabhängiger Dienste.

Ein API-Gateway.

Einen Authentifizierungsdienst.

Mehrere Microservices.

Eine Message Queue.

Eine Datenbank.

Vielleicht zusätzlich einen Suchindex oder einen externen Zahlungsdienstleister.

Jede dieser Komponenten besitzt eigene Logdateien.

Eigene Metriken.

Eigene Fehlercodes.

Eigene Zeitstempel.

Eigene Netzwerkverbindungen.

Die eigentliche Schwierigkeit besteht deshalb nicht mehr darin, Daten zu sammeln.

Die Schwierigkeit besteht darin, die Zusammenhänge zwischen diesen Daten überhaupt erkennen zu können.

Ein Beispiel aus der Praxis

Nehmen wir an, die Antwortzeit einer Webanwendung steigt plötzlich von 150 Millisekunden auf über drei Sekunden.

Der Alarm schlägt an.

Das Monitoring meldet erhöhte Latenzen.

Was nun?

Die CPU-Auslastung aller Pods liegt unter zwanzig Prozent.

Arbeitsspeicher ist ausreichend vorhanden.

Auch das Netzwerk zeigt keine Auffälligkeiten.

Der Kubernetes-Cluster selbst arbeitet völlig fehlerfrei.

An dieser Stelle endet klassisches Monitoring.

Es weiß lediglich, dass ein Problem existiert.

Nicht jedoch, warum.

Die eigentliche Ursache könnte völlig unterschiedlich aussehen.

Eine SQL-Abfrage verwendet plötzlich keinen Index mehr.

Ein DNS-Resolver antwortet verzögert.

Ein Storage-System benötigt ungewöhnlich lange für Schreibzugriffe.

Ein externer Authentifizierungsdienst liefert Antworten mit hoher Latenz.

Eine Bibliothek erzeugt durch einen Fehler tausende zusätzliche Datenbankabfragen.

Ein Kubernetes-Cluster kann all diese Szenarien problemlos orchestrieren.

Er erkennt jedoch keines davon.

Nicht weil Kubernetes unzureichend wäre.

Sondern weil dies nicht seine Aufgabe ist.

Observability beantwortet unbekannte Fragen

Hier setzt Observability an.

Während Monitoring auf vorher definierten Regeln basiert, verfolgt Observability einen grundlegend anderen Ansatz.

Das Ziel besteht nicht darin, möglichst viele Alarme zu erzeugen.

Das Ziel besteht darin, den inneren Zustand eines Systems anhand seiner Telemetriedaten nachvollziehen zu können.

Der Begriff stammt ursprünglich aus der Regelungstechnik.

Ein System gilt als beobachtbar, wenn sich sein interner Zustand ausschließlich anhand seiner Ausgaben rekonstruieren lässt.

Übertragen auf Software bedeutet das:

Ein Betreiber soll nachvollziehen können, warum sich ein System auf eine bestimmte Weise verhält, ohne die Anwendung verändern oder zusätzliche Debug-Ausgaben aktivieren zu müssen.

Genau deshalb umfasst Observability deutlich mehr als Dashboards.

Sie verbindet drei unterschiedliche Datenquellen.

Metriken.

Logs.

Und sogenannte Distributed Traces.

Warum Logs alleine nicht mehr ausreichen

Logs gehören zu den ältesten Werkzeugen der Softwareentwicklung.

Sie dokumentieren Ereignisse.

Ein Benutzer meldet sich an.

Eine Datenbankverbindung wird geöffnet.

Eine Anfrage schlägt fehl.

Ein Hintergrundprozess startet.

Bei einer einzelnen Anwendung funktioniert dieses Prinzip hervorragend.

In einer Microservice-Architektur entsteht jedoch schnell ein anderes Bild.

Stellen wir uns einen Bestellvorgang in einem Online-Shop vor.

Eine einzige Bestellung erzeugt möglicherweise Einträge in zehn verschiedenen Anwendungen.

Im API-Gateway.

Im Authentifizierungsdienst.

Im Warenkorb.

Im Zahlungsservice.

Im Lagerverwaltungssystem.

Im Rechnungsservice.

Im Versanddienst.

Im Benachrichtigungssystem.

Jede Anwendung schreibt ihre eigene Logdatei.

Ohne gemeinsamen Bezugspunkt existieren plötzlich tausende voneinander unabhängige Einträge.

Die eigentliche Geschichte der Anfrage geht verloren.

Distributed Tracing macht Anfragen sichtbar

Genau hier liegt der enorme Wert von Distributed Tracing.

Jede eingehende Anfrage erhält eine eindeutige Identität.

Diese sogenannte Trace-ID begleitet die Anfrage während ihres gesamten Lebenszyklus.

Jeder beteiligte Dienst ergänzt Informationen über die eigene Bearbeitung.

Dadurch entsteht eine vollständige Zeitleiste.

Welche Services wurden aufgerufen?

Wie lange dauerte jeder Verarbeitungsschritt?

Welche Datenbankabfrage verursachte die größte Verzögerung?

An welcher Stelle trat erstmals ein Fehler auf?

Anstatt hunderte Logdateien manuell auszuwerten, lässt sich der vollständige Ablauf einer einzelnen Benutzeranfrage innerhalb weniger Sekunden nachvollziehen.

Gerade in Kubernetes-Umgebungen ist diese Transparenz von unschätzbarem Wert.

Denn Kubernetes verschiebt Workloads permanent zwischen Nodes.

Pods werden ersetzt.

Container neu gestartet.

IP-Adressen ändern sich.

Statische Infrastruktur existiert praktisch nicht mehr.

Die eigentliche Konstante ist deshalb nicht der Server.

Sondern die Anfrage selbst.

OpenTelemetry verändert den Markt

Lange Zeit war Observability eng an einzelne Hersteller gebunden.

Jeder Anbieter verwendete eigene Agenten.

Eigene Datenformate.

Eigene Programmierschnittstellen.

Mit der Entstehung von OpenTelemetry hat sich diese Situation grundlegend verändert.

OpenTelemetry definiert heute einen offenen Standard für die Erfassung von Metriken, Logs und Traces.

Anwendungen instrumentieren sich einmalig gegen diesen Standard.

Die eigentliche Auswertung kann anschließend über unterschiedliche Plattformen erfolgen.

Prometheus.

Grafana.

Jaeger.

Tempo.

Elastic.

Datadog.

Dynatrace.

New Relic.

Dieser offene Ansatz passt hervorragend zur Philosophie von Kubernetes.

Nicht ein einzelnes Werkzeug steht im Mittelpunkt.

Entscheidend sind standardisierte Schnittstellen.

Warum Observability zur Plattformaufgabe wird

Spätestens an diesem Punkt zeigt sich erneut ein Muster, das uns bereits in den vorherigen Kapiteln begegnet ist.

Kubernetes liefert keine vollständige Lösung.

Es schafft die Voraussetzungen dafür, dass spezialisierte Lösungen integriert werden können.

Eine leistungsfähige Observability-Plattform entsteht deshalb niemals durch die Installation eines einzelnen Werkzeugs.

Sie beginnt bereits bei der Architektur einer Anwendung.

Welche Metriken werden erhoben?

Welche Ereignisse werden protokolliert?

Wie werden Logs strukturiert?

Welche Trace-Kontexte werden zwischen Diensten übertragen?

Welche Informationen dürfen aus Datenschutzgründen überhaupt gespeichert werden?

Wie lange werden Telemetriedaten aufbewahrt?

Wer besitzt Zugriff auf Produktionsdaten?

Wie werden Alarmregeln priorisiert?

Wer reagiert außerhalb der Geschäftszeiten?

Diese Fragestellungen reichen weit über die Installation eines Prometheus Operators oder einer Grafana-Instanz hinaus.

Sie betreffen Architektur, Betrieb, Compliance und organisatorische Prozesse gleichermaßen.

Gute Observability reduziert keine Fehler – sie reduziert ihre Auswirkungen

An dieser Stelle entsteht häufig ein Missverständnis.

Observability verhindert keine Ausfälle.

Sie beschleunigt auch keine Anwendungen.

Sie reduziert weder den Speicherbedarf noch verbessert sie automatisch die Verfügbarkeit.

Ihr eigentlicher Nutzen liegt an einer anderen Stelle.

Sie verkürzt die Zeit zwischen dem Auftreten eines Problems und dessen tatsächlicher Behebung.

In der Betriebswirtschaft spricht man häufig von den Kennzahlen MTTD (Mean Time to Detect) und MTTR (Mean Time to Recover).

Je schneller ein Problem erkannt wird und je schneller seine Ursache eindeutig identifiziert werden kann, desto geringer fallen wirtschaftliche Schäden, Reputationsverluste und Betriebsunterbrechungen aus.

Gerade bei geschäftskritischen Anwendungen entscheidet deshalb nicht allein die Wahrscheinlichkeit eines Fehlers über die Qualität einer Plattform.

Entscheidend ist vielmehr, wie schnell ein Unternehmen nach einem unvermeidbaren Fehler wieder handlungsfähig wird.

Und genau deshalb gehört Observability heute zu den zentralen Disziplinen professionellen Plattformbetriebs.

Nicht weil moderne Anwendungen häufiger ausfallen.

Sondern weil ihre innere Komplexität so stark zugenommen hat, dass klassische Überwachungsmethoden den tatsächlichen Zustand verteilter Systeme nicht mehr zuverlässig beschreiben können.

Im nächsten Kapitel betrachten wir einen Bereich, dessen Bedeutung in den vergangenen Jahren mindestens ebenso stark gewachsen ist: die Sicherheit cloud-nativer Plattformen – und warum Kubernetes zwar zahlreiche Sicherheitsmechanismen bereitstellt, daraus jedoch noch lange kein Sicherheitskonzept entsteht.

Sicherheit in Kubernetes: Warum ein sicherer Cluster noch keine sichere Plattform ist

Kaum ein Aspekt wird bei der Einführung von Kubernetes so kontrovers diskutiert wie die Sicherheit.

Die einen betrachten Kubernetes als besonders komplex und damit zwangsläufig als schwer abzusichern. Andere argumentieren genau umgekehrt und verweisen auf die zahlreichen Sicherheitsmechanismen, die Kubernetes bereits standardmäßig mitbringt. Beide Sichtweisen greifen zu kurz.

Kubernetes ist weder per se sicher noch unsicher.

Es stellt einen umfangreichen Werkzeugkasten zur Verfügung, mit dem sich sehr sichere Plattformen realisieren lassen. Gleichzeitig lässt sich mit denselben Werkzeugen innerhalb weniger Minuten eine Plattform erzeugen, deren Angriffsfläche erheblich größer ist als die einer klassischen Serverlandschaft.

Entscheidend ist deshalb nicht, welche Sicherheitsfunktionen Kubernetes besitzt.

Entscheidend ist, welche Verantwortung Kubernetes überhaupt übernehmen kann – und welche Verantwortung zwangsläufig beim Betreiber verbleibt.

Sicherheit ist kein Produktmerkmal

Einer der größten Denkfehler moderner IT besteht darin, Sicherheit als Eigenschaft einer einzelnen Technologie zu betrachten.

Man hört Formulierungen wie:

“Unsere Infrastruktur ist sicher, weil wir Kubernetes einsetzen.”

Oder:

“Wir betreiben unsere Anwendungen in einer Private Cloud, deshalb sind wir sicher.”

Diese Aussagen sind ungefähr so sinnvoll wie die Behauptung, ein Gebäude sei sicher, weil es aus Beton gebaut wurde.

Natürlich spielt das Baumaterial eine Rolle.

Ob das Gebäude jedoch tatsächlich sicher ist, hängt von Zutrittskontrollen, Fluchtwegen, Brandschutz, Wartung, Überwachung und zahlreichen organisatorischen Maßnahmen ab.

Mit IT-Infrastrukturen verhält es sich nicht anders.

Sicherheit entsteht niemals durch die Wahl einer Technologie.

Sicherheit entsteht durch die konsequente Umsetzung eines Sicherheitskonzeptes.

Kubernetes schützt nicht vor schlechten Entscheidungen

Nehmen wir ein einfaches Beispiel.

Ein Entwickler erstellt einen Container.

Innerhalb des Containers läuft die Anwendung als Benutzer root.

Aus Sicht von Kubernetes ist daran zunächst nichts ungewöhnlich.

Der Container startet.

Die Anwendung funktioniert.

Die Plattform arbeitet wie vorgesehen.

Aus sicherheitstechnischer Sicht entsteht jedoch ein unnötiges Risiko.

Gelingt es einem Angreifer, die Anwendung zu kompromittieren, verfügt der Schadcode innerhalb des Containers bereits über weitreichende Berechtigungen.

Kubernetes hätte dies durchaus verhindern können.

Nicht automatisch.

Aber über sogenannte Security Contexts, Pod Security Standards oder Admission Controller.

Die eigentliche Entscheidung musste jedoch vorher getroffen werden.

Kubernetes erzwingt keine Sicherheitsstrategie.

Es setzt lediglich Regeln um, die ein Betreiber zuvor definiert hat.

Dieser Unterschied zieht sich durch nahezu alle Sicherheitsmechanismen der Plattform.

Authentifizierung ist nicht Autorisierung

Ein weiterer Bereich, der regelmäßig zu Missverständnissen führt, betrifft die Zugriffskontrolle.

Zunächst muss zwischen zwei Begriffen unterschieden werden, die häufig synonym verwendet werden, technisch jedoch vollkommen unterschiedliche Fragestellungen beantworten.

Authentifizierung beantwortet die Frage:

“Wer bist du?”

Autorisierung beantwortet dagegen:

“Was darfst du?”

Kubernetes besitzt hierfür ein ausgesprochen flexibles Berechtigungssystem.

Role Based Access Control – kurz RBAC – erlaubt die Definition sehr feingranularer Berechtigungen.

Ein Benutzer darf beispielsweise Deployments aktualisieren.

Ein anderer lediglich Logs lesen.

Ein Service Account darf Secrets abrufen.

Ein Operator erhält ausschließlich Zugriff auf seine eigenen Custom Resources.

Theoretisch lässt sich nahezu jede Berechtigung präzise modellieren.

Praktisch sieht die Realität häufig anders aus.

Unter Zeitdruck erhalten Entwickler Cluster-Administratorrechte.

Service Accounts verfügen über unnötig umfangreiche Berechtigungen.

Automatisierungsskripte arbeiten mit dauerhaft gültigen Zugangsdaten.

Nicht, weil Kubernetes dies verlangt.

Sondern weil einfache Lösungen kurzfristig attraktiver erscheinen als sauber modellierte Berechtigungskonzepte.

Gerade diese Abkürzungen zählen jedoch zu den häufigsten Ursachen späterer Sicherheitsprobleme.

Der Cluster endet nicht an der API

Viele Sicherheitsbetrachtungen konzentrieren sich ausschließlich auf Kubernetes selbst.

Dabei beginnt die eigentliche Angriffsfläche häufig lange bevor ein Angreifer den API-Server überhaupt erreicht.

Eine moderne Plattform besteht aus deutlich mehr Komponenten.

Container Images werden gebaut.

Artefakte werden in Registries gespeichert.

CI/CD-Pipelines erzeugen neue Releases.

Secrets werden bereitgestellt.

Git-Repositories enthalten Infrastrukturdefinitionen.

Identity Provider verwalten Benutzerkonten.

DNS-Systeme veröffentlichen Dienste.

Load Balancer terminieren TLS-Verbindungen.

Jede einzelne dieser Komponenten erweitert die Angriffsfläche.

Ein kompromittierter Build-Server kann schädlichen Code in ein Container-Image einschleusen.

Eine falsch konfigurierte Registry kann manipulierte Images ausliefern.

Ein gestohlener API-Schlüssel ermöglicht Zugriff auf Cloud-Ressourcen.

Ein unsicheres Git-Repository kann Infrastrukturdefinitionen verändern, lange bevor Kubernetes überhaupt beteiligt ist.

Der Cluster bildet deshalb lediglich einen Teil einer wesentlich größeren Plattform.

Wer ausschließlich den Cluster absichert, schützt häufig nur einen kleinen Teil des eigentlichen Systems.

Die Software-Lieferkette ist zur neuen Angriffsfläche geworden

Noch vor wenigen Jahren konzentrierte sich IT-Sicherheit vor allem auf Netzwerke.

Firewalls.

VPNs.

Segmentierung.

Perimeterschutz.

Mit der zunehmenden Verbreitung von Open Source und Cloud-native Architekturen hat sich dieser Schwerpunkt grundlegend verschoben.

Heute entstehen viele Risiken bereits während der Softwareentwicklung.

Kaum eine moderne Anwendung besteht ausschließlich aus selbst geschriebenem Code.

Ein typischer Microservice nutzt häufig mehrere hundert Bibliotheken.

Diese Bibliotheken besitzen wiederum eigene Abhängigkeiten.

Aus einigen hundert direkten Abhängigkeiten entstehen schnell mehrere tausend indirekte Komponenten.

Jede einzelne davon kann Sicherheitslücken enthalten.

Oder – wie Angriffe auf die Software-Lieferkette in den vergangenen Jahren eindrucksvoll gezeigt haben – bewusst manipuliert worden sein.

Genau deshalb gewinnen Begriffe wie Software Supply Chain Security, SBOM (Software Bill of Materials), Image Signing oder Provenance zunehmend an Bedeutung.

Ein Betreiber möchte heute nicht mehr nur wissen, welche Anwendung läuft.

Er möchte nachvollziehen können,

• aus welchem Quellcode sie entstanden ist,
• welche Bibliotheken enthalten sind,
• welcher Build-Prozess verwendet wurde,
• wer das Artefakt signiert hat,
• und ob das ausgelieferte Container-Image tatsächlich unverändert ist.

Diese Fragestellungen liegen vollständig außerhalb des eigentlichen Kubernetes-Kerns.

Sie entscheiden jedoch maßgeblich über die Sicherheit einer Plattform.

Sicherheit endet nicht mit dem Deployment

Selbst eine vollständig geprüfte Anwendung bleibt nur so lange sicher, bis sich ihre Umgebung verändert.

Neue Schwachstellen werden täglich veröffentlicht.

Bibliotheken altern.

Verschlüsselungsverfahren werden angepasst.

Betriebssysteme erhalten Sicherheitsupdates.

Container-Images müssen regelmäßig neu gebaut werden.

Hier zeigt sich ein grundlegender Unterschied zwischen klassischer Softwareentwicklung und Plattformbetrieb.

Während Entwickler häufig in Releases denken, denken Plattformteams in kontinuierlichen Risiken.

Eine Anwendung, die gestern noch als sicher galt, kann morgen bereits mehrere kritische Schwachstellen enthalten, obwohl kein Entwickler auch nur eine einzige Zeile Code verändert hat.

Genau deshalb reicht ein einmaliger Security-Scan nicht aus.

Sicherheit ist kein Meilenstein.

Sie ist ein permanenter Prozess.

Zero Trust verändert die Architektur moderner Plattformen

Parallel dazu hat sich in den vergangenen Jahren ein weiteres Sicherheitsprinzip etabliert.

Zero Trust.

Der Name wird häufig missverstanden.

Zero Trust bedeutet nicht, niemandem zu vertrauen.

Es bedeutet vielmehr, implizites Vertrauen vollständig abzuschaffen.

Früher galt innerhalb vieler Unternehmensnetzwerke ein einfaches Prinzip.

Wer sich einmal erfolgreich im internen Netzwerk befand, erhielt vergleichsweise umfangreiche Freiheiten.

Cloud-native Plattformen funktionieren anders.

Jede Kommunikation wird grundsätzlich überprüft.

Jede Identität muss sich authentifizieren.

Jede Verbindung benötigt eine explizite Berechtigung.

Dieses Prinzip beeinflusst mittlerweile nahezu sämtliche Architekturentscheidungen.

Service-to-Service-Authentifizierung.

Kurzlebige Tokens.

Workload Identities.

mTLS.

Network Policies.

Policy Engines.

Alle verfolgen letztlich dasselbe Ziel:

Vertrauen wird nicht vorausgesetzt.

Es wird für jede Interaktion neu nachgewiesen.

Warum Sicherheit immer eine Plattformdisziplin bleibt

Betrachtet man alle bisherigen Aspekte gemeinsam, entsteht ein klares Bild.

Ein Kubernetes-Cluster kann sicher konfiguriert werden.

Er kann gehärtet werden.

Er kann Netzwerkregeln durchsetzen.

Berechtigungen verwalten.

Container isolieren.

Policies anwenden.

Doch keine dieser Funktionen beantwortet die eigentliche Frage:

Wie entsteht eine sichere Plattform?

Die Antwort lautet:

Durch das Zusammenspiel technischer Maßnahmen, organisatorischer Prozesse und kontinuierlicher Überprüfung.

Welche Images dürfen überhaupt deployed werden?

Wie werden kritische CVEs priorisiert?

Wann müssen Container neu gebaut werden?

Wer genehmigt Änderungen an Infrastrukturdefinitionen?

Wie werden Secrets rotiert?

Welche Audit-Logs müssen revisionssicher gespeichert werden?

Wie wird überprüft, dass Sicherheitsrichtlinien tatsächlich eingehalten werden?

Erst die Summe dieser Entscheidungen bildet ein belastbares Sicherheitskonzept.

Und genau darin liegt die eigentliche Herausforderung.

Nicht Kubernetes macht Sicherheit kompliziert.

Moderne Softwareplattformen sind komplex geworden.

Kubernetes macht diese Komplexität lediglich sichtbar.

Hochverfügbarkeit, Backups und Disaster Recovery: Warum Resilienz kein Feature, sondern eine Architekturentscheidung ist

Kaum ein Begriff wird im Zusammenhang mit Cloud-native Architekturen häufiger verwendet als Hochverfügbarkeit.

Nahezu jeder Infrastrukturanbieter wirbt mit hochverfügbaren Plattformen. Kubernetes gilt ohnehin als Synonym für ausfallsichere Anwendungen. Die Erwartung ist deshalb verständlich: Wer Kubernetes einsetzt, erhält automatisch eine robuste und fehlertolerante Infrastruktur.

Wie so oft ist die Realität differenzierter.

Kubernetes besitzt hervorragende Mechanismen, um den Ausfall einzelner Komponenten zu kompensieren. Daraus folgt jedoch keineswegs, dass eine Anwendung hochverfügbar ist. Noch weniger bedeutet es, dass sich ein Unternehmen von einem schwerwiegenden Störfall zuverlässig erholen kann.

Zwischen High Availability (HA) und Disaster Recovery (DR) besteht ein fundamentaler Unterschied.

Und genau dieser Unterschied wird in vielen Projekten unterschätzt.

Kubernetes sorgt dafür, dass Container weiterlaufen

Beginnen wir mit der Stärke von Kubernetes.

Fällt ein Pod aus, startet Kubernetes automatisch einen neuen.

Fällt ein Worker Node aus, werden die betroffenen Workloads – sofern ausreichend Kapazität vorhanden ist – auf andere Nodes verteilt.

Skaliert eine Anwendung horizontal, verteilt Kubernetes eingehende Anfragen auf mehrere Instanzen.

Diese Mechanismen bilden die Grundlage hochverfügbarer Systeme.

Sie lösen jedoch ausschließlich Probleme innerhalb der definierten Betriebsumgebung.

Mit anderen Worten:

Kubernetes sorgt dafür, dass Workloads innerhalb eines Clusters möglichst zuverlässig betrieben werden.

Es beantwortet jedoch keine Fragen wie:

• Was passiert, wenn der gesamte Cluster ausfällt?
• Was geschieht bei einem Ausfall der Storage-Infrastruktur?
• Wie schnell kann eine produktive Umgebung vollständig wiederhergestellt werden?
• Welche Daten dürfen maximal verloren gehen?
• Wie wird überprüft, ob eine Wiederherstellung tatsächlich funktioniert?

Genau hier beginnt Disaster Recovery.

Ein Backup ersetzt keine Wiederherstellungsstrategie

Fragt man Unternehmen nach ihrem Backup-Konzept, lautet die Antwort häufig:

“Wir erstellen täglich Backups.”

Das klingt zunächst beruhigend.

Die eigentliche Frage lautet jedoch nicht, ob Backups existieren.

Sondern:

Wie schnell lässt sich daraus der vollständige Geschäftsbetrieb wiederherstellen?

Diese Unterscheidung mag klein erscheinen.

In Wirklichkeit entscheidet sie darüber, ob ein Unternehmen nach einem schwerwiegenden Vorfall innerhalb einer Stunde oder erst nach mehreren Tagen wieder arbeitsfähig ist.

Ein Backup besitzt erst dann einen praktischen Wert, wenn drei Bedingungen erfüllt sind.

Erstens muss es vollständig sein.

Zweitens muss es konsistent sein.

Drittens muss seine Wiederherstellung regelmäßig getestet werden.

Gerade der letzte Punkt wird erstaunlich häufig vernachlässigt.

Ein Backup, dessen Restore-Prozess nie überprüft wurde, ist letztlich nichts weiter als eine Annahme.

Was muss in Kubernetes überhaupt gesichert werden?

Bereits diese scheinbar einfache Frage zeigt, warum Kubernetes neue Anforderungen an Backup-Strategien stellt.

Viele Administratoren denken zunächst an die laufenden Container.

Diese sind jedoch in den meisten Fällen vollständig austauschbar.

Ein Pod lässt sich jederzeit neu erzeugen.

Gesichert werden müssen stattdessen ganz andere Informationen.

Zunächst der Zustand des Clusters selbst.

Deployments.

Services.

ConfigMaps.

Network Policies.

Ingress-Ressourcen.

Custom Resources.

Role Bindings.

Secrets.

All diese Informationen werden letztlich in etcd gespeichert.

Hinzu kommen persistente Daten.

Datenbanken.

Objektspeicher.

Dateisysteme.

Message Queues.

Suchindizes.

Schließlich existiert noch eine dritte Ebene.

Die Infrastruktur außerhalb des Clusters.

DNS-Konfigurationen.

Load Balancer.

Identity Provider.

Git-Repositories.

Container Registries.

CI/CD-Pipelines.

Cloud-Ressourcen.

Erst wenn alle drei Ebenen berücksichtigt werden, entsteht eine vollständige Wiederherstellungsstrategie.

RPO und RTO sind keine theoretischen Kennzahlen

Im Zusammenhang mit Disaster Recovery begegnet man regelmäßig zwei Abkürzungen.

Recovery Point Objective (RPO)

und

Recovery Time Objective (RTO).

Leider werden beide Begriffe häufig ausschließlich im Rahmen von Audits oder Compliance-Anforderungen diskutiert.

Tatsächlich beschreiben sie eine der wichtigsten unternehmerischen Entscheidungen überhaupt.

Das RPO beantwortet die Frage:

Wie viele Daten dürfen im schlimmsten Fall verloren gehen?

Beträgt das RPO vier Stunden, akzeptiert das Unternehmen einen maximalen Datenverlust von vier Stunden.

Liegt es bei fünf Minuten, muss die gesamte Plattform entsprechend anders entworfen werden.

Das RTO beschreibt dagegen,

wie lange die Wiederherstellung maximal dauern darf.

Muss eine Plattform innerhalb von fünf Minuten wieder verfügbar sein?

Innerhalb einer Stunde?

Oder genügt ein Arbeitstag?

Diese Werte bestimmen unmittelbar die Architektur.

Ein Unternehmen mit einem RTO von fünf Minuten benötigt völlig andere Prozesse als ein Unternehmen, das einen eintägigen Ausfall akzeptieren kann.

Technologie folgt hier unmittelbar den geschäftlichen Anforderungen.

Nicht umgekehrt.

Hochverfügbarkeit verhindert keine Katastrophen

Ein besonders hartnäckiger Irrtum besteht in der Annahme, Hochverfügbarkeit und Disaster Recovery seien unterschiedliche Bezeichnungen für dieselbe Disziplin.

Das Gegenteil ist der Fall.

Hochverfügbarkeit beschäftigt sich mit dem Ausfall einzelner Komponenten.

Disaster Recovery beschäftigt sich mit dem Ausfall ganzer Systeme.

Ein Beispiel verdeutlicht diesen Unterschied.

Fällt ein Worker Node aus, übernimmt Kubernetes automatisch dessen Workloads.

Der Benutzer bemerkt im Idealfall nichts.

Fällt dagegen die gesamte Region eines Cloud-Anbieters aus, existiert möglicherweise kein Cluster mehr, auf dem Kubernetes überhaupt reagieren könnte.

Auch ein versehentlich gelöschtes Kubernetes-Cluster lässt sich nicht durch einen ReplicaSet Controller wiederherstellen.

Ebenso wenig hilft horizontale Skalierung gegen einen erfolgreichen Ransomware-Angriff oder eine fehlerhafte Infrastrukturänderung, die sämtliche Produktionsressourcen gleichzeitig betrifft.

Disaster Recovery beginnt dort, wo Kubernetes keine Kontrolle mehr besitzt.

Resilienz entsteht durch Architektur

Interessanterweise beschäftigen sich besonders erfahrene Plattformteams deutlich weniger mit Backups als mit Resilienz.

Der Unterschied ist erheblich.

Backups versuchen, verlorene Daten wiederherzustellen.

Resilienz versucht, den Geschäftsbetrieb trotz Störungen aufrechtzuerhalten.

Diese Denkweise verändert die Architektur.

Datenbanken werden repliziert.

Load Balancer verteilen Anfragen über mehrere Availability Zones.

Kritische Dienste werden redundant betrieben.

DNS kann auf alternative Standorte umschalten.

Deployments erfolgen schrittweise.

Fehlerdomänen werden bewusst voneinander getrennt.

Chaos Engineering überprüft regelmäßig, wie sich Systeme unter realen Ausfallbedingungen verhalten.

Nicht jede Plattform benötigt all diese Maßnahmen.

Entscheidend ist vielmehr, dass jede Architektur bewusst auf definierte Ausfallszenarien ausgelegt wird.

Disaster Recovery scheitert selten an der Technik

Bemerkenswert ist, dass die größten Probleme im Ernstfall häufig nicht technischer Natur sind.

Viel häufiger fehlen klare Prozesse.

Wo befinden sich die aktuellen Sicherungen?

Wer darf eine Wiederherstellung anstoßen?

Welche Systeme müssen zuerst gestartet werden?

Welche Abhängigkeiten existieren zwischen den Anwendungen?

Wer informiert Kunden?

Wer dokumentiert den Vorfall?

Wer entscheidet, wann die Plattform wieder produktiv geschaltet werden darf?

In vielen Unternehmen existieren diese Informationen ausschließlich im Wissen einzelner Mitarbeiter.

Genau deshalb gehört Dokumentation ebenso zum Disaster Recovery wie technische Automatisierung.

Eine Plattform ist erst dann wirklich resilient, wenn ihre Wiederherstellung unabhängig von einzelnen Personen funktioniert.

Resilienz ist eine wirtschaftliche Entscheidung

An dieser Stelle lohnt sich ein Perspektivwechsel.

Häufig wird über Hochverfügbarkeit ausschließlich technisch diskutiert.

Dabei handelt es sich in erster Linie um eine betriebswirtschaftliche Fragestellung.

Jede zusätzliche Redundanz verursacht Kosten.

Jedes weitere Rechenzentrum erhöht den Betriebsaufwand.

Jede Replikation benötigt Bandbreite und Infrastruktur.

Umgekehrt verursacht jedoch auch jeder Ausfall Kosten.

Produktionsstillstand.

Vertragsstrafen.

Imageverlust.

Umsatzeinbußen.

Vertrauensverlust.

Die eigentliche Aufgabe einer Plattformarchitektur besteht deshalb nicht darin, jeden Ausfall unmöglich zu machen.

Sie besteht darin, ein wirtschaftlich sinnvolles Verhältnis zwischen Investitionskosten und Ausfallrisiko zu schaffen.

Kubernetes ist Teil der Lösung – nicht die gesamte Lösung

Nach sieben Kapiteln zeichnet sich ein wiederkehrendes Muster ab.

Kubernetes löst genau das Problem, für das es entwickelt wurde.

Es orchestriert Container zuverlässig.

Es stellt den gewünschten Infrastrukturzustand sicher.

Es automatisiert zahlreiche Betriebsaufgaben.

Doch weder Hochverfügbarkeit noch Disaster Recovery entstehen automatisch durch die Existenz eines Kubernetes-Clusters.

Sie entstehen durch Architekturentscheidungen, Betriebsprozesse und kontinuierliche Übung.

Genau deshalb gehört Disaster Recovery zu den Disziplinen, die in frühen Projektphasen häufig unterschätzt werden, im Ernstfall jedoch über die Handlungsfähigkeit eines Unternehmens entscheiden.

Managed Kubernetes ist nicht gleich Managed Platform: Wo die Verantwortung tatsächlich endet

Spätestens an diesem Punkt stellt sich für viele Unternehmen eine berechtigte Frage.

Wenn der Betrieb einer Kubernetes-Plattform tatsächlich so viele technische und organisatorische Disziplinen umfasst – warum entscheiden sich dann nicht einfach alle für einen Managed-Kubernetes-Dienst?

Schließlich bieten nahezu alle großen Cloud-Anbieter entsprechende Lösungen an.

Amazon Web Services stellt Elastic Kubernetes Service (EKS) bereit.

Microsoft bietet Azure Kubernetes Service (AKS).

Google betreibt die Google Kubernetes Engine (GKE).

Auch zahlreiche europäische Hosting-Anbieter werben mit vollständig verwaltetem Kubernetes.

Auf den ersten Blick scheint das Problem damit gelöst.

Der Cluster wird vom Anbieter betrieben.

Updates erfolgen automatisch.

Die Control Plane ist hochverfügbar.

Der Betriebsaufwand sollte sich damit auf ein Minimum reduzieren.

Genau diese Schlussfolgerung ist jedoch einer der häufigsten Irrtümer im Zusammenhang mit Kubernetes.

Was Managed Kubernetes tatsächlich bedeutet

Um diesen Irrtum zu verstehen, muss zunächst klar sein, welche Bestandteile ein Kubernetes-Cluster überhaupt besitzt.

Vereinfacht lässt sich Kubernetes in zwei Bereiche unterteilen.

Die Control Plane bildet die zentrale Steuerung des Clusters. Hier laufen unter anderem der API-Server, der Scheduler, die Controller und die etcd-Datenbank.

Daneben existieren die Worker Nodes. Auf ihnen werden die eigentlichen Anwendungen ausgeführt.

Bei einem Managed-Kubernetes-Angebot übernimmt der Anbieter in der Regel den Betrieb der Control Plane.

Er sorgt dafür, dass der API-Server erreichbar bleibt.

Er aktualisiert zentrale Kubernetes-Komponenten.

Er überwacht die Verfügbarkeit der Steuerungsebene.

Je nach Anbieter übernimmt er zusätzlich das automatische Ersetzen ausgefallener Master-Komponenten.

Das ist zweifellos ein erheblicher Vorteil.

Die Control Plane zählt zu den anspruchsvollsten Bestandteilen eines Kubernetes-Clusters und ihr zuverlässiger Betrieb erfordert tiefgehendes Wissen über verteilte Systeme.

Die entscheidende Frage lautet jedoch:

Wie groß ist der Anteil der Control Plane am gesamten Plattformbetrieb?

Die Antwort überrascht viele Unternehmen.

Er ist deutlich kleiner, als häufig angenommen wird.

Die eigentliche Verantwortung bleibt beim Betreiber

Denn selbst wenn der Anbieter die vollständige Control Plane übernimmt, verbleiben nahezu alle Aufgaben, die wir in den vorherigen Kapiteln betrachtet haben, weiterhin beim Kunden.

Die Anwendungen müssen entwickelt werden.

Container Images müssen gebaut, signiert und regelmäßig aktualisiert werden.

CI/CD-Pipelines müssen entworfen und betrieben werden.

Ingress Controller müssen konfiguriert werden.

TLS-Zertifikate müssen verwaltet werden.

Network Policies müssen entwickelt werden.

Storage-Konzepte müssen entworfen werden.

Backups müssen erstellt und getestet werden.

Monitoring muss eingerichtet werden.

Logs müssen ausgewertet werden.

Distributed Traces müssen instrumentiert werden.

Incident-Prozesse müssen definiert werden.

Runbooks müssen gepflegt werden.

Compliance-Anforderungen müssen erfüllt werden.

Disaster-Recovery-Szenarien müssen regelmäßig getestet werden.

Keine dieser Aufgaben verschwindet dadurch, dass der API-Server von einem Cloud-Anbieter betrieben wird.

Managed Kubernetes reduziert den Aufwand an einer sehr spezifischen Stelle.

Nicht am gesamten Plattformbetrieb.

Der Begriff “Managed” wird häufig missverstanden

Das Problem beginnt bereits beim Begriff selbst.

“Managed” suggeriert Verantwortung.

Tatsächlich beschreibt er häufig lediglich den Verantwortungsbereich des Anbieters.

Und dieser endet erstaunlich früh.

Ein Beispiel.

Ein Deployment führt dazu, dass eine neue Anwendungsversion keine Verbindungen mehr zur Datenbank herstellen kann.

Der Cluster funktioniert.

Die Nodes sind gesund.

Der API-Server antwortet.

Die Control Plane arbeitet fehlerfrei.

Aus Sicht des Managed-Kubernetes-Anbieters liegt keine Störung vor.

Für das Unternehmen steht dennoch die Produktion still.

Ein anderes Beispiel.

Ein Zertifikat läuft ab.

Der Ingress liefert ausschließlich TLS-Fehler.

Kubernetes selbst arbeitet weiterhin ordnungsgemäß.

Auch hier besteht aus Sicht des Infrastrukturanbieters kein Plattformproblem.

Oder nehmen wir einen erfolgreichen Angriff auf die Software-Lieferkette.

Ein kompromittiertes Container-Image wird über die CI/CD-Pipeline in Produktion ausgerollt.

Der Cluster verhält sich exakt so, wie er entworfen wurde.

Die eigentliche Sicherheitslücke liegt vollständig außerhalb seines Verantwortungsbereichs.

Diese Beispiele zeigen ein wiederkehrendes Muster.

Managed Kubernetes übernimmt Infrastruktur.

Nicht Betrieb.

Verantwortung lässt sich nicht virtualisieren

Diese Erkenntnis führt zu einem grundsätzlichen Missverständnis moderner Cloud-Architekturen.

Cloud-Dienste reduzieren den operativen Aufwand.

Sie beseitigen ihn jedoch nicht.

Vielmehr verschiebt sich die Verantwortung.

Früher musste ein Unternehmen physische Server betreiben.

Heute übernimmt diese Aufgabe der Cloud-Anbieter.

Dafür entstehen neue Verantwortlichkeiten.

Cloud-Architekturen.

Identity Management.

Kostenkontrolle.

Netzwerksicherheit.

Automatisierung.

Governance.

Kubernetes folgt exakt derselben Logik.

Die Verantwortung verschwindet nicht.

Sie verlagert sich.

Und genau deshalb genügt es nicht, lediglich den technischen Funktionsumfang verschiedener Angebote zu vergleichen.

Entscheidend ist vielmehr die Frage:

Welche Verantwortung möchte das Unternehmen langfristig selbst übernehmen?

Plattformbetrieb ist eine eigene Ingenieurdisziplin

An dieser Stelle wird deutlich, warum sich in den vergangenen Jahren ein völlig neues Berufsbild etabliert hat.

Platform Engineering.

Noch vor wenigen Jahren existierten in vielen Unternehmen klassische Systemadministratoren, Netzwerkadministratoren und Datenbankadministratoren.

Heute entstehen zunehmend dedizierte Plattformteams.

Ihre Aufgabe besteht nicht darin, einzelne Server zu administrieren.

Sie entwickeln und betreiben eine interne Plattform, auf der Entwicklungsteams Anwendungen effizient, sicher und reproduzierbar bereitstellen können.

GitOps.

Golden Paths.

Self-Service-Portale.

Standardisierte Deployment-Prozesse.

Automatisierte Policy-Prüfungen.

Observability.

Security Baselines.

All diese Themen gehören mittlerweile zum Verantwortungsbereich moderner Plattformteams.

Der Grund dafür ist einfach.

Die Komplexität moderner Softwarelandschaften ist so stark gestiegen, dass Plattformbetrieb selbst zu einer eigenständigen Ingenieurdisziplin geworden ist.

Die eigentliche wirtschaftliche Frage lautet nicht “Build or Buy”

An dieser Stelle wird die Diskussion häufig auf eine scheinbar einfache Entscheidung reduziert.

Selbst betreiben oder einkaufen.

In Wirklichkeit lautet die Frage anders.

Worin besteht der eigentliche Wettbewerbsvorteil Ihres Unternehmens?

Ein Softwareunternehmen entwickelt Produkte.

Ein Maschinenbauer entwickelt Maschinen.

Ein Krankenhaus behandelt Patienten.

Ein Versicherer kalkuliert Risiken.

Nur die wenigsten Unternehmen erzielen ihren Marktvorteil dadurch, dass sie besonders effizient Kubernetes-Cluster betreiben.

Natürlich gibt es Ausnahmen.

Große Softwareunternehmen mit mehreren hundert Entwicklern profitieren häufig von einer eigenen Plattformorganisation.

Sie verfügen über die notwendige Größe, um den Aufbau interner Plattformkompetenz wirtschaftlich zu rechtfertigen.

Für viele mittelständische Unternehmen sieht die Situation jedoch grundlegend anders aus.

Hier bindet der Aufbau eines eigenen Plattformteams hochqualifizierte Ingenieure, deren eigentliche Kompetenz häufig an ganz anderer Stelle benötigt würde.

Die wirtschaftliche Entscheidung lautet deshalb nicht:

Können wir Kubernetes selbst betreiben?

Fast jedes Unternehmen kann das.

Die entscheidende Frage lautet:

Sollten wir unsere besten Ingenieure langfristig mit dem Betrieb einer Plattform beschäftigen – oder mit der Entwicklung der Produkte, die unser Unternehmen tatsächlich von seinen Wettbewerbern unterscheiden?

Genau an dieser Stelle endet die rein technische Betrachtung.

Denn die Entscheidung über den Plattformbetrieb ist letztlich keine Technologieentscheidung.

Sie ist eine strategische Unternehmensentscheidung. Kapitel 9 – Fazit: Kubernetes ist nicht das Problem. Falsche Erwartungen sind es.

Zu Beginn dieses Artikels stand eine scheinbar einfache Frage:

Warum unterschätzen Unternehmen den Aufwand für Kubernetes so häufig?

Nach acht Kapiteln dürfte die Antwort deutlich differenzierter ausfallen als noch zu Beginn.

Nicht Kubernetes wird unterschätzt.

Unterschätzt wird der professionelle Betrieb moderner Softwareplattformen.

Dieser Unterschied ist entscheidend.

Denn Kubernetes erfüllt seine Aufgabe außerordentlich gut. Es orchestriert Container, gleicht den tatsächlichen Zustand eines Systems kontinuierlich mit dem gewünschten Zustand ab und automatisiert zahlreiche Prozesse, die vor wenigen Jahren noch manuell durchgeführt werden mussten.

Genau deshalb hat sich Kubernetes innerhalb weniger Jahre zum De-facto-Standard für den Betrieb cloud-nativer Anwendungen entwickelt.

Das eigentliche Missverständnis entsteht erst dann, wenn Unternehmen glauben, mit der Einführung von Kubernetes sei der Aufbau einer produktionsreifen Plattform bereits abgeschlossen.

In Wirklichkeit beginnt die anspruchsvollste Phase genau an diesem Punkt.

Eine produktive Plattform besteht nicht nur aus einem Cluster.

Sie besteht aus Observability, Sicherheitskonzepten, Backup- und Recovery-Strategien, Netzwerkarchitekturen, Automatisierung, Governance, Compliance, Incident Management, GitOps, Release-Prozessen und einer Vielzahl organisatorischer Entscheidungen, die über Jahre hinweg gepflegt, dokumentiert und kontinuierlich weiterentwickelt werden müssen.

Die Einführung von Kubernetes reduziert diese Aufgaben nicht.

Sie verändert lediglich die Art und Weise, wie sie gelöst werden.

Gerade darin liegt die Stärke der Plattform.

Kubernetes versucht nicht, jedes Problem selbst zu lösen. Stattdessen stellt es ein außergewöhnlich flexibles Fundament bereit, auf dem sich nahezu jede Anforderung abbilden lässt.

Diese Offenheit hat jedoch ihren Preis.

Sie verschiebt Verantwortung vom Hersteller auf den Betreiber.

Jede Entscheidung für eine bestimmte CNI, einen Storage-Treiber, eine GitOps-Lösung oder eine Observability-Plattform ist gleichzeitig eine Entscheidung für deren langfristigen Betrieb.

Je größer eine Plattform wird, desto stärker verschiebt sich deshalb der Fokus.

Nicht die Bereitstellung eines Clusters entscheidet über den Erfolg eines Projekts.

Sondern die Qualität des Plattformbetriebs.

Vielleicht ist genau das die wichtigste Erkenntnis dieses Artikels.

In den vergangenen Jahren wurde Kubernetes häufig als technologische Innovation diskutiert.

Heute ist Kubernetes Infrastruktur.

Und Infrastruktur besitzt eine bemerkenswerte Eigenschaft.

Sie erzeugt für sich genommen keinen Wettbewerbsvorteil.

Kein Kunde entscheidet sich für ein Softwareprodukt, weil dessen Hersteller besonders elegante Network Policies entwickelt hat.

Kein Anwender bleibt einer Plattform treu, weil ihre Pods sauber über mehrere Worker Nodes verteilt werden.

Kunden erwarten etwas anderes.

Sie erwarten, dass Anwendungen zuverlässig verfügbar sind.

Dass Updates keine Ausfälle verursachen.

Dass Sicherheitslücken schnell geschlossen werden.

Dass Daten geschützt sind.

Dass sich Fehler nachvollziehen und beheben lassen.

Kurz gesagt:

Sie erwarten einen professionellen Betrieb.

Genau deshalb sollte jedes Unternehmen eine ehrliche Frage beantworten.

Nicht:

“Können wir Kubernetes selbst betreiben?”

Sondern:

“Ist der Betrieb einer Kubernetes-Plattform wirklich die Aufgabe, mit der wir unsere wertvollsten Ingenieurinnen und Ingenieure langfristig beschäftigen möchten?”

Für manche Unternehmen lautet die Antwort eindeutig Ja.

Große Softwarehersteller mit eigenen Plattformorganisationen, mehreren hundert Entwicklern und spezifischen Anforderungen profitieren häufig davon, ihre Plattform vollständig selbst zu entwickeln und zu betreiben.

Für viele andere Unternehmen lautet die Antwort jedoch Nein.

Nicht weil ihnen das technische Know-how fehlt.

Sondern weil ihre eigentliche Wertschöpfung an anderer Stelle entsteht.

Ein SaaS-Unternehmen entwickelt Software.

Ein Maschinenbauer entwickelt Maschinen.

Ein Energieversorger versorgt Kunden mit Energie.

Der Betrieb einer Kubernetes-Plattform ist für diese Unternehmen notwendige Infrastruktur – aber selten ihr Geschäftsmodell.

Und genau deshalb entscheiden sich immer mehr Organisationen dafür, den Plattformbetrieb in die Hände von Spezialisten zu legen.

Nicht, um Verantwortung abzugeben.

Sondern um Verantwortung bewusst zu verteilen.

Warum wir bei ayedo genau hier ansetzen

Bei ayedo betreiben wir nicht einfach Kubernetes-Cluster.

Wir übernehmen die Verantwortung für den professionellen Betrieb cloud-nativer Plattformen.

Dazu gehören nicht nur die Infrastruktur und die Kubernetes-Control-Plane, sondern ebenso Themen wie GitOps, Observability, Monitoring, Security, Backup-Strategien, Updates, Incident Management und der kontinuierliche Betrieb Ihrer Anwendungen.

Unser Ziel ist dabei nicht, Ihnen möglichst viel Infrastruktur zu verkaufen.

Unser Ziel ist, dass sich Ihre Entwickler wieder auf das konzentrieren können, was Ihr Unternehmen tatsächlich voranbringt: die Entwicklung guter Software.

Den Betrieb der Plattform übernehmen wir.

Wenn Sie aktuell vor der Entscheidung stehen, Kubernetes selbst einzuführen, eine bestehende Plattform weiterzuentwickeln oder den Betrieb langfristig wirtschaftlicher aufzustellen, sprechen Sie mit uns.

Lassen Sie sich unverbindlich beraten. Gemeinsam analysieren wir Ihre bestehende Plattform, bewerten den tatsächlichen Betriebsaufwand und zeigen Ihnen auf, welche Architektur für Ihre Anforderungen technisch und wirtschaftlich sinnvoll ist.

Denn am Ende geht es nicht darum, möglichst viele Kubernetes-Cluster zu betreiben.

Es geht darum, Software zuverlässig, sicher und nachhaltig auszuliefern.