On-Premises-Cloud

Doch in der Zwischenzeit hat sich das deutlich verändert, sodass nicht nur junge und moderne Start-Up-Unternehmen, sondern zunehmend auch Unternehmen aus allen Branchen derartige Angebote nutzen, oder zumindest deren Einführung in Erwägung ziehen.

Schnell hat sich ebenfalls der Begriff „Hybrid Cloud“ etabliert, unter dem im Wesentlichen die gleichzeitige Nutzung von IT-Services aus dem eigenen RZ und aus der Cloud zu verstehen ist. Doch letztendlich handelt es sich dabei um zwei voneinander unabhängige Welten, die kein einheitliches Management oder sonstige Gemeinsamkeiten miteinander vereinen.

Seit geraumer Zeit stellen die drei großen Cloud-Anbieter jedoch Lösungen bereit, die diese Gemeinsamkeiten zwischen der Private und der Public Cloud herstellen und eine Brücke zwischen diesen beiden Welten bauen sollen.

Der folgende Artikel befasst sich mit diesen Lösungen, stellt sie vor und führt in diesem Zusammenhang den Begriff „On-Premises-Cloud“ ein.

On-Premises-Cloud

Public, Private und Hybrid Cloud sind Begriffe, die in der IT-Branche mittlerweile jedem geläufig sind und deren Definition als Lerninhalt bei der Ausbildung eines IT-Berufes zum Standardrepertoire gehört. Doch was ist eine On-Premises-Cloud? Einfach nur ein neuer Name für alten Wein in neuen Schläuchen?

Was zunächst wie ein Widerspruch in sich selbst klingt, kann dazu beitragen, dass Anwendungen (oder auf Neudeutsch „Workloads“), die bislang aus bestimmten Gründen als nicht cloudfähig bewertet wurden, dennoch in die Cloud verlagert werden können.

Doch eins nach dem anderen.

Mit dem Begriff Cloud verbindet man in der Regel, dass IT-Services irgendwo auf der Welt in einem externen Rechenzentrum bereitgestellt werden, Anwender diese Services je nach Bedarf abrufen und man nur für die tatsächliche Nutzung bezahlen muss. Außerdem sagt man der Cloud nach, dass deren Leistungs- und Rechenkapazität schier unendlich ist und sich punktuell den jeweiligen Anforderungen der Nutzer anpassen kann. Amazon hat mit der Gründung des Tochterunternehmens „Amazon Web Services“ (AWS) im August 2006 und der Einführung des Angebotes „Elastic Compute Cloud“ den Begriff „elastisch“ als ein wesentliches Charakteristikum der Cloud geprägt.

Doch trotz der vielversprechenden Argumente, die für die Nutzung von Cloud Services sprechen, wie etwa Erhöhung der Flexibilität, „Pay as you go“, Skalierbarkeit und all die anderen bekannten Argumente waren viele unserer Kunden zunächst sehr skeptisch gegenüber dem neuen Servicekonzept eingestellt. Unsere Projekterfahrung zeigt jedoch, dass sich dies in den letzten Jahren deutlich verändert hat und immer mehr unserer Kunden die Cloud als festen Bestandteil in ihre IT-Infrastruktur integrieren. Dieser Umstand lässt sich sicherlich auch damit begründen, dass das Vertrauen in die Cloud-Anbieter hinsichtlich der Einhaltung von gesetzlichen Vorschriften bezüglich Datenschutz gestiegen ist.

So kommt es, dass z.B. einer unserer Kunden seine gesamte IT-Landschaft vorbehaltlos auf den Prüfstand gestellt hat. Ziel dieses Projektes war es, so viele IT-Services wie möglich in die Cloud zu verlagern, um damit bis dato eigenbetriebene IT-Systeme abzubauen und dadurch die freiwerdenden Flächen im RZ und den dislozierten Technikräumen einer neuen Nutzung zuführen zu können sowie gleichzeitig die eigenen Kosten für die IT zu minimieren.

Ein sehr aufwändiges Unterfangen, das sich am Ende jedoch gelohnt hat. So wurden rund 60 – 70% der IT-Systeme und IT-Verfahren identifiziert, die in den kommenden Jahren und im Laufe ihres Lebenszyklus‘ sukzessive zu entsprechenden Cloud-Servicemodellen (IaaS, PaaS, SaaS) ausgelagert werden. Bei dieser Betrachtung wurden nicht nur datenschutzrechtliche Aspekte berücksichtigt, sondern auch kommerzielle Abschätzungen gemacht. Demnach verspricht die Auslagerung der IT-Services nach Abschluss der Transition eine signifikante Kostenreduktion.

Am Rande, aber nicht unwichtig, ist zu erwähnen, dass die Grundlage für eine so hohe „Trefferquote“ die Bereitschaft zu einem hohen Maß an Standardisierung der internen Prozesse war.

