Umgebungshybridmuster

Mit dem Umgebungshybrid-Architekturmuster behalten Sie die Produktionsumgebung einer Arbeitslast im vorhandenen Rechenzentrum. Sie verwenden die öffentliche Cloud dann für Ihre Entwicklungs- und Testumgebungen oder andere Umgebungen. Dieses Muster basiert auf der redundanten Bereitstellung derselben Anwendungen in mehreren Rechenumgebungen. Ziel der Bereitstellung ist es, die Kapazität, Agilität und Ausfallsicherheit zu erhöhen.

Wenn Sie die Arbeitslasten festlegen, die migriert werden sollen, stoßen Sie eventuell auf bestimmte Anwendungen, deren Ausführung in der öffentlichen Cloud Probleme mit sich bringt.

• Rechtliche oder behördliche Auflagen können dafür verantwortlich sein, dass Daten in einem bestimmten Land verbleiben müssen.
• Lizenzbestimmungen von Drittanbietern untersagen möglicherweise die Ausführung bestimmter Software in einer Cloudumgebung.
• Eine Anwendung benötigt möglicherweise Zugriff auf Hardwaregeräte, die nur lokal verfügbar sind.

Berücksichtigen Sie in solchen Fällen nicht nur die Produktionsumgebung, sondern alle Umgebungen, die zum Lebenszyklus einer Anwendung gehören, einschließlich Entwicklungs-, Test- und Staging-Systeme. Diese Einschränkungen gelten häufig für Produktionsumgebung und ihre Daten. Sie gelten möglicherweise nicht für andere Umgebungen, in denen die eigentlichen Daten nicht verwendet werden. Wenden Sie sich an die Compliance-Abteilung Ihrer Organisation oder an das entsprechende Team.

Das folgende Diagramm zeigt ein typisches Umgebungshybrid-Architekturmuster.

Das Ausführen von Entwicklungs- und Testsystemen in anderen Umgebungen als die der Produktionssysteme kann riskant erscheinen und von Ihren bestehenden Best Practices oder Ihren Bemühungen abweichen, Unterschiede zwischen Ihren Umgebungen zu minimieren. Solche Bedenken sind zwar berechtigt, können aber ausgeräumt werden, wenn Sie zwischen den Phasen der Entwicklungs- und Testprozesse unterscheiden:

Die Entwicklungs-, Test- und Bereitstellungsprozesse variieren zwar von Anwendung zu Anwendung, setzen sich jedoch mehr oder weniger aus folgenden Phasen zusammen:

• Entwicklung: Releasekandidaten erstellen
• Funktions- oder Nutzerakzeptanztests: Prüfen, ob der Releasekandidat die funktionalen Anforderungen erfüllt.
• Leistungs- und Zuverlässigkeitstests: Prüfen, ob der Releasekandidat die nicht funktionalen Anforderungen erfüllt Dieser Test wird auch als Lasttest bezeichnet.
• Staging- oder Bereitstellungstests: Prüfen, ob das Bereitstellungsverfahren funktioniert.
• Produktion: Freigabe neuer oder aktualisierter Anwendungen.

Da die Ausführung mehrerer dieser Phasen in einer einzigen Umgebung selten praktikabel ist, erfordert jede Phase normalerweise eine oder mehrere dedizierte Umgebungen.

Der Hauptzweck einer Testumgebung besteht jedoch in der Ausführung von Funktionstests, Der Hauptzweck einer Staging-Umgebung besteht darin, zu testen, ob die Bereitstellungsverfahren Ihrer Anwendung wie vorgesehen funktionieren. Wenn ein Release eine Staging-Umgebung erreicht, sollten die Funktionstests abgeschlossen sein. Staging ist der letzte Schritt, bevor Sie Software in Ihrer Produktionsbereitstellung bereitstellen.

Damit Testergebnisse aussagekräftig und für die Produktionsbereitstellung gelten, müssen alle Umgebungen, die Sie während des gesamten Lebenszyklus einer Anwendung verwenden, folgenden Regeln so weit wie möglich entsprechen:

• Alle Umgebungen sind funktional äquivalent. Das bedeutet, dass Architektur, APIs und Versionen von Betriebssystemen sowie Bibliotheken äquivalent sind und die Systeme sich in allen Umgebungen gleich verhalten. Durch diese Äquivalenz lässt sich vermeiden, dass Anwendungen in einer Umgebung funktionieren, in einer anderen jedoch nicht, oder dass Fehler nicht reproduzierbar sind.
• Umgebungen, die für Leistungs- und Zuverlässigkeitstests, Staging und Produktion verwendet werden, sind funktionsunabhängig äquivalent. Das heißt, diese Umgebungen unterscheiden sich in puncto Leistung, Umfang, Konfiguration, Betrieb und Wartung nicht oder nur unwesentlich. Ansonsten sind Leistungs- und Staging-Tests bedeutungslos.

Im Allgemeinen ist es in Ordnung, wenn sich die für die Entwicklung und Funktionstests verwendeten Umgebungen auf funktionsunabhängiger Ebene von den anderen Umgebungen unterscheiden.

