MultiCloud-Anbindung – Herausforderungen und Lösungsansätze

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.

Nach Erfahrungen des Projektgeschäftes von ComConsult ist mittlerweile nicht nur der Einsatz von Cloud-Lösungen klar und deutlich erkennbar. Es ist darüber hinaus eindeutig festzustellen, dass ein Cloud-Anbieter in der Regel nicht alle Anforderungen erfüllen kann. Insofern wundert es nicht, dass Unternehmen in zunehmendem Maße mehrere und unterschiedliche Cloud-Angebote nutzen, um die jeweiligen Workloads optimal zu verteilen.

Dieser deutlich erkennbare Trend wirft gleichzeitig automatisch Fragen hinsichtlich der Anbindung und der Integration mehrerer Cloud-Provider auf.

Der vorliegende Artikel greift diese Fragen auf und skizziert mögliche Lösungsansätze, mit denen man den Herausforderungen, die sich automatisch aus der gleichzeitigen Nutzung mehrerer Clouds ergeben, begegnen kann.

Die schlechte Nachricht vorab – und das sei schon vorweggenommen: Es gibt keine „One-Size-Fits-All“-Lösung – in diesem Kontext könnte man auch sagen „One Cloud Fits All“ – zumal sich in der Regel die Ausgangsvoraussetzungen individuell und je nach Anwendungsfall unterscheiden. Doch auch wachsende Sicherheitsbedenken und strengere Compliance-Vorschriften beeinflussen die zunehmende Nutzung von Hybrid- und Multi-Cloud-Lösungen. Anstatt alle Daten und Anwendungen in die Public Cloud zu migrieren, ziehen es einige Unternehmen deshalb vor (oder sind sogar verpflichtet), einige Daten OnPrem in der eigenen Umgebung zu halten, um das Risiko von Verstößen gegen Sicherheits- und Compliance-Anforderungen zu verringern oder einfach nur, um konkrete Kundenanforderungen zu erfüllen.

Andere wiederum versprechen sich zusätzlich, das Risiko eines „Vendor-Lock-Ins“ zu minimieren, Kosten zu reduzieren und es zu vereinfachen, innovativ und flexibel zu bleiben, indem sie nur die besten Funktionen jedes Cloud-Anbieters nutzen.

Doch trotz all dieser Vorteile kann die Einrichtung und Nutzung mehrerer Umgebungen die Komplexität insgesamt erhöhen und zu neuen Problemen im täglichen Betrieb und dem Management führen.

Wir wollen zunächst den Unterschied zwischen dem Hybrid- und dem Multi-Cloud-Modell herausarbeiten:

Hybrid Cloud

Beim Hybrid-Cloud-Modell betreibt ein Unternehmen seine Anwendungen zunächst OnPrem im eigenen Rechenzentrum oder in einer Private Cloud und einige in einer oder mehreren Public Clouds. Eine Kommunikationsbeziehung besteht höchstens zwischen dem eigenen RZ (respektive Private Cloud) und der jeweiligen Anwendung in der Public Cloud. Die Abbildung 1 soll dies schematisch veranschaulichen.

In diesem Modell können die mit X, Y und Z bezeichneten Anwendungen jeweils auf einem SaaS-, IaaS- oder PaaS-Angebot des jeweiligen Cloud-Providers basieren. Die Anbindung erfolgt auf Basis der gängigen Anbindungsvarianten, wie z.B. über Internet oder Direktanschlussmöglichkeiten, die vom jeweiligen Cloud-Provider angeboten werden (z.B. MS Azure ExpressRoute oder AWS Direct Connect).

Entscheidend und typisch ist, dass es keine Cloud-übergreifenden Kommunikationsbeziehungen zwischen den Anwendungen in der/den Public Cloud(s) gibt.

Multi-Cloud

In einer Multi-Cloud-Umgebung hingegen werden einzelne Workloads zwar auch in mehreren Clouds betrieben, doch ist es möglich, einzelne Teile einer Applikation in unterschiedlichen Clouds zu betreiben und damit monolithische Anwendungen in einzelne Microservices aufzuteilen und diese in der jeweils am besten geeigneten Cloud bereitzustellen.