Doch was hat das alles nun mit dem Begriff On-Premises-Cloud zu tun?

Eine ganze Reihe von IT-Services wurde als nichtauslagerungsfähig eingestuft, weil datenschutzrechtliche und/oder technische Argumente wie z.B. Paketlaufzeiten, etc. dagegen sprachen. Deshalb wurde beschlossen, diese Services weiterhin in klassischer Manier On-Premises, d.h. auf eigener Infrastruktur im eigenen Rechenzentrum und mit eigenem IT-Personal zu betreiben, auch wenn in diesem konkreten Fall der Wunsch und der Wille zur Auslagerung dieser Services in die Cloud bestand.

Und hier kommt die On-Premises-Cloud ins Spiel.

Die großen Cloud-Anbieter stellen für die Lösung dieser Herausforderung mit Azure Stack von Microsoft, Outposts von AWS und Anthos von Google jeweils eine Lösung bereit, die die Clouds der jeweiligen Anbieter in das Kunden-Rechenzentrum bringen und sich nahtlos in die dortige Infrastruktur integrieren.

Doch ist das nicht das, was man klassischerweise unter einer Hybrid Cloud versteht, also die Integration einer privaten Cloud in die Angebote der Public-Cloud-Anbieter? Die Antwort ist ein klares „Jein“.

Ja in dem Sinne, dass diese Lösungen lokale IT-Ressourcen mit denen der Public Cloud verbinden. Nein, dahingehend, dass sie u.a. die Administration und das Management von Cloud- und On-Premises-Ressourcen vereinheitlichen und das Management der On-Premises-Hardware zumindest teilweise durch den Cloud-Anbieter erfolgt.

Der Unterschied zu einer „herkömmlichen“ Hybrid Cloud besteht demnach darin, dass nun eine tiefe Integration der On-Premises Services mit der Cloud auf Basis eines einheitlichen Managements, einheitlicher Programmierschnittstellen (APIs) und zentralisierten Monitorings zur Orchestrierung der Workloads in der Hybrid Cloud möglich ist – sozusagen die Hybrid Cloud 2.0, wenn man so will.
Obwohl die genannten Lösungen das gleiche Ziel verfolgen und vergleichbare Funktionen bieten, existieren im Detail gewisse Unterschiede, die hier gegenübergestellt werden sollen. Die folgende Abbildung gibt hierzu einen Überblick.

Nachfolgend ein etwas ausführlicherer Überblick der jeweiligen Spezifika.

Hardware-Optionen

Alle drei Lösungen unterstützen unterschiedliche Optionen für die Hardware, die OnPrem erforderlich ist.

Google Anthos unterstützt eine Vielzahl von Hardware-Plattformen und ist mit den meisten Server-Plattformen kompatibel, sodass die Lösung entweder auf vorhandener Hardware oder auf vergleichsweise günstigen Standard-Servern implementiert werden kann.

Im Gegensatz dazu wird Azure Stack ausschließlich auf Server-Hardware unterstützt, die durch Microsoft für diesen Anwendungsfall zertifiziert ist. Hier geht es in der Regel um Data-Center-Komponenten, die speziell für Azure Stack konzipiert sind.

Azure Stack Edge ist ein ergänzendes „Hardware-as-a-Service”-Angebot, das für die Datenverarbeitung am Edge ausgelegt ist. Hierbei handelt es sich um Appliances, auf denen VMs und Containeranwendungen ausgeführt werden können. Sie sind in unterschiedlichen Ausführungen verfügbar, wie z.B. 19“-Rackmontage, „ruggedized“ in robuster Bauform für den Einsatz in entsprechenden Umgebungen und als „Mini“-Version mit Akkubetrieb für den mobilen Einsatz.

AWS Outposts hingegen setzt ausschließlich auf eine eigens hierfür entwickelte Hardware-Plattform, die von AWS vertrieben, installiert und administriert wird. Dabei handelt es sich um modular aufgebaute Racks, die mit Servern, Storage und Netzkomponenten ausgestattet sind und im Kunden-RZ installiert und mit einer AWS-Region verbunden werden.

Management

Wie zuvor erwähnt, setzt AWS Outposts zwingend die von AWS bereitgestellte Hardware voraus. Dieser Nachteil wird jedoch – je nach Sichtweise – durch das zugehörige Management-Modell kompensiert, da die komplette Installation des Systems und das Management der Hybrid-Cloud-Infrastruktur vollständig durch AWS erbracht werden.

Im Gegensatz dazu obliegt das Hardware-Management bei Google Anthos und den beiden Varianten von Azure Stack – Azure Stack Hub und Azure Stack HCI – jeweils dem Anwender.