Wie im folgenden Diagramm dargestellt, basieren die Test- und Entwicklungsumgebungen auf Google Cloud. Eine verwaltete Datenbank wie Cloud SQL kann als Option für Entwicklung und Tests in Google Cloud verwendet werden. Entwicklung und Tests können dasselbe Datenbankmodul und dieselbe Version in der lokalen Umgebung verwenden, eine funktional äquivalente Version oder eine neue Version, die nach der Testphase in die Produktionsumgebung eingeführt wird. Da die zugrunde liegende Infrastruktur der beiden Umgebungen nicht identisch ist, ist dieser Ansatz für Leistungslasttests nicht gültig.

Die folgenden Szenarien passen gut zum Umgebungshybridmuster:

• Mit Kubernetes als gemeinsame Laufzeitebene, sofern möglich und sinnvoll, erreichen Sie eine funktionale Äquivalenz in allen Umgebungen. Die Google Kubernetes Engine (GKE) Enterprise-Version kann eine wichtige Technologie für diesen Ansatz sein.
  • Sorgen Sie für die Portabilität von Arbeitslasten und abstrahieren Sie Unterschiede zwischen Rechenumgebungen. Mit einem Zero-Trust-Service Mesh können Sie die erforderliche Kommunikationstrennung zwischen den verschiedenen Umgebungen kontrollieren und aufrechterhalten.
• Sie führen Umgebungen für die Entwicklung und Funktionstests in der öffentlichen Cloud aus. Diese Umgebungen können funktional äquivalent zu den übrigen Umgebungen sein, die sich jedoch in funktionsunabhängigen Aspekten wie der Leistung unterscheiden können. Dieses Konzept wird im vorherigen Diagramm veranschaulicht.
• Sie führen Umgebungen für die Produktion, das Staging sowie Leistungs- (Lasttests) und Zuverlässigkeitstests in der privaten Rechenumgebung aus und sorgen so für eine funktionale und funktionsunabhängige Äquivalenz.

Designaspekte

• Geschäftsanforderungen: Jede Bereitstellungs- und Releasestrategie für Anwendungen hat Vor- und Nachteile. Um sicherzustellen, dass der von Ihnen gewählte Ansatz Ihren spezifischen Anforderungen entspricht, basieren Sie Ihre Auswahl auf eine gründliche Bewertung Ihrer Geschäftsanforderungen und -einschränkungen.
• Umgebungsunterschiede: Als Teil dieses Musters ist das Hauptziel der Verwendung dieser Cloud-Umgebung die Entwicklung und Tests. Der endgültige Status ist das Hosten der getesteten Anwendung in der privaten Umgebung vor Ort (Produktion). Das technische Team muss die Architekturen und Funktionen beider Funktionen kennen und verstehen, um das Entwickeln und Testen einer Funktion zu vermeiden, die in der Cloudumgebung wie erwartet funktionieren kann und in der Produktionsumgebung (lokal) fehlschlägt. Dies umfasst Abhängigkeiten von anderen Anwendungen und der Hardwareinfrastruktur, z. B. Sicherheitssysteme, die Traffic-Prüfungen durchführen.
• Governance: Verwenden Sie einen Genehmigungs- und Governance-Prozess, um zu steuern, was Ihr Unternehmen in der Cloud entwickeln und welche Daten es für Tests verwenden darf. Dieser Prozess kann Ihrem Unternehmen auch helfen, sicherzustellen, dass in Ihren Entwicklungs- und Testumgebung keine Cloud-Funktionen verwendet werden, die in Ihrer lokalen Produktionsumgebung nicht vorhanden sind.
• Erfolgskriterien: Es muss klare, vordefinierte und messbare Erfolgskriterien für das Testen geben, die mit den Standards für die Qualitätssicherung von Software in Ihrem Unternehmen übereinstimmen. Wenden Sie diese Standards auf jede Anwendung an, die Sie entwickeln und testen.
• Redundanz: Auch wenn Entwicklungs- und Testumgebungen nicht ganz so zuverlässig sein müssen wie die Produktionsumgebung, benötigen sie dennoch redundante Funktionen und die Möglichkeit, verschiedene Fehlerszenarien zu testen. Ihre Anforderungen an ein Fehlerszenario könnten dazu führen, dass Sie Redundanz in Ihre Entwicklungs- und Testumgebung einbauen.

Vorteile

Das Ausführen von Arbeitslasten für die Entwicklung und für Funktionstests in der öffentlichen Cloud bietet mehrere Vorteile:

• Umgebungen lassen sich nach Bedarf automatisch starten und herunterfahren. Sie können beispielsweise eine komplette Umgebung für jede Commit- oder Pull-Anfrage bereitstellen, Tests ausführen und dann die Umgebung wieder abschalten. Dieser Ansatz bietet außerdem folgende Vorteile:
  • Sie können die Kosten senken, indem Sie VM-Instanzen beenden, wenn sie inaktiv sind, oder Umgebungen nur bei Bedarf bereitstellen.
  • Sie können Entwicklung und Tests beschleunigen, indem Sie sitzungsspezifischen Umgebungen für jede Pull-Anfrage starten. Außerdem wird dadurch der Wartungsaufwand reduziert und Inkonsistenzen in der Build-Umgebung werden verringert.
