"OpenStack war die schlimmste aller Welten"

Der CEO von Red Hat, Jim Whitehurst, konnte vor kurzem rund 6000 Besucher auf dem Red Hat Summit in Boston begrüßen. John Dix, Chefredakteur unserer US-Schwesterpublikation "Network World", hatte Gelegenheit, mit Whitehurst zu sprechen.

"Die Hybrid Cloud ist eine Reise, kein Zielort"

Einer der Redner auf Ihrer Konferenz sagte, dass 84 Prozent aller Red-Hat-Kunden eine Cloud-Deployment-Strategie besitzen. Treibt der Cloud-Boom Ihr Geschäft?

James Whitehurst: Ich glaube schon, dass uns der Trend in die Cloud hilft. Unsere Daten zeigen, dass uns Kunden, die Cloud Computing nutzen, schnelleres Wachstum bescheren. Die Versprechen, die die Cloud macht, beschleunigen die Migration von Unix zu Linux. Die Leute modernisieren ihre Applikationen, um den Weg in die Cloud zu beschreiten. Und Linux ist das Basissystem für Cloud-Infrastrukturen. Ganz generell ist es so, dass alles, was die Leute dazu bringt, von einer alten auf eine neue Architektur zu wechseln, gut für uns ist. Die Cloud ist also ein wirklich großer Treiber.

Einer der Vorteile der Red Hat Enterprise Linux (RHEL)-Distribution ist, dass sie in jeder Umgebung läuft - egal ob VMware, Hyper-V, Amazon, Google oder Azure. Wir haben sie so entworfen, dass die Kunden Applikationen für RHEL schreiben können und diese dann überall laufen. Auf der anderen Seite wollen auch alle Cloud-Provider mit uns arbeiten und eine RHEL-Zertifizierung bekommen, weil Sie sich diese Workloads nicht entgehen lassen wollen. Für uns funktioniert es super, der Klebstoff zwischen Applikation und Deployment zu sein.

Wo wir gerade davon sprechen, Apps zu hosten: Wie nah sind wir eigentlich der Hybrid-Cloud-Vision, nach der On-Premise-Apps bei Spitzenauslastung einfach in die Public Cloud "verschoben" werden können?

Whitehurst: Die Hybrid Cloud ist eine Reise, kein Zielort. Wir sind also in gewisser Weise schon da. Wir haben heute bereits Banken und Hedge Fonds unter unseren Kunden, die Analytics on Premise betreiben und regelmäßig auf die Public Cloud ausweichen müssen, entweder zum täglichen Handelsschluss oder bereits vor Handelsstart.

Dieses Szenario eignet sich nicht für jede Applikation und jeden Kontext. Das Skalieren von Daten ist immer noch ein wirklich schwieriges Unterfangen. Applikationen, die darauf ausgelegt sind zu skalieren helfen da schon viel, aber einfach ein SAP-ERP-System auf Amazon zu 'quetschen' wird nicht funktionieren. Es geht aber für ganz bestimmte Typen von Workloads. Für die Zukunft wollen wir deren Zahl steigern, soweit das relevant und möglich ist.

"Wir wollen keine Open-Source-Projekte starten"

Sie haben auf dem Summit eine Ankündigung bezüglich Amazon gemacht. Erzählen Sie uns mehr darüber.

Whitehurst: Das Announcement besteht aus verschiedenen Komponenten. Eines davon ist besserer RHEL-Support. Vieles was wir tun, hängt mit dem Thema Hardwarekompatibilität unter RHEL zu tun. Hier müssen wir solange weitermachen, bis wir mit jedem Hardwarehersteller kompatibel sind. Zu diesem Zweck bauen wir ein eng verzahntes Team von Entwicklern auf, um die Amazon-Hardware so bald wie möglich unterstützen zu können.

Am wichtigsten ist aber, dass wir gemeinsam alle Amazon-Services nativ auf OpenShift [Anm.d.Red.: Die Container-Plattform von Red Hat] bringen. Wenn Sie unsere Container-Plattform on Premise betreiben und Amazon-Services nutzen wollen, können Sie diese Dinge künftig nativ über OpenShift nutzen. Wir glauben, dass das für Entwickler eine große Sache ist.