Unterstützte Cloud Services

Hier dürfte wohl der größte Unterschied zwischen den drei Angeboten liegen.

Obwohl AWS Outposts und Azure Stack eine große Vielzahl ihrer jeweiligen Services aus dem Portfolio ihrer Cloud-Angebote, wie z.B. cloudbasierte VMs und Datenbanken, in das Kunden-RZ bringen, bietet Azure Stack ein etwas breiteres Angebot. Beispiel hierfür ist der Dienst Azure Functions – Microsoft’s Dienst für das Serverless Computing. AWS Lamda – das Pendant von AWS – wird auf Outposts nicht unterstützt.

Deutlich hiervon unterscheidet sich Google Anthos. Die Grundlage für diese Lösung basiert auf Kubernetes und bildet damit eine Ebene für ein zentralisiertes Deployment und einheitliche Verwaltung von Workloads über heterogene (Cloud-)Infrastrukturen hinweg. Auf dieser Basis können OnPrem-Infrastrukturen mit Cloud-Angeboten auch unterschiedlicher Anbieter integriert und verwaltet werden. Das bedeutet, dass Google Anthos die Google Cloud Platform (GCP) im Gegensatz zu Azure und AWS nicht in diesem Sinne in das Kunden-RZ bringt, sondern auf Basis von Kubernetes die Integration unterschiedlichster Infrastrukturen erreicht.

Unterstützung von Multi-Cloud-Angeboten und Anbieter-Unabhängigkeit

Da Google Anthos im Kern auf Kubernetes basiert, kann diese Lösung gleichzeitig unterschiedliche Cloud-Angebote unterstützen und ist damit nicht zwingend an die Google Cloud Platform gebunden.
Dies ist ein wesentliches Unterscheidungsmerkmal gegenüber AWS Outposts und Azure Stack, die jeweils keine Multi-Cloud-Unterstützung mitbringen, sondern lediglich mit den eigenen Services kompatibel sind. AWS und Azure sind darüber hinaus untereinander nicht kompatibel, wodurch die Migration von Workloads von einem zum anderen Anbieter erheblich erschwert wird. Hier hat Google Anthos aufgrund des Kubernetes-basierten Ansatzes einen klaren Vorteil.

Auf der anderen Seite sind die Einführung von Google Anthos und der Aufbau von entsprechendem Know-how unter Umständen mit deutlich größeren Aufwänden verbunden.

Fazit

Alle drei großen Cloud-Anbieter haben Lösungen in ihrem Portfolio, die den Aufbau und den Betrieb einer modernen Hybrid Cloud deutlich vereinfachen. Mit diesen Lösungen eröffnen sich je nach Anwendungsfall neue Möglichkeiten, um Workloads, die z.B. aus technischen Gründen oder spezifischen Anforderungen an Compliance und Datenschutz als nicht cloudfähig klassifiziert wurden, in die Cloud zu verlagern und deren unumstrittenen Vorteil zu nutzen. Gleichzeitig können die beschriebenen Lösungen auch bei der Migration dieser Workloads unterstützen.

Selbst wenn alle Anbieter vergleichbare Ziele und (mehr oder weniger) ähnliche Ansätze verfolgen, kann nicht klar und eindeutig gesagt werden, welche Lösung die geeignetste ist. Dies ist immer vom konkreten Einzelfall abhängig und muss dementsprechend individuell betrachtet und bewertet werden.
Hier ein paar Beispiele für Fragen, die in diesem Zusammenhang zu stellen sind:

• Welche Workloads können in die Cloud verlagert werden und welche müssen OnPrem bleiben?
• Sind mit der Auslagerung von Workloads in die Cloud kommerzielle oder operative Vorteile verbunden?
• Steht der Aufwand für die Auslagerung in Relation zu potenziellen Kosteneinsparungen?
• Werden bereits Services aus der Cloud genutzt?
• Wenn ja, welche genau?
• Wie sollen und können die Cloud Services mit den OnPrem-Workloads integriert werden?
• Wie sind die Kommunikationsbeziehungen der Workloads untereinander?
• Wie sieht die Anbindung an die Cloud konkret aus? (Eine Frage, die in diesem Artikel gar nicht behandelt wird, aber dennoch außerordentlich wichtig ist.)

Die Aufzählung dieser Fragen ist weit davon entfernt, vollständig zu sein, stellt jedoch auch nicht den Anspruch auf Vollständigkeit. Sie soll lediglich einen Hinweis darauf geben, dass mit der Einführung von Cloud Services und der potenziellen Auslagerung von OnPrem-Workloads eine ausführliche und durchaus aufwändige Analyse der individuellen Infrastruktur und der konkreten Anforderungen unverzichtbar ist, um den optimalen Nutzen daraus zu ziehen.