So entwerfen Sie eine Hybrid Cloud-Architektur

Der in der jüngsten Vergangenheit verfolgte Hybrid-Cloud-Ansatz umfasste in der Regel die Migration einiger Dienste von der lokalen Infrastruktur in eine Public oder Private Cloud, die miteinander kommunizieren. Selbst wenn eine neue Anwendung für das Hosten in einer Public Cloud entwickelt wurde, hielt sie sich an eine traditionelle serviceorientierte Architektur (SOA).

Heute bildet die auf Microservices basierende Architektur jedoch den Kern des Hybrid-Cloud-Modells. Microservices sind ein Ansatz, bei dem eine Anwendung zur einfachen Bereitstellung in kleinere Komponenten oder Dienste aufgeteilt wird. Diese Microservices unterscheiden sich von den Diensten in einer SOA dadurch, dass sie über einen eigenen Stack verfügen und in Containern bereitgestellt werden. Dabei handelt es sich um schlanke, ausführbare Dateien, die den Microservice und seine abhängigen Bibliotheken enthalten.

Container sind leichtgewichtig, weil sie den Betriebssystem-Kernel der Maschine teilen, was bedeutet, dass jeder Container nur den Microservice und seine Abhängigkeiten enthält. Alle Betriebssystemabhängigkeiten werden von der Hardware gemeinsam genutzt, in der sich der Container befindet. Durch diese Virtualisierung können Microservices unabhängig in jeder On-Premises- oder Cloud-Umgebung bereitgestellt werden. Durch diese Autarkie unterscheiden sich Microservices stark von einer SOA und eignen sich besser für die Cloud-Bereitstellung, bei der Elastizität und Flexibilität zur Optimierung der Cloud-Ressourcen von größter Bedeutung sind.

Containerisierung als Verpackungsmodell zur Isolierung von Prozessen in jeder Umgebung ist kein neues Konzept, aber die Einführung von Docker im Jahr 2013 als Container-Engine hat eine universelle Verpackungsstruktur geschaffen. Darüber hinaus automatisiert eine Container-Orchestrierungsplattform wie Kubernetes die Bereitstellung von Docker – oder jedem anderen Container, der den Standards der Open Container Initiative (OCI) entspricht – in Hybrid-Cloud-Umgebungen.

Die Einführung der Containerisierung hat dazu beigetragen, die Nutzen der Hybrid Cloud wirklich zu nutzen, wobei sich der Schwerpunkt hin zur einfachen Portierbarkeit von Workloads und der automatischen Bereitstellung von Diensten in der Cloudumgebung Ihrer Wahl verlagert hat.

Vor ein paar Jahren drehten sich die wichtigsten Fragen in einer Diskussion über Hybrid-Cloud-Architekturen darum, in welcher Cloud- oder On-Premises-Umgebung die einzelnen Workloads ausgeführt werden sollten und wie diese verschiedenen Umgebungen miteinander kommunizieren können. Im Wesentlichen blieben der Hosting-Standort und die physische Konnektivität die wichtigsten Überlegungen.

Zum Beispiel würde eine Anwendung, die mit sensiblen Daten arbeitet, in einer Private Cloud gehostet werden. Oder eine Altlast-App, die schwer zu modernisieren ist, würde lokal weiterhin fortbestehen. In der Zwischenzeit würden die Unternehmen die Apps, die Skalierbarkeit benötigen, in die Public Cloud verlagern. Dann würden sie Kanäle wie VPN-Tunnel (Virtual Private Network) oder Nachrichtenströme einrichten, um die Kommunikation zwischen Umgebungen zu erleichtern.

Diese sind nach wie vor wichtige Faktoren, die es zu berücksichtigen gilt. Mit dem Paradigma der Containerisierung hat sich jedoch der Schwerpunkt von physischem Standort und Konnektivität zu Flexibilität verlagert. Dadurch können Workloads nahtlos von einer Umgebung in eine andere verlagert werden. Ob eine Anwendung in einer Private Cloud oder in einer Public Cloud gehostet werden soll, muss also keine starre Entscheidung sein. Wenn die Strategie nicht funktioniert, ist es einfach, Workloads, die in Containern verpackt sind, zwischen Umgebungen zu verschieben, nach oben und unten zu skalieren und sogar Instanzen desselben Dienstes in verschiedenen Umgebungen auszuführen.