Somit ergeben sich automatisch neue Kommunikationsbeziehungen, die Cloud-übergreifende, performante Verbindungen dazwischen erforderlich machen.

Die Abbildung 2 soll dies systematisch anhand der Anwendung X mit den verteilten Microservices A, B und C darstellen.

Die physikalische Konnektivität zwischen den einzelnen Microservices kann zunächst auch hier über die zuvor genannten gängigen Anbindungsvarianten und zusätzlich mittels eines entsprechenden Routings hergestellt werden. Dabei ist jedoch zu berücksichtigen, dass sämtlicher Datenverkehr über das eigene Rechenzentrum (oder die Private Cloud) ausgetauscht wird. Dies kann wiederum die Anforderungen an die Kapazität der eigenen RZ-Anbindung erhöhen und aufgrund von Latenzen und ggf. Paketverlustraten die Performanz einer derartig verteilten Anwendung nachhaltig negativ beeinflussen.

Lösungsansatz

Die meisten WAN- und Internet-Carrier, doch mittlerweile auch eine Vielzahl unabhängiger Anbieter – nennen wir sie zusammengefasst „Cloud Management Service Provider“ (CMSP) – bieten einen zentralen und performanten Übergang zu den unterschiedlichen Cloud-Service-Providern (CSP) an, der in vielen Fällen unter dem Produktnamen “Cloud Connect“ vertrieben wird.

Der Kern dieses Ansatzes ist, dass diese Anbieter selbst über performante Übergänge zu den CSPs und einem entsprechend ausgelegten Backbone verfügen.

Die Architektur dieses Lösungsansatzes wird in der nachfolgenden Abbildung schematisch dargestellt (zur besseren Übersicht wird in der Abbildung 3 auf die Darstellung der Private Cloud verzichtet).

Hier kann ebenfalls die Konnektivität zum Cloud Management Service Provider (via dessen Co-Location) über die gängigen Anbindungsvarianten via Internet (und z.B. IPSec-VPN) oder über MPLS zum eigentlichen Cloud-Connect-Service hergestellt werden. Faktisch kann dadurch die Co-Location des CMSPs und dessen Service als weiterer Standort des Unternehmen-WANs betrachtet werden.

Hinsichtlich Performanz, Bandbreite, Paketverlustraten und anderer Netzgüteparameter zwischen den einzelnen Cloud-Anbietern machen die jeweiligen CMSPs in der Regel keine konkreten Angaben oder sichern gar entsprechende SLAs zu. Stattdessen verweisen sie typischerweise auf die generell hohe Performanz ihres eigenen Backbones und der Anbindungen an die einzelnen Cloud-Provider (rechte Seite der Skizze).

Wie bereits erwähnt kann die Konnektivität zum CMSP über die gängigen Anbindungsvarianten erfolgen. Der Vorteil einer MPLS-basierten Anbindung besteht darin, dass auf der Verbindungsstrecke zwischen dem Unternehmen und dem CMSP (linke Hälfte der Skizze) auch SLA-basierende Netzgüteparameter im Sinne von QoS zur Verfügung gestellt werden können, was im jeweils konkreten Fall durchaus erforderlich sein kann, um die Ende-zu-Ende-Performanz sicherstellen zu können.

Management einer Multi-Cloud-Umgebung

Die zuvor aufgezeigten Szenarien mögen dem Leser dieses Artikels die zusätzliche Komplexität, die mit dem Einsatz einer Multi-Cloud einhergeht, veranschaulichen.

Diese kommt nicht nur von den unterschiedlichen Anbindungen auf der Ebene des Netzwerkes zustande, sondern auch weil sich die Administrationstools der einzelnen Cloud-Anbieter teilweise erheblich unterscheiden. Das wiederum erfordert Cloud-spezifisches Know-how seitens der Administratoren, welches oftmals erst einmal erarbeitet, künftig aufrechterhalten und stets weiterentwickelt werden muss.

Um die Vorteile einer Multi-Cloud-Umgebung dennoch effizient nutzen zu können, bedarf es deshalb einer Lösung zur Cloud-übergreifenden Vereinheitlichung des Managements.

