Plattform-Engineering scheint sich ganz um Kubernetes zu drehen. Die Tool-Landschaften im Plattform-Engineering sind überflutet mit Tools, die sich auf Kubernetes konzentrieren, und die meisten Referenzarchitekturen gehen davon aus, dass Interne Entwicklungsplattformen ausschließlich auf das Deployment containerisierter Microservices in Kubernetes-Clustern ausgerichtet sind.
Kubernetes ist zweifellos ein zentrales Element vieler Plattform-Engineering-Initiativen. Laut der Umfrage der Cloud Native Computing Foundation aus dem Jahr 2023 setzen bereits 66 % der Unternehmen Kubernetes in der Production ein, weitere 18 % evaluieren es derzeit.
Aber: Organisationen, die Kubernetes nutzen, haben auch Infrastruktur außerhalb von Kubernetes. Viele haben sogar den Großteil ihrer Infrastruktur anderswo. Manche nutzen Kubernetes überhaupt nicht.
Das bedeutet: Es besteht ein Bedarf, Infrastruktur auch außerhalb von Kubernetes zu verwalten. Es bedeutet, hybride Infrastrukturen zu managen, die sich über Kubernetes, Linux-VMs, Windows-Server, serverlose Infrastrukturen, Bare-Metal-Server und andere “Besonderheiten” erstrecken.
In diesem Beitrag möchte ich über die Herausforderungen beim Management hybrider Infrastrukturen sprechen, wie diese gelöst werden können und welche Vorteile es hat, Plattform-Engineering auf die gesamte Infrastruktur auszurichten – und nicht nur auf Container in Kubernetes.
Warum es immer Infrastruktur außerhalb von Kubernetes geben wird
Es gibt bestimmte Arten von Workloads, die einfach nie auf Kubernetes migriert werden. Warum?
- Legacy-Architekturen – Ältere Anwendungen sind nicht für die Containerisierung konzipiert und müssten umfassend überarbeitet werden, um in einer Kubernetes-Umgebung zu funktionieren. Oft sind die Kosten für eine Migration solcher Legacy-Anwendungen in eine Kubernetes-Umgebung zu hoch, sodass sie auf absehbare Zeit nicht-containerisiert bleiben werden.
- Zustandsbehaftete Anwendungen – Zustandsbehaftete Anwendungen (wie Datenbanken) benötigen oft komplexe Konfigurationen für persistente Speicherlösungen, was ihre Verwaltung in Kubernetes erschwert.
- Performance-Anforderungen – Kubernetes bringt einen gewissen Overhead mit sich, der sich negativ auf leistungskritische Anwendungen auswirken kann, die direkten Hardwarezugriff oder eine sehr geringe Latenz benötigen.
- Komplexität – Für kleine, einfache Anwendungen kann Kubernetes überdimensioniert sein, was zu unnötiger betrieblicher Komplexität ohne nennenswerte Vorteile führt.
- Ressourcenbedarf – Der Betrieb von Kubernetes selbst erfordert Ressourcen (Control Plane, Worker Nodes), die in ressourcenbeschränkten Umgebungen nicht verfügbar oder zu teuer sein können.
- Kompatibilitätsprobleme – Manche Software hat spezielle Betriebssystemabhängigkeiten, erfordert maßgeschneiderte Konfigurationen oder nutzt Legacy-Tools, die sich nur schwer containerisieren und mit Kubernetes orchestrieren lassen.
- Regulatorische oder sicherheitsbezogene Einschränkungen – In manchen Branchen gibt es strenge Anforderungen, die die Containerisierung erschweren oder den Aufwand im Vergleich zum Nutzen nicht rechtfertigen – insbesondere im Umgang mit sensiblen Daten.
Egal, ob nur einer dieser Punkte auf deine Umgebung zutrifft: Infrastruktur außerhalb von Kubernetes wird es immer geben.
Pain Points beim Verwalten der Infrastruktur innerhalb und außerhalb von Kubernetes
Die Verwaltung der Infrastruktur sowohl innerhalb als auch außerhalb von Kubernetes bringt einige Herausforderungen mit sich:
- Fragmentierte Sichtbarkeit: Da Kubernetes Container verwaltet und andere Tools für Legacy-Systeme oder virtuelle Maschinen (VMs) zuständig sind, fällt es Ingenieur:innen schwer, einen einheitlichen Überblick über ihre Infrastruktur zu bekommen.
- Inkonsistente Developer Experience: Entwickler:innen haben oft keine gute Erfahrung beim Zugriff auf Kubernetes- und Nicht-Kubernetes-Dienste. Abhängig vom jeweiligen Dienst sind unterschiedliche Tools, Prozesse und Benutzeroberflächen erforderlich.
- Komplexes Networking: Die Netzwerkanbindung zwischen Kubernetes-Clustern und Nicht-Kubernetes-Umgebungen (z. B. On-Premise-Systeme oder Cloud-VMs) ist häufig kompliziert und erfordert manuelle Eingriffe oder individuelle Lösungen.
- Infrastruktursilos: Unterschiedliche Teams nutzen verschiedene Management-Tools für Kubernetes und andere Ressourcen, was zu spezialisiertem Wissen in Silos und getrennten Toolchains führt. Das verlangsamt die Fehlersuche, Upgrades und das allgemeine Infrastrukturmanagement.
- Sicherheits- und Compliance-Risiken: Eine konsistente Umsetzung von Sicherheitsrichtlinien und regulatorischen Anforderungen über Kubernetes-verwaltete und traditionelle Umgebungen hinweg ist eine große Herausforderung – insbesondere in stark regulierten Branchen.
Diese Probleme kennt jede:r, der oder die mit Infrastruktur über verschiedene Technologien hinweg arbeitet. In vielen Organisationen führt das zu einer erheblichen Doppelarbeit, weil operative Ressourcen mehrfach, getrennt für unterschiedliche Infrastrukturen umgesetzt werden. Das ist nicht nur teuer, sondern schafft auch Anreize, alles getrennt zu halten: In den Aufbau separater Fähigkeiten für unterschiedliche Technologie-Stacks wurde bereits viel investiert. Wenn du dich in dieser Situation befindest, fallen dir vermutlich sofort ein oder mehrere wichtige Projekte oder Initiativen in deinem Unternehmen ein, die genau wegen dieser geteilten Infrastruktur ernsthaft blockiert sind.
Organisationen, die Plattform Engineering ernst nehmen (Mehr zum Thema: Warum Platform Engineering?) und Softwareentwickler:innen (sowie anderen Stakeholdern) Self-Service anbieten möchten, müssen über diese Silos hinausdenken.
Mehr über Platform Engineering Herausforderungen hier lesen.
Die gute Nachricht? Es ist möglich, nicht nur das Management von Infrastruktur und Anwendungen technologieübergreifend zu vereinheitlichen, sondern dies auch schrittweise und mit begrenzten Ressourcen umzusetzen.
Wie man Infrastruktursilos zusammenführt
Im Zentrum steht eine unbequeme Wahrheit: Je früher man sich dazu entscheidet, den Fokus auf technologieübergreifende Funktionen zu legen, desto günstiger und einfacher wird es. Es ist unangenehm, das auszusprechen, denn in den meisten Organisationen wurden schon vor langer Zeit viele Entscheidungen getroffen, die es heute schwierig machen, den Kurs zu ändern.
Aber die Wahrheit bleibt bestehen: Je früher man diese Entscheidung trifft, desto leichter wird der Weg. Mit jedem weiteren Tag wird mehr in Silos und spezialisierte Tools investiert, die später schwer zu harmonisieren und integrieren sind – und je mehr bereits investiert wurde, desto größer wird auch der Widerstand. Deshalb: Heute ist ein genauso guter Tag wie jeder andere, um die Plattform-Engineering-Bemühungen auf die gesamte Infrastruktur zu richten – besser heute als morgen.
Um loszulegen, braucht es einen konkreten Pain Point, ein Problem oder ein Bedürfnis, das mit dem aktuellen Setup nicht erfüllt werden kann. Sobald das identifiziert ist, sind die nächsten Schritte theoretisch einfach – in der Praxis jedoch herausfordernd:
- Um dieses Problem zu lösen, wähle Tools, die technologieagnostisch sind. Wahrscheinlich hast du solche bereits im Einsatz. Terraform zum Beispiel ist egal, wo es Infrastruktur deployed. Und natürlich ist Cloudomation eine gute Wahl für eine technologieagnostische Abstraktions- und Integrationsschicht 😉.
- Löse das Problem, das du dir vorgenommen hast. Nutze dann dieses Beispiel, um zu zeigen, dass technologieübergreifende Orchestrierung möglich ist. Wenn du dich für Cloudomation entscheidest, unterstützen wir dich auf jedem Schritt – von der Analyse deiner Situation über die Umsetzung und den Betrieb bis hin zur Argumentation, mit der du den geschaffenen Mehrwert sichtbar machen kannst.
- Finde anschließend den nächsten großen Pain Point. Und dann: wiederholen.
Es wird nicht leicht sein. Aber es lohnt sich.
Vorteile einer integrierten hybriden Infrastruktur
Was hast du davon?
Kurzfristig vor allem: Probleme 😅.
Aber langfristig bringt dir die Fähigkeit, Infrastruktur über Kubernetes hinaus und über verschiedene Technologien hinweg zu verwalten, erhebliche Vorteile:
- Bessere Sichtbarkeit & Kontrolle: Die Möglichkeit, Infrastruktur und Anwendungen technologieübergreifend zu sehen und zu steuern, vereinfacht den Betrieb enorm. Zentralisiertes Monitoring, Logging und Richtlinienmanagement helfen Ops-Teams, alles effektiver zu verwalten. Das erleichtert die Fehlererkennung, die Einhaltung von Compliance-Vorgaben und das Kostenmanagement.
- Bessere Ressourcennutzung: Einer der größten Kostentreiber in isolierter Infrastruktur ist die doppelte Umsetzung von Diensten und Funktionen für verschiedene Technologie-Stacks. Eine einheitliche Schicht für Sichtbarkeit und Steuerung erlaubt es Organisationen, bestehende Investitionen in Nicht-Kubernetes-Infrastruktur (z. B. Windows-Server, Legacy-Apps, Datenbanken) weiter zu nutzen – ohne dabei Arbeitsaufwände zu duplizieren.
- Reibungslosere Migrationen & Übergänge: Unterstützt eine schrittweise Modernisierung, indem Legacy- und Cloud-native-Systeme koexistieren können. Erlaubt hybride Strategien, bei denen Workloads nach und nach nach Kubernetes migriert werden – ohne Unterbrechungen.
- Einheitliche Developer Experience: Entwickler:innen bekommen einen konsistenten Zugang zu Diensten – egal ob diese auf Kubernetes, VMs oder anderen Systemen laufen. Das reduziert kognitive Komplexität und spart viel Zeit.
Zum Glück werden viele dieser Vorteile schnell greifbar. Es ist nicht nötig, gleich eine vollständige Abstraktionsschicht über alles hinweg zu haben, um den Nutzen zu sehen. Selbst wenn z. B. nur einige Windows-Server und bestimmte Kubernetes-Dienste über eine gemeinsame Oberfläche verwaltet werden können, verringert das bereits die Komplexität für Operations – und zeigt den Stakeholdern ganz konkret, warum dieser Ansatz sinnvoll und wertvoll ist. Von dort aus lässt sich die Integration weiterer Infrastruktur-Komponenten Schritt für Schritt fortsetzen.
Wie anfangen? Ein bisschen Eigenwerbung
Um eine einheitliche Abstraktionsschicht über verschiedene Technologien hinweg erfolgreich umzusetzen, sind Kommunikation, Change Management und organisatorisches Rückgrat entscheidend. Aber auch die Technologie spielt eine wichtige Rolle.
Mit Cloudomation bekommst du eine erprobte, leistungsstarke Plattform, um Infrastruktur und Anwendungen technologieübergreifend zu integrieren und zu managen – und ein Expertenteam, das dich auf jedem Schritt begleitet.
Von Anfang an war unser Fokus bei Cloudomation, Infrastrukturmanagement außerhalb von und ergänzend zu Kubernetes zu ermöglichen. Wenn du damit kämpfst, Infrastruktur ohne oder zusätzlich zu Kubernetes zu verwalten, sollten wir miteinander sprechen.
Wir versprechen nicht, dass dein Job einfach wird – Plattform Engineering ist nicht einfach, und das wird sich auch nicht ändern. Aber wir versprechen, dass dein Job machbar wird:
Wir geben dir die Werkzeuge an die Hand, mit denen du eine robuste Abstraktionsschicht über jede beliebige Infrastruktur hinweg aufbauen kannst.