All dies hat zu einer modernen, hochverfügbaren und flexiblen Architektur geführt, die hohe Leistung, Ressourceneffizienz und Kosteneinsparungen bietet.

Bei der Planung und Implementierung einer Hybrid-Cloud-Architektur müssen viele Faktoren berücksichtigt werden, darunter die Geschäftsziele eines Unternehmens, seine aktuelle technologische Landschaft, die Ziele der digitalen Transformation und Sicherheitsaspekte. Da eine solche Architektur mit mehreren Hybrid-Cloud-Lösungen sehr schnell komplex werden kann, ist es wichtig, Betriebstools zu nutzen, um ein zentralisiertes, nahtloses und skalierbares Cloud-Management für die Hybrid Cloud zu gewährleisten. Hier sind einige Faktoren, die bei der Entwicklung einer Hybrid-Cloud-Strategie zu berücksichtigen sind.

Modernisierungsstrategie

Für die meisten Unternehmen beginnt die Idee des Hybrid Cloud Computing mit der Modernisierung oder der Verlagerung ihrer Anwendungen von lokalen Systemen in die Cloud. Es gibt mehrere Möglichkeiten, dies umzusetzen:

• Lift-and-Shift: Eine der gängigsten Methoden, um die Modernisierung in Gang zu bringen, ist die Verlagerung der kompletten Anwendung in die Cloud. Dazu gehört der Wechsel der zugrunde liegenden Hardware, um von den Vorteilen der sicheren und skalierbaren Cloud-Computing-Ressourcen und Infrastrukturservices zu profitieren. Dies ist eine praktische Option, wenn die Zeit für eine Umstrukturierung oder Neuarchitektur nicht ausreicht.
• Refaktorierung: Anstatt die komplette monolithische Anwendung in die Cloud zu verlagern, was nicht nur zeitaufwändig, sondern auch unnötig sein kann, ist es besser, ein oder zwei Dienste zu identifizieren, die keinen Compliance- oder dringenden Bedarf an Leistungsverbesserung haben, und sie zu überarbeiten. Beispielsweise kann Glue-Code hinzugefügt werden, um REST-APIs verfügbar zu machen, da die bisherigen Serviceschnittstellen eng mit der jeweiligen Plattform verbunden waren. Anschließend erfolgt die Bereitstellung in der Cloud. Diese schrittweise Verschiebung bietet die Möglichkeit, einen kleinen Teil des Datenverkehrs an neue Instanzen in der Cloud weiterzuleiten, um Test- und Lernmöglichkeiten zu nutzen, und schließlich alle Instanzen des Dienstes in die Cloud zu verlagern.
• Neugestaltung: Schließlich gibt es noch den anspruchsvollsten Ansatz, alle Systemkomponenten in modulare Microservices mit jeweils nur einer Aufgabe aufzuteilen, die unabhängig voneinander in Produktion gehen können, und sie zu containerisieren. Dies erfordert eine komplette Neufassung und ist ein teurer Prozess, maximiert aber auch die Renditen.

Einheitliche Steuerungsebene

Unternehmenseinheiten verwalten ihre Cloud-Geschäftswelt über eine einheitliche Steuerungsebene. Diese ermöglicht eine zusammenhängende und konsistente Cloud-Erfahrung in allen Umgebungen. Sie unterstützt Kern-Cluster-Managementfunktionen wie Workload-Planung und -Orchestrierung, Continuous Integration und Bereitstellung (CI/CD)-Pipelines, Protokollierung, Telemetrie und Verbundsicherheit.

Das Ziel besteht darin, die zugrunde liegenden Komplexitäten der einzelnen Cloud-Service-Anbieter (CSPs) sowie die Laufzeiten der Anwendungen zu abstrahieren und den Betriebsteams eine gemeinsame Schnittstelle zur Verwaltung der Workloads im Unternehmen zur Verfügung zu stellen. 

Hier sind einige der Vorteile einer einheitlichen Steuerungsebene:

