…aber eine hervorragende Meta-Plattform für Platform as a Service-Lösungen
PaaS-Lösungen sind vor allem in Betracht von Time-To-Market Kubernetes überlegen
Die Komplexität von Kubernetes ist für kleinere Firmen und Start-Ups zu hoch und rentiert sich erst nach langer Zeit
Container-Lösungen und Kubernetes werden mittlerweile bei den meisten PaaS-Lösungen als Basis verwendet und bilden eine mächtige Betriebsplattform
Mit Knative ergeben sich neue Marktchancen für Cloud Provider, IT-Dienstleister und Tool-Entwickler
Als im Jahr 2014 das Kubernetes Projekt veröffentlicht wurde, konnte niemand erahnen welche Marktakzeptanz und -präsenz das Container-Orchestrierungs-Tool erreichen könnte. Kubernetes hat den Markt aufgerollt, nach gut 5 Jahren seine Mitstreiter (Docker Swarm, Mesosphere, etc.) überholt und Einzug in die Rechenzentren vieler Unternehmen und Konzerne gehalten.
Wenn man die Umfragen der Cloud Native Computing Foundation betrachtet, zeigen diese die gleichen Herausforderungen auf: Kubernetes ist komplex, egal ob gemanaged oder on-premise. Während es bei Themen wie Netzwerk, Speicher und Security eine Verbesserung gibt, verharrt die Komplexität, bis auf eine Ausnahme, auf dem gleichen Niveau.
What are your challenges in using / deploying containers – Quelle: https://bit.ly/2PWPusx
Die Marktpräsenz lässt vermuten, dass Kubernetes nun die einzige relevante Option ist, um container-basierte Anwendungen zu betreiben. Doch, wie öfter im Leben, ist auch hier die Antwort auf diese Frage nicht immer Kubernetes.
PaaS als Fastlane
Noch bevor Kubernetes das Licht der Welt erblickte, florierte der Markt an Betriebsumgebungen für Web-Anwendungen. Große Namen in dieser Zeit waren Heroku, Googles App Engine und neben vielen anderen sicherlich auch Amazons Elastic Beanstalk. Diese Plattformen sind nach wie vor aktiv und stellen eine Alternative zu Kubernetes dar. Diese Alternative ist vor allem für kleinere Firmen und Start-Ups interessant, die aus Ressourcengründen noch nicht in der Lage sind, eigene Kubernetes-Umgebungen zu betreiben.
Aber das ist nicht der einzige Grund, auf ein “Platform as a Service” (PaaS) zu setzen. Viele PaaS-Anbieter bieten eine Source-to-Application Integration an, bei dem der Build der Anwendung durch den Plattformanbieter durchgeführt wird und das Artefakt im Anschluss direkt auf der Plattform bereitgestellt wird. Dieses Vorgehen gibt einen erheblichen Zeitvorteil und ist vor allem für Unternehmen interessant, die Features und Fixes möglichst schnell an den Endkunden bringen wollen. Dank Buildpacks, die sowohl von Heroku, als auch von Cloud Foundry unterstützt werden, kann der Build an die Gegebenheiten der Anwendung angepasst werden.
PaaS als sicherer Hafen
Das Angebot der PaaS-Anbieter umfasst auch Datenbanken und Message Broker. Die Verwaltung dieser Tools ist eine der kostspieligsten Aufgaben beim Betrieb einer Anwendung. Die Implementierung von Backup- und Recovery-Szenarien für solche Infrastruktur-Komponenten ist komplex, schwer zu testen und mit hohen Kosten für zusätzlichen Speicherplatz verbunden.
Diese Teile aus einer managed Umgebung zu beziehen ist nicht nur beim Betrieb einer Anwendung auf einer PaaS sinnvoll, sondern auch in dem Fall, bei dem der Kubernetes-Cluster von einem Cloud Provider gemanaged oder auf (virtuellen) Maschinen in einem Cloud Umfeld betrieben wird.
Dieser sichere Hafen beschränkt sich nicht nur auf Infrastruktur-Komponenten, auch die Anwendungen profitieren von einer PaaS. Beispielsweise bieten die PaaS-Anbieter Rolling Updates an, bei dem während eines Versionswechsels eine Anwendung die Instanzen nach und nach ausgetauscht werden. Damit werden Ausfallzeiten vermieden. Ebenfalls können Stoßzeiten durch die PaaS-Anbieter abgefangen und die Anwendungen entsprechend der Anzahl der Anfragen hochskaliert werden.
Ausgewählte PaaS in der Übersicht
Der Markt für PaaS teilt sich derzeit in Cloud Foundry-, OpenShift-basierte und proprietäre Lösungen auf. Neben der Möglichkeit die PaaS-Lösungen selbst zu betreiben, bieten die meisten Anbieter neben Public auch Private Cloud Dienste an. Dies ermöglicht es für Unternehmen sowohl im eigenen Rechenzentrum, sowie auf gemanagten Umgebungen das gleiche Betriebsmodell zu nutzen. In diesem Segment sind vor allem die Hyperscaler wie AtoS, IBM, Swisscom, SAP und Red Hat aktiv. Auch Microsoft hat mittlerweile mit Azure Red Hat OpenShift ein managed OpenShift im Angebot.
Das PaaS-Angebot von Microsoft (Azure App Service) kann ebenfalls im eigenen bzw. gemanagten Rechenzentrum über Azure Stacks bezogen werden. Das Hauptgeschäft der meisten Anbieter ist der US-amerikanische Markt, dennoch bieten viele auch ein Hosting in Europa oder sogar in Deutschland an.
Folgend eine Übersicht der PaaS-Anbieter, bei denen die Dienste in Europa gehostet werden. Die Tabelle ist nach Plattformen gegliedert. Zudem werden die durch den Anbieter verwalteten Dienste gelistet.
PostgreSQL Redis Über 170 Integrationen mit SaaS-Anbieter (u.a. Datenbanken, Message Broker)
Kubernetes als Meta-Plattform
Oftmals ist ein Wechsel auf ein Public Cloud-Angebot aus ideologischer oder sicherheitstechnischer Sicht nicht möglich. Diese Herausforderungen haben sowohl RedHat als auch die Cloud Foundry Foundation verstanden. Mit OpenShift hat RedHat seit mehreren Jahren eine PaaS-Lösung auf Basis von Kubernetes im Repertoire. Mit Project Eirini hat auch Cloud Foundry eine Möglichkeit geschaffen Kubernetes als Orchestrierungs-Lösung für Container zu verwenden.
Beide Tools sind vor allem für Unternehmen interessant, die bereits Know-How für Kubernetes aufgebaut haben und nun die Vorteile einer PaaS den Entwicklern und Kunden zur Verfügung stellen wollen. Der Komfort dieser Lösungen geht jedoch mit höheren Kosten für den Betrieb einher, da sowohl OpenShift als auch Cloud Foundry weitere Dienste mitbringen, die nun ebenfalls unterhalten werden müssen.
Dass Kubernetes nicht nur eine ideale Meta-Plattform für PaaS-Angebote ist, hat auch Google verstanden und mit Knative einen Aufsatz für Kubernetes erschaffen, der Serverless-Workloads ausführen und verwalten kann.
Knative, Serverless und PaaS
Das Serverless sich nicht nur auf Function-as-a-Service (FaaS) bezieht und viele Gemeinsamkeiten mit PaaS hat, zeigt sich bei der Architektur von Knative. Diese beinhaltet neben der Komponente zum Verwalten von Workloads, auch eine Komponente zum Bauen des Services direkt aus dem Quellcode. Beides sind elementare Bestandteile eines PaaS-Angebots.
Die Serving-Komponente überwacht die Anzahl der Requests auf den Service und kann bei Bedarf oder Nicht-Bedarf den Service entsprechend der Anfragen hoch- oder gar auf keine Instanz herunterskalieren. Um eine URL auf die richtige Instanz zu leiten, benutzt die Serving-Komponente Istio. Damit können nicht nur einfache Routing-Use Cases wie in diesem Fall realisiert werden, sondern auch Szenarien wie A/B-Tests, bei denen eine Version A einem Teil der Kunden und eine Version B einem zweiten Teil der Kunden bereitgestellt wird. Dadurch kann beispielsweise ein direkter Vergleich zwischen zwei unterschiedlichen Varianten eines Features stattfinden.
Die Build-Komponente ist modular aufgebaut und kann auf verschiedene Mechanismen zurückgreifen. Nebst einem einfachen Plugin, dass nur ein Dockerfile (eine Datei die beschreibt aus welchen Teilen sich ein Docker-Image zusammensetzt) benötigt, können auch komplexe Builds auf Basis von Buildpacksdurchgeführt werden.
Über die Eventing-Komponente können nach Bedarf Instanzen eines Services gestartet werden, um so eine effektive und vor allem kostensparende Verarbeitung von Daten (z.B. die Umwandlung eines Bild von einem Format in ein anderes Format) durchzuführen. Die Eventing-Komponente stellt dabei Adapter für unterschiedlichste Quellen wie GitHub, Apache Kafka oder Google Cloud Pub/Sub bereit.
Komponente
Beschreibung
Serving
Serving übernimmt die Instantiierung der Container für die Services und verwaltet die Routen für Istio. Zudem überwacht Serving die Auslastung (z.B. Anzahl der Requests) des Services und skaliert diesen entsprechend der Anfrage hoch oder runter.
Build
Die Build-Komponente übernimmt das Erstellen der Container. Die Container werden auf Grundlage des Quellcodes der Anwendung erstellt. Der eigentliche Build-Mechanismus ist austauschbar und kann in der einfachsten Variante über ein Dockerfile im Quellcode-Verzeichnis, oder, angelehnt an Heroku oder Cloud Foundry, über Buildpacks ausgeführt werden.
Eventing
Eventing ermöglicht es Services mit verschiedenen Event-Quellen zu verbinden. Dadurch ist es beispielsweise möglich Instanzen eines Services für die Verarbeitung einer Nachricht in einem Message Broker zu starten.
Service Catalog
Neben Build und Ausführung, zeichnen sich die PaaS-Angebote, durch die angebundenen Managed Services aus. Auch für Kubernetes gibt es eine solche Lösung, die im Rahmen der Special Interests Group Service Catalogentstanden ist. Der Service Catalog implementiert den Client-Teil der Open Service Broker API. Der Provider-Teil wird von einer Vielzahl von Anbietern bereitgestellt. Die Liste der Implementierungen umfasst dabei Anbindungen an die managed Services der Cloud-Provider wie Microsoft Azure, Amazon Web Service und Google Cloud Platform und auch Anbindungen an Open Stack und vSphere (VMWare Service Broker), sowie Implementierungen die beispielsweise Helm (Paketmanager für Kubernetes) oder Ansible (Deklarative Beschreibung der Infrastruktur) nutzen. Letztere sind für die Entwicklung und für den Betrieb im eigenen Rechenzentrum von Interesse.
Der Clou an einem Service Catalog ist die schnelle Bereitstellung von Ressourcen wie Datenbanken, Message Broker oder S3-Buckets. Entwickler und DevOps deklarieren die gewünschten Maße (Arbeits-, Festplattenspeicher und CPU) und binden die erstellte Ressource an den eigenen Service. Der Betrieb der im Katalog verfügbaren Dienste wird durch entsprechendes Fachpersonal oder den Cloud-Provider durchgeführt. Wichtig ist, dass an dieser Stelle eine ausreichende Absicherung sowohl durch Backup- und Sicherheitsmechanismen der gemanaged Dienste als durch den Anbieter gewährleistet wird.
Zusammenfassung
Unternehmen stehen immer wieder vor der Frage, ob in Kubernetes investiert werden sollte. Bei kleinen Unternehmen und Start-Ups ist diese Frage unnötig. Die Investitionen die notwendig sind um Kubernetes zu betreiben, sind sehr hoch und bedürfen einer langen Zeitspanne bis sich diese rentieren. Vor allem für Start-Ups lenkt die Komplexität von Kubernetes zu sehr vom eigentlichen Geschäft ab und die treibt die Time-To-Market in die Höhe. Deshalb sollten Firmen die in dieser Kategorie angesiedelt sind, zumindest in den Anfangszeiten, Kubernetes meiden und eine PaaS wie Heroku, Elastic Beanstalk, Google App Engine oder ähnliches benutzen.
Dennoch sollten nicht nur Start-Ups über die Einführung von PaaS-Lösungen in die IT-Landschaft nachdenken. Vor allem für Anwendungen mit starkem Nutzerfokus und hoher Änderungsgeschwindigkeit sind PaaS-Lösungen optimal. Mit Cloud Foundry und OpenShift gibt es bereits zwei Lösungen die sowohl On-Premise betrieben als auch über Dienstleister gemanaged werden können und in der Public Cloud verfügbar sind. Ein einheitlicher Tech-Stack in der Private sowie in der Public Cloud kann für Synergien bei Betrieb und Entwicklung sorgen. Mit Azure Stacks kann auch das PaaS-Angebot von Microsoft im eigenen Rechenzentrum bzw. gemanaged betrieben werden.
Kubernetes ist mittlerweile zu einer stabilen Meta-Plattform herangewachsen und kommt als Unterbau mehrerer PaaS-Lösungen zum Einsatz. Diese Verschmelzung ist vor allem für Unternehmen interessant, die bereits Know-How in Kubernetes und Container-Technologien aufgebaut haben, da sie dadurch in der Lage sind den IT- und Entwicklungsabteilungen vollwertige PaaS-Services innerhalb der bestehenden Landschaft bereitzustellen.
Für Cloud Provider hält der aktuelle Markt eine gute Chance bereit die eigene Position durch innovative Technologien zu verbessern. Knative bietet eine gute Basis um Serverless-Workloads zu betreiben. In Kombination mit einem Service Catalog kann ein Dienst bereitgestellt werden, der die Vorzüge, wie sie aus einem PaaS-Angebot bekannt sind, mit der Ausgereiftheit von Kubernetes kombiniert.
IT-Dienstleister und Tool-Entwickler haben die Möglichkeit durch die Vereinigung von Knative und Service Catalog neue Produkte zu entwickeln, die eine von Heroku oder Cloud Foundry bekannte User Experience bieten und sich somit am zukünftigen Markt zu positionieren.
Empfehlungen
Nutzen Sie die Synergieeffekte und verhindern Sie Wildwuchs durch die Definition eines einheitlichen Tech-Stacks auf Basis von Cloud Foundry, OpenShift oder Azure Stacks.
Verlagern Sie Anwendungen mit starkem Nutzerfokus und hoher Änderungsfrequenz in PaaS-Lösungen und profitieren Sie von der Geschwindigkeit der Plattformen.
Nehmen Sie Knative in ihr Portfolio auf, um eine Option für Serverless auf Basis von Kubernetes anbieten zu können.
Automatisieren Sie die Bereitstellung von Infrastruktur-Komponenten (z.B. Datenbanken und Message-Queues) mittels Service Catalog und entlasten Sie ihr Operations-Team.
