Zdenk Kluka - stock.adobe.com
Die Zukunft von Kubernetes liegt in der Hybrid Cloud
Kubernetes ist nach wie vor mit seinen Wurzeln in der Public Cloud verhaftet. Will es weiter wachsen, muss es hybride Strukturen besser bewältigen und die Komplexität reduzieren.
In den letzten fünf Jahren hat sich Kubernetes von einer obskuren Technologie zu einem automatisierten Containerbereitstellungs-Tool und schließlich zu einem Ökosystem entwickelt, das die Migration in die Cloud unterstützt. Kubernetes hat also einen weiten Weg hinter sich, aber ein Ende der Reise ist noch lange nicht in Sicht.
Das Erfolgsgeheimnis von Kubernetes liegt in seinem überlegenen Modell für die Containerbereitstellung. Durch seine Anschlussfähigkeit wuchs es alsbald zu einem Ökosystem heran, das zu einem führenden Middleware-Paket für Cloud-native Anwendungen geworden ist. Diese Transformation hat jedoch zu einer Komplexität geführt, die nun der weiteren Ausbreitung von Kubernetes im Wege steht. Dies stellt die nächste große Herausforderung bei der Weiterentwicklung der Technologie dar.
Bisher war die Public Cloud der primäre Inkubator für Kubernetes. Dementsprechend sind der Entwicklung von Anwendungen Grenzen gesetzt. Wenn Kubernetes seine derzeitigen Einschränkungen überwindet, wird sich das jedoch radikal ändern.
Kubernetes bedient eine Marktlücke
Kubernetes war ursprünglich ein Google-Projekt, das zur Verwaltung eines Such- und Service-Ökosystems entwickelt wurde, das nicht viel mit dem Betrieb von Geschäftsanwendungen in gewöhnlichen Unternehmen zu tun hatte. Kubernetes – oder Borg, wie der interne Vorgänger bei Google genannt wurde – musste flexibel sein und zahlreiche Funktionen und Anpassungsmöglichkeiten abhaken.
Bis heute konzentriert sich die Open-Source-Version von Kubernetes darauf, die genannte Marktlücke zu schließen – der Support von Anwendungen in der Public Cloud sowie von Cloud-nativen und Microservice-zentrierten Workloads. Das Ökosystem um Kubernetes herum baut darauf auf und fügt Funktionen wie Service-Mesh-Technologie und Multi-Cloud-Fähigkeiten hinzu.
Es gibt noch viel zu tun
Die beiden größten Hindernisse für die weitere Verbreitung von Kubernetes am Markt sind die Komplexität und die Kenntnisse, die von Seiten der Mitarbeiter für die Installation und Nutzung erforderlich sind. Wer schon seit längerer Zeit mit Kubernetes arbeitet, wird bestätigen können, dass die Technologie immer komplizierter geworden ist.
Das gilt besonders für das entsprechende Ökosystem – die Verschmelzung von Middleware-Tools, die für die vollständige Verwaltung der Lebenszyklen von Cloud-nativen Anwendungen erforderlich sind.
Das andere Problem ist das Ökosystem selbst. Die meisten Unternehmen sehen es als den Weg zu Cloud-nativen Anwendungen an – aber nicht alle sind sich sicher, dass sie diesen Weg auch bis zum Ende beschreiten wollen. Fast alle befürchten zudem, dass ein Großteil oder zumindest viele ihrer aktuellen Anwendungen dabei auf der Strecke bleiben werden.
Die Benutzer wünschen sich eine Version von Kubernetes, die nicht nur für ihre Cloud-nativen Bereitstellungen bedient, sondern auch in ihrem Rechenzentrum sowie in Hybrid- und Multi-Cloud-Umgebungen seinen Dienst tut. Die Vorstellung, dass in der Zukunft alle Business-Anwendungen in der Public Cloud laufen werden ist schlicht unrealistisch und Kubernetes muss deshalb hybride Systeme in Zukunft abbilden können.
Kubernetes ist so erfolgreich, weil es das Kernstück eines Anwendungsmodells ist, aber kein solches Modell kann überleben, wenn es für den durchschnittlichen Entwickler oder Administratoren zu komplex ist. Es muss außerdem die zentralen Geschäftsanwendungen unterstützen, auf deren Fundament die gesamte Betriebs-IT ruht. Mit diesen beiden Aspekten muss sich die Kubernetes-Community befassen, um weitere Marktanteile zu erobern.
Der Schlüssel zur Lösung beider Probleme ist die Erweiterung des Ökosystems von Kubernetes selbst. Es muss ein Container-Ökosystem werden, nicht nur ein Cloud-natives Ökosystem. In seiner Anfangszeit wurde Kubernetes als Ergänzung zu Docker gehandelt, die das Arbeiten mit Microservice-zentrierten Anwendungen erleichterte.
In Zukunft muss es eine breitere Palette von Bedürfnissen abdecken, so muss es zum Beispiel mit monolithischen Anwendungen umgehen oder die Kluft zwischen Public Clouds und privaten Rechenzentren überbrücken können.
Die nächste Herausforderung: Public Cloud vs. On Premises
Kubernetes ist auch heute noch weitgehend auf den Einsatz in der Public Cloud konzentriert. Cloud-Anbieter wollen Kunden an ihre Kubernetes-Dienste binden. Ihr Ziel ist es, ein Paket anzubieten, das die Anwendungsbereitstellung und -Umsetzung in der Cloud vereinfacht, und dabei möglichst die Kunden an ihre Plattformen bindet. Der Wettlauf um die Position als Marktführer für Kubernetes in der Cloud hat dazu geführt, dass das Thema Rechenzentrum auf der Strecke geblieben ist. Das Komplexitätsproblem ist in all dem Getöse um Managed Services untergegangen.
Die etablierten Anbieter von Software für Rechenzentren betrachten dies offensichtlich als Bedrohung für ihr eigenes Geschäft. Sie erkennen nun, dass sie den Kubernetes- und Cloud-Zug aufspringen können, indem sie auf ihre Weise die Komplexität und die Probleme mit der Hybrid Cloud angehen. Zu den wichtigsten Anbietern, die erkannt haben, dass Multi-Cloud ihr Weg zur Marktführung in Sachen Kubernetes ist, gehören VMWare und IBM mit Red Hat.
VMware hat einen Vertrag mit Amazon abgeschlossen, um vSphere in der Cloud zu hosten und mit der Kubernetes-Version von Amazon zu verwalten. VMware bietet zudem eigene Kubernetes-Services an. Auch Microsoft und Google bieten als Cloud-Provider Kubernetes an. Red Hat und IBM waren schon immer stark im Rechenzentrum vertreten. IBM arbeitet nach der Übernahme von Red Hat nun hart daran, seinen eigenen Container-Ansatz – Kabanero – mit OpenShift zu harmonisieren. Letzteres basiert auf Kubernetes und kann sowohl On-Premises als auch in der Public Cloud betrieben werden.
Dieses Kubernetes-Modell stellt das Rechenzentrum in den Mittelpunkt. Es schafft eine Abstraktionsschicht, welche die Public Cloud oder lokale Umgebung überlagert. Private Cloud und Public Cloud werden nicht mehr länger unterschieden.
Stattdessen erscheinen diese gleichermaßen als Orte, an denen Container gehostet werden. Die Maxime, dass sich alles nur noch um die zu hostende Anwendung drehen soll, statt um das Hosting an sich, wird Kubernetes transformieren.
Wie eine echte Hybrid Cloud Realität wird
Die meisten hybriden Cloud-Architekturen trennen heute Anwendungen in ein Frontend in der Public Cloud und einen Kern, der im Rechenzentrum läuft. Kubernetes und sein Ökosystem hingegen könnten das ändern. Wenn zum Beispiel eine containerbasierte Anwendung die Grenze zwischen Public Cloud und Rechenzentrum überwindet, kann das IT-Team über diese beiden Systeme hinweg einen gemeinsamen Topf von Hosting-Ressourcen verwenden, die einander ergänzen und absichern.
Abstraktion ist das Konzept, das in Zukunft dabei helfen wird, verteilte Kubernetes-Cluster in verschiedenen Umgebungen gemeinsam zu verwalten. Sie vereinheitlicht und vereinfacht den Betrieb und erzeugt eine gemeinsame Schnittstelle, unter der die technische Komplexität von Kubernetes verborgen bleibt. Auf diesem Weg können beide Probleme von Kubernetes bewältigt werden.
Microsoft verfügt bereits über die Azure Service Fabric, eine Art universeller Servicebus, und hat sich auch dafür eingesetzt, diesen in andere Service-Mesh-Technologien einzubinden. Eine Service-Mesh-Verbindung ins Rechenzentrum würde die Anforderungen an die Integration hybrider Cloud-Anwendungen selbst dann erfüllen, wenn das Rechenzentrum nicht vollständig auf Microservices umgestellt wird.
Kubernetes-Ökosysteme, die von Rechenzentrumssoftware-Anbietern aufgebaut wurden, zwingen die Public-Cloud-Anbieter bereits zur Anpassung. Das zeigt sich schon bei Google Anthos, das von genau dem Unternehmen stammt, das Kubernetes geschaffen hat. Die Zukunft der Container liegt in einem breiter angelegten, einfacheren Kubernetes-Ökosystem.