• Nutzen Sie dynamische Strategien für die Workload-Platzierung auf virtuellen Maschinen, in Containern oder in serverlosen Bereitstellungen.
• Genießen Sie die Möglichkeit, mit minimalem Aufwand zusätzliche Anbieter oder Edge-Standorte einzuführen.
• Erstellen Sie PaaS-Funktionen wie Function-as-a-Service (FaaS), die hochverfügbar sind und in verschiedenen Cloud-Implementierungen eingesetzt werden können.
• Zentralisieren Sie das Compliance-Management.

API Gateway und Service Mesh

Architekturmuster wie zentralisierte API Gateways und Service Mesh ermöglichen eine transparente Verwaltung von Cloud-Funktionen wie Routing, Dienst-zu-Dienst-Kommunikation, Sicherheit, Ratenbegrenzung und Observability.

Das API Gateway fungiert als einheitliche Eingangstür in allen Regionen und ist für die Abwicklung des „Nord-Süd“-Verkehrs verantwortlich. Dazu gehören unter anderem die folgenden Bereiche:

• Benutzerauthentifizierung und -autorisierung
• Drosselung und Ratenbegrenzung
• Datenverkehrsmanagement
• API-Lebenszyklusmanagement
• Sicherheitsbarrieren für die Cloud
• Edge Analytics

Das Service Mesh hingegen verarbeitet den „Ost-West“-Verkehr zwischen Service-Abhängigkeiten:

• Sichere Dienst-zu-Dienst-Kommunikation in einem Cluster
• Datenverkehrsmanagement mit Lastverteilung, Routing-Regeln, Neuversuchen, Failover, Notfallwiederherstellung und Fehlerinjektion
• Telemetrie mit Metriken, Protokollen und Traces für den gesamten Datenverkehr innerhalb eines Clusters, einschließlich Cluster-Egress und -Ingress
• Verteilte Rückverfolgbarkeit, um den Fluss einer Anfrage über Dienstgrenzen hinweg zu instrumentieren
• Automatisierte Erkennung von Diensten

Istio ist zum Beispiel eine Open-Source-Service-Mesh-Ebene, die die Kommunikation zwischen Diensten gemäß einer vordefinierten Konfiguration steuert, die von Cloud-Administratoren bereitgestellt wird. Sie fungiert als Sidecar zur Kubernetes-Orchestrierungsschicht und arbeitet mit Containern, unsichtbar für Programmierer und Administratoren.

Sicherheit

Die Komplexität der Hybrid-Cloud-Architektur erfordert einen mehrstufigen Ansatz auf verschiedenen Ebenen, um Sicherheit und Schutz von Anfang bis Ende zu gewährleisten. 

Cloud-Service-Provider wie IBM Cloud, Amazon Web Services (AWS), Microsoft Azure und Google Cloud sind gemäß Service Level Agreements (SLAs) dafür verantwortlich, alle Aufrufe auf der Perimeterebene zu authentifizieren und zu autorisieren und so eine Firewall um Unternehmensanwendungen aufzubauen. Dazu gehören der Schutz vor Denial-of-Service und die Einhaltung von Datenschutzbestimmungen wie der Datenschutz-Grundverordnung (DSGVO) und dem Health Insurance Portability and Accountability Act (HIPAA).

In einer lokalen Infrastruktur kann die Perimetersicherheit mithilfe von API Gateways erreicht werden, die alle Endgeräte schützen. Jeder Aufruf von einem Web-Service oder einer mobilen Anwendung, die sich außerhalb eines Rechenzentrums befindet, muss validiert und über das API Gateway weitergeleitet werden.

Eine Cloud-Computing-Umgebung enthält eine zusätzliche Sicherheitsebene in Form von Kontrollrichtlinien, die im Service Mesh definiert sind, und APIs, die von der Orchestrierungsplattform bereitgestellt werden. Diese Richtlinien stellen sicher, dass nur sichere Aufrufe an die Kubernetes-Knoten und von dort an die Microservices weitergeleitet werden.