Eine Möglichkeit dieser Herausforderung zu begegnen, besteht darin, einen auf diese Aufgabenstellung spezialisierten Dienstleister zu beauftragen. Dieser kann (und soll), auf Basis fest vereinbarter SLAs, notwendige Änderungen an der Gesamtkonstellation der Multi-Cloud-Infrastruktur durchführen. Es gibt mittlerweile eine ganze Reihe von Unternehmen, die sich teilweise als Start-Ups auf dieses Geschäftsmodell spezialisiert haben.

Eine weitere Variante ist die Nutzung der oben genannten und beschriebenen Cloud-Connect-Services eines Carriers oder eines weiteren Dienstleisters, die jedoch „nur“ die Inter-Cloud-Konnektivität herstellen. In diesem Fall verbleibt jedoch i.d.R. immer noch der administrative Aufwand beim Auftraggeber, z.B. in Zusammenhang mit der Bereitstellung weiterer Ressourcen in der jeweiligen Cloud.

Die letzte Variante, die hier im Rahmen dieses Artikels betrachtet werden soll, ist der vollständige Eigenbetrieb der Multi-Cloud-Umgebung. Aus den vorherigen Abschnitten geht hervor, dass diese Variante mit den größten Aufwänden verbunden ist. Dies gilt insbesondere auch mit Hinblick auf das Vorhalten von Personal und entsprechendem Know-how, was sehr kostenintensiv sein und die mit der Multi-Cloud-Umgebung erhofften Kosteneinsparungen vernichten kann.

Dennoch haben die drei großen Cloud-Service-Provider AWS, MS Azure und Google Cloud Platform diese Herausforderung erkannt und bieten seit geraumer Zeit entsprechende Lösungen zum vereinheitlichten und Cloud-übergreifenden Management auf ihren Plattformen an. Diese sollen nachfolgend kurz beschrieben und deren Unterschiede zueinander herausgearbeitet werden.

AWS zielte mit seinem Cloud-Angebot schon immer darauf, sämtliche Workloads samt ihrer Verwaltung in deren Cloud zu transferieren. Infolgedessen förderte die Cloud-Plattform einen reinen Public-Cloud-Ansatz und widmete ihre Ressourcen der Unterstützung von Unternehmen bei der Migration in die Public Cloud. Die effiziente Unterstützung eines Hybrid-Cloud-Ansatzes stand dabei also nicht unbedingt im Vordergrund. Insofern war die Ankündigung von AWS Outposts auf der re:Invent 2018 eine große Überraschung.

Anfang 2019 sorgten die beiden anderen großen Cloud-Anbieter – MS Azure und Google – mit der Ankündigung von Google Cloud Anthos und MS ARC für Schlagzeilen. Beide Lösungen richten sich an Unternehmen, die den Hybrid- oder Multi-Cloud-Ansatz verfolgen.

Doch was sind die Gemeinsamkeiten und Unterschiede der jeweiligen Angebote?

AWS Outposts

Das Konzept von AWS Outposts, das sich primär an Unternehmen mit Hybrid-Cloud-Architekturen richtet, ist ziemlich einfach. Der Service ermöglicht es Kunden, AWS-Compute- und Storage-Services (AWS EC2 und EBS) in ihren eigenen Rechenzentren zu verwenden, jedoch auf Basis und mittels Integration der von AWS bereitgestellten Hardware. Diese Lösung richtet sich demnach in erster Linie an Unternehmen, die die Nutzung von Ressourcen im eigenen RZ (respektive Private Cloud) und AWS erleichtern möchten.

MS Azure Arc

Mit Microsoft Azure Arc können Unternehmen die Verwendung verschiedener Umgebungen vereinfachen, indem sie die Azure-Verwaltungsfunktionen Cloud-übergreifend auf jede Infrastruktur erweitern, unabhängig von ihrem Standort. Durch die Verwendung von Kubernetes bietet Azure Arc die Möglichkeit, containerbasierte Anwendungen bereitzustellen und zu verwalten. Azure Arc kann dabei auch andere Arten von Ressourcen organisieren, z.B. Windows- und Linux-Dienste.

