JAXenter: Ihr werdet über den Cloud Native Stack sprechen. Ist das schon ein fixer Terminus? Oder was versteht man bzw. Ihr darunter?
Josef Adersberger und Mario-Leander Reimer: Der Terminus Cloud Native etabliert sich gerade, nicht zuletzt durch die Cloud Native Computing Foundation unter dem Dach der Linux Foundation. Als Cloud Native bezeichnet man Anwendungen, die inhärent dafür ausgelegt sind, in der Cloud zu laufen wie z.B. Microservices, Twelve-Factor Apps, Self-contained Systems und Big-Data-Anwendungen. Das bringt eine ganze Reihe an Vorteilen: man kann besser skalieren – mit der Last und zusätzlichen Funktionen, man kann größere Datenmengen verarbeiten, der Betrieb wird effizienter und Continuous Delivery erst möglich.
Aufgabe des Cloud Native Stacks ist es, die zusätzliche Komplexität, die durch den Betrieb in der Cloud entsteht, vor den Anwendungen bestmöglich zu verbergen.
Den Begriff Cloud Native Stack prägen wir gerade, denn man benötigt ja auch einen Stack, auf dem Cloud Native Anwendungen laufen. Das Spannende daran ist, dass es nicht den einen Stack gibt, sondern eine ganze Reihe alternativer Bausteine, aus denen man sich seinen Stack zusammenbauen kann. Alle relevanten Bausteine sind open source und entstammen oft Cloud-Größen wie Google, Netflix oder Twitter.
JAXenter: Woraus besteht der Cloud Native Stack und welche Aufgabe hat er?
Josef Adersberger und Mario-Leander Reimer: Aufgabe des Cloud Native Stacks ist es, die zusätzliche Komplexität, die durch den Betrieb in der Cloud entsteht, vor den Anwendungen bestmöglich zu verbergen. In der Cloud sind Anwendung hochgradig verteilt und alles kann immer fehlschlagen. So etwas erzeugt eine deutliche zusätzliche Komplexität.
Obwohl es viele alternative Bausteine im Cloud Native Stack gibt, ist der Aufbau stets gleich: Die Basis bildet ein Cluster-Scheduler, der Container auf den verfügbaren Ressourcen ausführt. Diesen nutzt der Cluster-Orchestrierer, um ganze Anwendungen laufen zu lassen. Die Anwendungen sind auf Basis einer Applikationsplattform entwickelt. Das ist gut vergleichbar mit einem klassischen Stack, wie etwa JEE: Der Cluster-Scheduler entspricht dem Betriebssystem, der Cluster-Orchestrierer dem JEE-Applikationsserver und die Applikationsplattform entspricht der JEE API.
JAXenter: Die “Cloud” geistert ja nun schon seit mehreren Jahren durch die IT-Szene. Welche neuen Impulse bringt nun aber der gerade beschriebene Cloud Native Stack mit sich?
Josef Adersberger und Mario-Leander Reimer: Der entscheidende Impuls des Cloud Native Stacks ist, dass die Infrastruktur der Cloud-Giganten für die Entwicklung und den Betrieb von Anwendungen nun für Jedermann verfügbar ist. Man nennt dies auch GIFEE: Google Infrastructure For Everbody Else. Man kann damit Anwendungen bauen, die vorher undenkbar waren. Nachdem sich im Cloud Computing der Bereich Infrastructure-as-a-Service (IaaS) bereits etabliert hat, wird sich durch den Cloud Native Stack auch der Bereich der Platform-as-a-Service (PaaS) etablieren.
JAXenter: Ihr zeigt auf der W-JAX, wie man eine Spring-Cloud-Anwendung als Docker Container in Kubernetes auf der DC/OS-Plattform deployt. Gehen wir mal der Reihe nach vor: Was gefällt euch an Spring Cloud?
Josef Adersberger und Mario-Leander Reimer: Spring Cloud hat die typischen Vorteile eines Spring-Projekts: ein einfaches und eingängiges Programmiermodell, viel Drive im Open-Source-Projekt und gute Werkzeugunterstützung. Spring Cloud bleibt den Prinzipien des Spring Frameworks treu und abstrahiert von der umgebenden Infrastruktur. Dies ist gerade bei Cloud Native Anwendungen extrem hilfreich, da das Feld noch jung ist und Infrastruktur-Bausteine, also Elemente des Cloud Native Stacks, kommen und gehen.
JAXenter: Weshalb Docker-Container?
Josef Adersberger und Mario-Leander Reimer: Docker vereinheitlicht den Transport und die Ausführung von Anwendungsbestandteilen. Wir nennen dies auch Betriebskomponenten: die Fortführung der Idee von Softwarekomponenten bis in den Betrieb. So etwas geht schon lange über Hardware-Virtualisierung. Der Transport der voluminösen virtuellen Images ist hier aber langwierig und der Ressourcenverbrauch bei der Ausführung üppig. Docker als Lösung zur Betriebssystem-Virtualisierung macht die Dinge leichter: die virtuellen Images sind kleiner, es gibt eine integrierte Image-Logistik und der Ressourcen-Overhead ist praktisch null.
JAXenter: Kommen wir zu Kubernetes – was bringt diese Komponente mit ins Spiel?
Josef Adersberger und Mario-Leander Reimer: Kubernetes ist im Kern ein Cluster-Orchestrierer. Kubernetes übergibt man eine Blaupause einer Anwendung, die beschreibt welche Docker Container wie gestartet, versorgt und verschraubt werden müssen, damit die Anwendung läuft. Neben diesem Anwendungsfall “Anwendung starten” automatisiert Kubernetes noch viele weitere Standard-Betriebs-Prozeduren. Dazu zählen z.B. das Skalieren von Anwendungen, der Austausch von Schlüsseln, die Veränderung von Konfigurationswerten oder sogar komplexe Rollut-Szenarien wie Canary Releases.
Das Motto der Stunde ist Play Hard: Es gibt viele spannende Technologien, mit denen man zumindest schon mal spielerisch Erfahrungen sammeln sollte.
JAXenter: Und schließlich die DC/OS-Plattform. Wozu ist diese nützlich in Eurem Setup?
Josef Adersberger und Mario-Leander Reimer: DC/OS bietet zwei Dinge: zum einen mit Mesos den aktuell leistungsfähigsten Cluster Scheduler und, zum anderen eine umfangreiche Infrastruktur um Mesos herum, die DC/OS zu einem Betriebssystem für die Cloud macht. DC/OS dient somit als Fundament des Cloud Native Stacks.
JAXenter: Was ist die Kernbotschaft Eurer Session, die jeder mit nach Hause nehmen sollte?
Josef Adersberger und Mario-Leander Reimer: All diejenigen, die eine bisher undenkbare Anwendung bauen wollen oder einfach nur ihre bestehende Anwendung besser skalierbar und effizienter betreibbar machen wollen, sollten sich mit dem Cloud Native Stack auseinandersetzen. Das Motto der Stunde ist Play Hard: Es gibt vielerlei spannende Technologien, mit denen man zumindest schon mal spielerisch Erfahrungen sammeln sollte – denn der Cloud Native Stack wird verändern, wie wir Anwendungen in Zukunft bauen.
JAXenter: Wir danken für dieses Gespräch!