Inwiefern unterstützt OpenShift auch andere Container-Tools?

Whitehurst: Wir kooperieren auf vielfältige Weise mit Docker und sind nach Docker selbst der zweitgrößte Kontributor beim Docker Project. Als Open-Source-Company wissen wir, wie schwer es ist, ein Framework oder eine Spezifikation zu verkaufen. Sie brauchen eine Laufzeitumgebung. Bei unserer Container-Plattform handelt es sich um ein Bundle, das wir RHEL Atomic genannt haben. Es ist unser 'Linux-Light' für Container im Einsatz. Es handelt sich dabei um die Docker-Spezifikation, aber wir bezahlen dafür nichts, sondern nutzen die Open-Source-Variante. Für die Orchestrierung nutzen wir Kubernetes. Auch hier gibt es ein Projekt, bei dem wir - nach Google - ebenfalls den zweitgrößten Beitrag leisten. Für die Automatisierung nutzen wir Ansible und einige Management Tools namens CloudForms. Und dann gibt es noch eine komplette DevOps Toolchain, die daran anknüpft.

Wenn man sich das mal auf Grundlage der Laufzeitumgebung überlegt, ist es ziemlich beeindruckend, dass die Lösung Docker Container, Orchestrierung und Automatisierung unter einen Hut bekommt. Docker hat ein Projekt namens 'Swarm' ins Leben gerufen, um eine 'Runtime' zu kreieren. Das steht wiederum in Konkurrenz zu Kubernetes. Auf diesem Level konkurrieren wir also mit Docker. Nichtsdestotrotz werden wir - wie schon in der Vergangenheit - enge Partner bleiben.

Red Hat sieht sich nicht in der Rolle, Open-Source-Projekte zu initiieren. Das ist alles andere als ein leichtes Unterfangen. Wir sehen uns eher in der Rolle, die populärsten Projekte zu identifizieren und diese mit Lifecycle-Versionen zu versorgen. OpenShift ist ebenfalls kein Projekt, das Projekt ist Red Hat Linux, das Docker Container, Kubernetes und Ansible zusammenbringt. In unseren Augen bündelt dieses Paket die Komponenten der führenden Projekte in einer leicht konsumierbaren Container-Laufzeitumgebung.

Als wir von einem physischen auf ein virtualisiertes Data Center umgestiegen sind, musste sich ein ganzes neues Management-Paradigma herausbilden. VMware ist ein Unternehmen für das Management von virtualisierten Data Centern und der Grund, warum sie aus dem Stand eine Sechs-Milliarden-Dollar-Company geworden sind. Sie haben dieses neue Paradigma verinnerlicht und beim Aufbau ihrer Plattform großartig umgesetzt.

Auf Applikationsebene sieht es so aus, dass der Umstieg von monolithischen Applikationen auf Microservices, die in Containern betrieben werden, sowohl eine völlig neue Applikationsplattform als auch ein neues Management-Paradigma erfordern. Wenn Sie 400 Enterprise-Anwendungen haben, die in 1,2 Millionen Containern realisiert sind, dann kommunizieren die Microservices über APIs und Messaging miteinander. Was, wenn an dieser Stelle ein Performance-Problem auftritt? Wie gehen Sie damit um?

All die Dinge, die in der alten, traditionellen Welt Bestand hatten, müssen in einer containerisierten Welt neu implementiert werden. Red Hat will nicht unbedingt versuchen alles zu tun, aber OpenShift ist eine Kernplattform, die es erlaubt Container zu skalieren. Darüber hinaus arbeiten wir mit den Softwareherstellern zusammen, um weitere Funktionen anbieten zu können. Es ist eine Applikationsarchitektur, die fundamental anders ist.