Außerdem kann das Konzept der Mikrosegmentierung, bei dem die Umgebung in verschiedene logische Sicherheitssegmente unterteilt wird, um Zugriffskontrollrichtlinien für jeden Dienst und Workload zu definieren, verwendet werden, um Sicherheitsebenen zwischen den in einer Umgebung laufenden Dienste zu erstellen und abzugrenzen. Und schließlich dient die Verschlüsselung als zusätzliche Ebene des Datenschutzes.

Netzwerkkonnektivität

In einer einzigen Cloud-Region verfügen die Verfügbarkeitszonen über ein dediziertes Glasfasernetzwerk, das alle Knoten in einem Netzwerk verbindet, wodurch Unternehmen hochverfügbare Architekturen mit unbegrenzter Bandbreite und geringen Latenzen erstellen können. Die Kommunikation zwischen Regionen und mehreren Cloud-Providern wird jedoch über das öffentliche Internet geleitet und ist mit hoher Latenzzeit und potenziellen Ausfällen verbunden.

In einer Hybrid Cloud-Architektur gibt es drei Muster für den Datenaustausch zwischen den zugrunde liegenden Anbietern:

• Öffentliche IP-Adressen über das Internet (hohe Latenzzeit aufgrund gemeinsamer Bandbreite)
• Verwaltete Services wie VPN (vorhersehbarere Latenz mit höherer Sicherheit)
• Dedizierte Verbindung über gemeinsame Präsenzpunkte (POPs) (eine kostspielige Option, die von CSPs angeboten wird, jedoch die geringste Latenz bei maximaler Sicherheit bietet)

Da sich diese Optionen in Bezug auf Übertragungsgeschwindigkeit, Latenz, Zuverlässigkeit, SLAs, Komplexität und Preisgestaltung unterscheiden, ist es wichtig, die Einschränkungen und Nutzen abzuwägen, bevor Sie die Netzwerkkonnektivitätsschicht entwerfen.

Verzerrung für Open Source in Entwicklungsplattformen

Eine Hybrid Cloud bietet die Möglichkeit, Workloads von einer Umgebung in eine andere zu verlagern. Zudem stellt sie eine Plattform für die Anwendungsentwicklung bereit, die in jeder Cloud läuft. Um wirklich cloudnativ zu sein, sollte es keine starke Abhängigkeit von einer bestimmten Technologie, Plattform oder sogar CSP geben und die Unternehmen sollten schnell auf Marktveränderungen reagieren.

Eine Open-Source-Architektur ermöglicht diesen einheitlichen Entwicklungsansatz, bei dem es den Entwicklern möglich wird, ihre zugrunde liegende Infrastruktur unabhängig von der für die Implementierung verwendeten Technologie zu verwalten. Open Source steht nicht mehr am Rande der Entwicklung und hat nicht mehr nur eine Zielgruppe, die es aus Kostengründen nutzt. Aufgrund seiner umfangreichen Funktionen, seiner Qualität und seiner communitybasierten Entwicklung ist es heute Mainstream und hat den Mittelpunkt des Interesses eingenommen.

Selbst in einem sensiblen Bereich wie der Sicherheit wird Open-Source-Software heute als eine gute Wahl angesehen, wie aus dem Red Hat Report on The State of Enterprise Open Source hervorgeht. Sicherheit, Qualität und Unterstützung einer cloudnativen Architektur sind die Hauptgründe, warum Unternehmen sich bewusst für Open Source entscheiden.

Weitere Informationen finden Sie in JJ Asghars Artikel Cultivating Careers, Communities and Companies with Open Source.

Die Hybrid-Cloud-Lösungen von IBM® Cloud bieten Flexibilität und Portabilität für Anwendungen und Daten. Linux, Kubernetes und Container unterstützen den Hybrid-Cloud-Stack und schaffen in Kombination mit Red Hat OpenShift eine gemeinsame Plattform, die On-Premises- und Cloudressourcen miteinander verbindet.

Erfahren Sie mehr über die mit IBM Cloud entwickelten Hybrid-Cloud-Lösungen.

Um mit dem Aufbau Ihrer eigenen Hybrid-Cloud-Lösungen zu beginnen, registrieren Sie sich für eine IBMid und erstellen Sie Ihr IBM Cloud-Konto.