Aber der Cloud-Trend beschränkt sich nicht nur auf Unified Communications and Collaboration (UCC). Viele Testumgebungen sind bereits in der Cloud. Hier können solche Umgebungen relativ schnell aufgebaut werden. Verarbeitet man in einer Testumgebung keine personengebundenen oder sonstige stark zu schützende Daten, sind Cloud-basierende Testumgebungen aufgrund der Vorteile der Cloud einfach zu verlockend.

Diesen Beispielen lassen sich weitere hinzufügen. Wir belassen es dabei.

Warum nicht alles in die Cloud?

Genauso wie der Gang in die Cloud für einige Anwendungen naheliegend und unumkehrbar ist, gibt es andere Anwendungen, die das gängige Modell der externen Clouds nicht nutzen können oder dürfen. Verschiedene technische bis rechtliche Gründe stehen dem Gang in die Cloud für bestimmte Anwendungen im Weg.

Ein einfaches Beispiel ist die industrielle Steuerung. Ein Roboter, der in einer Fertigungsumgebung eingesetzt wird, wird wohl kaum von einem tausende Kilometer entfernten Cloud-Rechenzentrum ausgesteuert werden können.

Andere Gründe, IT nicht in externe Clouds zu verlagern, können aus rechtlichen oder unternehmensinternen Richtlinien resultieren. Zu kryptografischen Zwecken eingesetzte private Schlüssel einiger Organisationen dürfen zum Beispiel die Räume der Organisation selbst nicht verlassen.

Hybrid Cloud ist die Antwort

Aus der Unumgänglichkeit der Cloud für einige und dem Ausschluss der Cloud für andere Anwendungen folgt das Konzept der Hybrid Cloud. Die Hybrid Cloud umfasst externe Clouds und unternehmenseigene Rechenzentren.

Man kann den externen und den internen Teil der Hybrid Cloud mit unterschiedlichen Technologien aufbauen. Während man in externen Clouds die Netz-, Server-, Speicher- und sonstigen Ressourcen so nutzt wie sie die Cloud-Betreiber betreiben, kann man im eigenen RZ auf die klassischen Designs für solche Infrastrukturen setzen. Eine derartige hybride Umgebung ist nicht integriert, sondern disjunkt, eine Art duale IT.

Ich habe mich zuletzt im Geleit vom September 2019 zur dualen IT geäußert [1]. Man kann über ihre Sinnfälligkeit streiten. Einige Unternehmen wollen eine duale IT möglichst vermeiden. Für solche Unternehmen haben die großen Cloud-Betreiber ein Konzept entwickelt, das die externe Cloud um Bestandteile in unternehmenseigenen Rechenzentren ergänzt. Ziel solcher Designs ist die Nutzung gleicher Mechanismen, Strukturen und Management-Verfahren in externen Clouds und Unternehmens-RZs.

Beispiel Azure Stack

Microsoft ist nicht nur der Betreiber der weltweit größten Cloud für Bürokommunikation (Microsoft 365, bisher überwiegend als Office 365 bekannt) und damit des weltweit größten Modells für Software as a Service (SaaS), sondern auch einer der größten Anbieter für andere Cloud-Modelle. Die Microsoft-Cloud für Infrastructure as a Service (IaaS) und Platform as a Service (PaaS) heißt Azure.

Die Azure-Cloud hat einen OnPrem-Ableger namens Azure Stack. Das Konzept von Azure Stack basiert darauf, dass Dienste und Funktionen, wie man sie von Azure kennt, auf Kundenumgebungen ausgeweitet werden. Diese Kundenumgebungen können ganze Rechenzentren sein oder Satelliten. Sogar disjunkte IT-Standorte können mit Azure Stack aufgebaut werden, d.h. eine ständig verfügbare Verbindung zur Microsoft-Cloud ist keine zwingende Voraussetzung für Azure Stack.

Microsoft unterscheidet hier die folgenden Szenarien:

• Azure Stack Edge: Hierbei handelt es sich um eine sogenannte Azure Managed Appliance, die Microsoft für IoT- und KI-Anwendungen an Satellitenstandorten positioniert und daher um Edge Computing im Sinne der weitverbreiteten und allgemeinen Definition des Ansatzes.
• Azure Stack HCI: HCI steht für Hyper-Converged Infrastructure. Azure Stack HCI kann als Compute- und Storage-Basis für Anwendungen genutzt werden. Somit ist Azure Stack HCI das Software-Defined Data Center (SDDC) mit Azure-Technologie.
• Azure Stack Hub: Dahinter verbirgt sich eine private und autonome Cloud-Umgebung, entweder mit der Azure-Cloud verbunden oder vollständig entkoppelt davon. Insofern bekommt ein Unternehmen mit Azure Stack Hub eine Umgebung, die es in Gänze selbst betreiben kann. Microsoft wirbt für dieses Konzept ausdrücklich mit dem Stichwort digitale Souveränität, siehe mein Geleit vom Juni 2020 [2].