Eine andere Sache in Bezug auf Container: Ich glaube, viele Leute verfallen schnell der Idee, Container wären eine Form der Virtualisierung. Das ist zwar in gewisser Weise richtig, weil mehrere Applikationen auf einem physischen oder virtualisierten Server betrieben werden. Der Unterschied ist aber: Auf Containern laufen nicht nur Applikationen. Hier wird auch das Betriebssystem sozusagen aufgeteilt. Der 'User Space' des Betriebssystems, den die Applikation braucht, befindet sich im Container. Das ist wichtig, weil mehr als 95 Prozent der Betriebssystems-Sicherheitslücken genau in diesem User Space liegen.

Der letzte große Bug hat rund 95 Prozent aller Container betroffen. Deren Inhalt muss natürlich mit einem Lifecycle versehen werden. Genauso wie alle Komponenten des Betriebssystems. Das funktioniert nicht nach dem Motto: 'Applikations-Logik im Container? Dann muss ich mich ja um nichts mehr kümmern'. Denn eigentlich liegt nun auch ein Großteil des Betriebssystems im Container. Wir sind der Überzeugung, dass Linux-Container einen Lifecycle und Patches brauchen. Selbst eine primitive Applikation, die über ein Jahr in einem Container betrieben wird, braucht 50 Security-Updates.

"Das wird explodieren wie keine Technologie je zuvor"

Lässt sich quantifizieren wo wir in Sachen Container-Adoption stehen?

Whitehurst: In meinen Augen wird diese Technologie explodieren, wie keine andere je zuvor. Sogar stärker noch als die Virtualisierung. Container stellen ein Deployment zu einem dramatisch niedrigeren Preis in Aussicht und ermöglichen eine viel effektivere Entwicklung von Software. Hierbei kann man nur gewinnen. Aber für die Bereitstellung in großem Maßstab reicht es momentan noch nicht ganz. Jeder spielt noch mit dieser Technologie rum und testet sie. Einige Banken haben mit dem Roll-out begonnen, aber wenn es darum geht echte, produktive Applikationen zu betreiben, gibt es in diesem Bereich nur einige wenige Early Adopter.

Die Public Cloud ist in Sachen Container schon viel weiter. Jeder erprobt bereits die Möglichkeiten, aber wir sind in diesem Bereich mit Abstand Marktführer und stehen mit all diesen Unternehmen in Kontakt. Ich würde sagen, wir sprechen hier von einigen hundert Firmen, die diesbezüglich etwas in Produktion haben.

Noch eine perspektivische Frage: Sie haben kürzlich gesagt, ein Drittel der Red-Hat-Gewinne sei auf die OpenStack-Umgebung zurückzuführen. Tatsächlich hatten Sie aber anfangs Ihre Probleme damit. Was ist nun richtig?

Whitehurst: Ja, ein Drittel ist richtig. Sagen wir, wie es ist: In den frühen Tagen war OpenStack die schlimmste aller Welten. Jeder Hersteller adaptierte es so schnell wie möglich, weil man glaubte, sich vor Amazon schützen zu können. So wurden sehr frühe Versionen auf die Kunden losgelassen, weil niemand zu spät dran sein wollte. Hatte man es dann zum Laufen gebracht, konnte man es in der Regel nicht updaten, denn dafür brauchte es einen Doktortitel. Wir haben es deswegen erst einmal etwas langsamer angehen lassen. Über die Zeit ist OpenStack gereift. Die letzten Revisionen laufen stabil und eignen sich hervorragend für ein ganzes Set von Workloads. Im Vergleich zur Public Cloud ist das der ökonomischere Weg, um Workloads abzubilden. Dabei wird die Adaption der nächsten OpenStack-Generation unumgänglich sein. Dafür werden der weiter steigende Traffic, aber auch neue Technologien, etwa das 5G-Netzwerk, sorgen.

Wir sind auf dem OpenStack-Markt ein großer Player und mit Abstand der größte Upstream-Lieferant. Aber es gibt auch viele Kundengespräche, in denen wir zwar wegen OpenStack angesprochen werden, dann aber Red Hat Enterprise Virtualization - unser VMware-Äquivalent - verkaufen. Wenn man Automatisierung und Skalierung will, ist OpenStack phänomenal, aber betreiben Sie hierauf mal eine Applikation, die hochgesichert laufen muss. Dann schneiden Sie sich ins eigene Fleisch. Es ist eine andere Architektur für eine andere Welt.

