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.