• Wenn Sie diese Umgebungen in der öffentlichen Cloud ausführen, können Sie sich mit der Cloud und den zugehörigen Tools vertraut machen und Erfahrungen damit sammeln. Dies kann für die Migration anderer Arbeitslasten hilfreich sein. Dieser Ansatz ist besonders hilfreich, wenn Sie sich dafür entscheiden, Arbeitslastportabilität mithilfe von Containern und Kubernetes, z. B. mit GKE Enterprise in verschiedenen Umgebungen zu erkunden.

Best Practices

Beachten Sie für die erfolgreiche Implementierung des Hybridarchitekturmusters für die Umgebung die folgenden Empfehlungen:

• Definieren Sie die Kommunikationsanforderungen für Ihre Anwendung, einschließlich das optimale Netzwerk- und Sicherheitsdesign. Verwenden Sie dann das Muster für gespiegeltes Netzwerk, um Ihre Netzwerkarchitektur so zu entwerfen, dass eine direkte Kommunikation zwischen Systemen aus verschiedenen Umgebungen verhindert wird. Wenn eine Kommunikation umgebungsübergreifend erforderlich ist, muss es in einer kontrollierten Art und Weise erfolgen.

• Die von Ihnen gewählte Strategie für die Bereitstellung und das Testen von Anwendungen sollte sich an Ihren Geschäftszielen und -anforderungen orientieren. Das kann das Implementieren von Änderungen ohne Ausfallzeit oder die schrittweise Implementierung von Funktionen in einer bestimmten Umgebung oder Nutzergruppe vor der allgemeinen Veröffentlichung umfassen.

• Sie können Container mit Kubernetes verwenden, um Arbeitslasten portabel zu machen und Unterschiede zwischen Umgebungen zu abstrahieren. Weitere Informationen finden Sie unter Referenzarchitektur der hybriden GKE Enterprise-Umgebung.

• Etablierung einer gemeinsamen Toolchain, die in allen Rechenumgebungen funktioniert, zum Bereitstellen, Konfigurieren und Betreiben von Arbeitslasten. Kubernetes bietet diese Beständigkeit.

• Achten Sie darauf, dass CI/CD-Pipelines in der gesamten Rechenumgebung konsistent sind und dass in diesen Umgebungen genau dieselben Binärdateien, Pakete oder Container bereitgestellt werden.

• Nutzen Sie bei Verwendung von Kubernetes ein CI-System wie Jenkins, um eine Bereitstellungspipeline zu implementieren, die Bereitstellungen auf Clustern ausführt und in allen Umgebungen funktioniert. Weitere Informationen finden Sie unter DevOps-Lösungen in Google Cloud.

• Um die kontinuierliche Bereitstellung sicherer und zuverlässiger Anwendungen zu unterstützen, sollten Sie die Sicherheit als integralen Bestandteil des DevOps-Prozesses (DevSecOps) einbinden. Weitere Informationen finden Sie unter: Mit dem Dev(Sec)Ops Toolkit können Sie Ihre mit dem Internet verbundenen Anwendungen in weniger als einer Stunde bereitstellen und schützen.

• Verwenden Sie für das Logging und Monitoring in Google Cloud und in vorhandenen Cloud-Umgebungen die gleichen Tools. Prüfen Sie den Einsatz von Open-Source-Monitoring und -Systemen. Weitere Informationen finden Sie unter Hybrid- und Multi-Cloud-Monitoring- und -Logging-Muster.

• Wenn Test- und Produktionsarbeitslasten von verschiedenen Teams verwaltet werden, ist die Verwendung verschiedener Tools möglicherweise kein Problem. Allerdings lässt sich der Schulungsaufwand und die Komplexität durch die Verwendung derselben Tools mit unterschiedlichen Berechtigungen für die Datenansicht reduzieren.

• Wählen Sie als Datenbank-, Speicher- und Nachrichtendienste für funktionale Tests Produkte aus, für die es in Google Cloud ein verwaltetes Äquivalent gibt. Durch die Nutzung verwalteter Dienste verringert sich der administrative Aufwand für die Pflege von Entwicklungs- und Testumgebungen.

• Zum Schutz vertraulicher Daten empfehlen wir, alle Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cloud Interconnect.

Die folgende Tabelle zeigt, welche Google Cloud-Produkte mit gängigen OSS-Produkten kompatibel sind.

OSS-Produkt	Kompatibel mit Google Cloud-Produkt
Apache HBase	Bigtable
apache beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL, PostgreSQL	Cloud SQL
Redis-Cluster, Redis, Memcached	Memorystore
Network File System (NFS)	Filestore
JMS, Kafka	Pub/Sub
Kubernetes	GKE Enterprise