Google Cloud Anthos

Mit Google Cloud Anthos können Unternehmen ihre vorhandenen OnPrem- oder Public-Cloud-Investitionen nutzen, indem sie ihre Anwendungen modernisieren und überall ausführen können. Im Kern nutzt Anthos die Google Kubernetes Engine (GKE) und andere bestehende GCP-Dienste, um einen einfachen Hybridpfad und eine vertraute Entwicklungserfahrung für Engineering-Teams bereitzustellen, die bereits Google Cloud verwenden.

Gemeinsamkeiten und Unterschiede

Google Cloud Anthos und Microsoft Azure Arc haben aus technischer Sicht ziemlich ähnliche Ansätze.

Beide nutzen Kubernetes und Container, um überall ein nahtloses Erlebnis zu bieten – vor Ort, in ihrer eigenen Public-Cloud-Plattform oder in der Cloud des jeweiligen Mitbewerbers.

AWS Outposts hingegen konzentriert sich ausschließlich auf die lokalen Anwendungsfälle.

Darüber hinaus erschwert AWS Outposts durch die Verwendung von (proprietärer) Hardware, die von AWS selbst bereitgestellt wird, de facto Multi-Cloud-Szenarien und sogar die Verwendung der unternehmenseigenen Hardware. Letzteres kann für Unternehmen, die stark in ihre eigene Rechen- und Speicherhardware investiert haben, eine besondere Herausforderung darstellen, da sie diese wahrscheinlich nicht durch benutzerdefinierte AWS-Hardware ersetzen werden. Auch dies ist in Zusammenhang einer Multi-Cloud-Strategie genauer zu bewerten.

Für Unternehmen mit geringerem Hardware-Footprint, die lokale Workloads erfordern, können AWS Outposts jedoch die allgemeine Governance ihrer IT-Strategien vereinfachen, indem sie eine ganzheitliche Sicht und Verwaltung von Ressourcen bieten.

AWS Outposts dürfte deshalb vor allem für Unternehmen infrage kommen, die sich vorrangig für AWS als Cloud-Service-Provider entschieden haben. Bei der Nutzung weiterer Clouds stellt sich dennoch die Frage der Integration dieser Dienste in die Gesamtinfrastruktur.

Doch was sind die Unterschiede zwischen den Angeboten der Cloud-Service-Provider?

AWS Outposts konzentriert sich – wie bereits erwähnt – in erster Linie auf die Cloud-Integration lokaler Ressourcen.

Die entsprechenden Angebote von Microsoft Azure und GCP erlauben hingegen eine Cloud-übergreifende Verwaltung der jeweiligen Ressourcen auf Basis von Kubernetes.

Während Kubernetes sowohl bei Microsoft Azure als auch bei Google Cloud Platform implementiert ist, ist seine Verwendung in Azure Arc optional, welches auch Edge-Computing-Umgebungen unterstützt, die es Kunden ermöglichen, sie in jeder Infrastruktur bereitzustellen.

In GCP Anthos ist Kubernetes ein Kernbestandteil des Tools. Es geht sogar so weit, zusätzliche Tools für die Konvertierung virtueller und Bare-Metal-Workloads in Container bereitzustellen. Dadurch können diese Workloads in der Google Kubernetes Engine und damit auf Anthos ausgeführt werden.

Fazit

Dieser Artikel hat einige Vor- und Nachteile bei der Nutzung einer Multi-Cloud-Umgebung aufgegriffen, wobei, um den Rahmen dieses Artikels nicht zu sprengen, bei weitem nicht alle Aspekte abgedeckt werden konnten. Beispiele hierfür seien u.a. die Auswirkungen auf die Anwendungsentwicklung und die Kooperation zwischen Software-Architekten und den Netzwerkadministratoren eines Unternehmens.

Dieser gesamte Themenkomplex wird jedoch in weiteren Artikeln dieser Reihe aufgegriffen werden, wobei der Begriff „komplex“ es hier sehr gut trifft, weil er die Komplexität des Themas und den damit verbundenen Fragestellungen aus Sicht des Autors widerspiegelt.