Beispiel AWS Outposts

Amazon bietet wie Microsoft eine Lösung an, die eine Erweiterung der Cloud auf die Rechenzentren von Kunden ermöglicht. Bekanntlich ist Amazon mit AWS (Amazon Web Services) der größte IaaS-/PaaS-Anbieter. AWS Outposts ist der Name des OnPrem-Ablegers von AWS. Laut Amazon dient das Design von AWS Outposts einem „konsistenten Hybrid-Erlebnis“.

Es gibt einen nicht unerheblichen Unterschied zwischen Azure Stack und AWS Outposts. Amazon hebt hervor, dass es sich bei AWS Outposts um einen „vollständig verwalteten Service“ (Fully Managed Service) handelt. Somit gibt es AWS Outposts nur in der „verbundenen“, von Amazon verwalteten Variante. Eine autonome und disjunkte Ausführung, etwa vergleichbar mit Azure Stack Hub, gibt es bei AWS nicht.
Amazon nennt drei Beispielszenarien für den Einsatz von AWS Outposts:

• Anwendungen, die nur niedrige Latenzen tolerieren
• Applikationen, die lokale Datenverarbeitung erfordern
• Datenhaltung an Kundenstandorten

Für AWS Outposts werden die gleiche Hardware, Dienste, Programmierschnittstellen (APIs) und Werkzeuge eingesetzt, wie man sie von AWS kennt. In dieser Beziehung ähneln sich AWS Outposts und Azure Stack HCI. Eine AWS-Outposts-Umgebung ist immer einer AWS-Region zugeordnet und mit den dort verfügbaren Werkzeugen zu administrieren. Die diesbezügliche Arbeitsteilung zwischen dem Kunden und Amazon ist dieselbe wie in der Cloud: Die Infrastruktur wird von Amazon administriert während der Kunde darauf basierend virtuelle Maschinen, Speicher und Netze nach dem eigenen Bedarf einrichten und betreiben kann.

Es gibt neben dem nativen AWS Stack eine zweite Variante von AWS Outposts, die auf einem VMware Stack aufbaut. Das ist ein Zugeständnis von Amazon an Kunden, die es bisher gewohnt sind, die SDDC-Lösung von VMware zu nutzen. Man kann darüber spekulieren, wie lange Amazon zwei Varianten von AWS Outposts anbieten wird.

Der Kampf um das RZ wird noch spannender

In den letzten Jahren haben wir hin und wieder über den Kampf um das RZ zwischen Herstellern geschrieben, zum Beispiel im Insider vom Dezember 2015 [3]. Dieser Kampf war zunächst hauptsächlich zwischen Cisco und VMware. Während Cisco mit der Lösung Application Centric Infrastructure (ACI) auf ein Design rund um die eigenen Switches und einen zugehörigen Controller setzt, bietet VMware ein vollständig auf Software basierendes SDDC inklusive Compute (vSphere), Storage (vSAN) und Netz (NSX). Beide haben ihre Netzlösung um Security-Funktionen wie Mikrosegmentierung ergänzt.

In der neuen Phase des Kampfes um das RZ geht es aber um mehr als nur Netz- und Sicherheitskonzepte. Es geht nun um nicht weniger als eine vollständige RZ-Umgebung, wenn die großen Cloud-Anbieter ihr Angebot um OnPrem-Ableger ergänzen. Bekanntlich setzen Microsoft und Amazon in ihren Clouds von ihnen selbst entwickelte oder zumindest mitentwickelte Lösungen für Compute, Storage, Netz und Security ein. Wenn diese Gesamtlösungen sich durchsetzen, wird es für klassische Anbieter von RZ-Komponenten eng. Und mit klassischen Anbietern sind nicht nur Netzhersteller gemeint, sondern auch Hersteller in den Bereichen Server, Virtualisierung, Speicher und Sicherheit.

Insofern wird der Kampf um das RZ spannender.

Verweise

[1] Moayeri, Behrooz: Duale IT – Fluch oder Segen? (Netzwerk Insider, September 2019)
[2] Moayeri, Behrooz: Cloud – aber richtig (Netzwerk Insider, Juni 2020)
[3] Moayeri, Behrooz: Cisco ACI kontra VMware NSX: War da was? (Netzwerk Insider, Dezember 2015)