Ein interessanter Fakt zu unserer OpenShift-Container-Plattform: Jeweils ungefähr ein Drittel unserer Kunden betreibt sie auf VMware, OpenStack oder Amazon. Einige sagen: 'Ich habe schon eine gute VMware-Infrastruktur, habe ein ELA [Anm.d. Red.: Enterprise License Agreement], ich schmeiße es einfach da mit hinein'. Leute, die etwas komplett Neues aufbauen, setzen entweder auf OpenStack oder die Cloud. OpenShift kann in jedem dieser Modelle betrieben werden.

"Der banale Downstream-Kram sorgt dafür, dass wir existieren"

Neben VMware ist auch Microsoft einer ihrer Haupt-Konkurrenten, richtig?

Whitehurst: VMware ist definitiv ein Konkurrent. In unserer bizarren 'Coopetition'-Welt konkurrieren wir seltsamerweise nicht so sehr mit Microsoft, weil es deren Welt und die Java-Welt gibt. Wir konkurrieren mit Oracle und IBM im Middleware-Segment. Mehr als mit Microsoft wie ich glaube. Technisch gesehen natürlich auch mit Microsoft aber nicht auf einem Deal-by-Deal-Level. Und auch wenn VMware in Sachen Software-defined Data Center ein klarer Konkurrent ist: Wir arbeiten viel mit ihnen zusammen und viele RHEL-Distributionen läuft auf ihren Produkten.

Sehr gut. Abschließende Bemerkungen?

Whitehurst: Unser Modell beruht auf folgendem Gedankengang: 'Hier ist ein Set an Notwendigkeiten in einem Unternehmen und dort ist ein cooles Bündel Cloud-nativer Open-Source-Technologien. Wie bringen wir diese Welten in konsumierbarer Weise für das Unternehmen zusammen?' Ich glaube, eine Menge Leute würden auch sagen: 'Red Hat bietet Support, der über Open Source hinausgeht'. In unseren Geschäftsberichten können Sie sehen, dass nur sechs Prozent unserer Kosten auf Support entfallen. Forschung und Entwicklung macht bei Red Hat einen höheren prozentualen Anteil der Einnahmen aus als bei Microsoft. Aus Open-Source-Technologie ein Produkt zu machen, das Lifecycle-Anforderungen genügt, ist echt teuer.

Wir haben ein paar Tausend Entwickler im Einsatz. Die müssen jedem Bugfix und Security Update in den 72 verschiedenen Kerneln, die wir unterstützen, nachgehen. Dabei darf natürlich nichts kaputtgehen, weswegen wir für die Applikation auf Binärkompatibilität setzen. Wenn ein Kunde eine Applikation, SAP oder Oracle etwa, auf Red Hat Enterprise Linux betreibt, weiß er, dass er die nächsten 13 Jahre den vollen Support bekommt und nie etwas kaputtgeht.

Open Source kann das nicht. Die Grundidee stammt aus der Open-Source-Welt, aber für die nächsten 13 Jahre sorgen Tausende von Red-Hat-Entwicklern dafür, dass alles läuft. Wenn ich davon spreche, Open Source konsumierbar zu machen, geht es bei weitem nicht nur um technischen Support. Der ist tatsächlich relativ einfach zu bewerkstelligen.

Keiner bringt ein neues Stück Hardware heraus, ohne es vorher Red Hat vorzulegen. Wir pflegen eine gewaltige Matrix, in der jede Applikation auf jeder Hardware getestet wird. SAP zum Beispiel rollt keine Applikation aus, die nicht vorher in unseren Laboren auf Hardwarekompatibilität getestet wurde. Diese Abstraktionsschicht ist für unsere Arbeit sehr wertvoll. Es ist toll, all diese coolen, offenen Innovationen zu sehen - und dass wir der größte Kontributor für viele dieser Projekte sind. Aber letzten Endes ist es eigentlich der banale Downstream-Kram, der dafür sorgt, dass wir existieren.

Dieser Artikel basiert auf einem Beitrag unserer US-Schwesterpublikation networkworld.com.