Mit dem Umgebungshybrid-Architekturmuster behalten Sie die Produktionsumgebung einer Arbeitslast im vorhandenen Rechenzentrum. Anschließend verwenden Sie die öffentliche Cloud für Ihre Entwicklungs- und Testumgebungen oder andere Umgebungen. Dieses Muster beruht 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 im Lebenszyklus einer Anwendung beteiligt sind, 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 dazu 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 Ihre Produktionssysteme kann riskant erscheinen und von Ihren vorhandenen Best Practices oder von Ihren Versuchen, die Unterschiede zwischen den Umgebungen zu minimieren, abweichen. 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 Es wird auch als Lasttest bezeichnet.
- Staging- oder Bereitstellungstests: Prüfen, ob das Bereitstellungsverfahren funktioniert.
- Produktion: Veröffentlichung 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 Ihre Bereitstellungsverfahren für Anwendungen 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 kein Problem, wenn sich die für die Entwicklung und Funktionstests verwendeten Umgebungen auf funktionsunabhängiger Ebene von den anderen Umgebungen durchaus unterscheiden können.
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 in das 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.
- Achten Sie auf 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 ihre eigenen 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 kontrollieren, was Ihr Unternehmen in der Cloud entwickeln darf und welche Daten es für Tests verwenden kann. 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:
- Sie können Umgebungen je nach Bedarf automatisch starten und beenden.
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, wenn 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. Dies reduziert auch den Wartungsaufwand und reduziert Inkonsistenzen in der Build-Umgebung.
- 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
Um das Muster der Hybridarchitektur der Umgebung erfolgreich zu implementieren, sollten Sie die folgenden Empfehlungen beachten:
- 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. Dies kann die Einführung von Änderungen ohne Ausfallzeiten oder die schrittweise Implementierung von Features in einer bestimmten Umgebung oder Nutzergruppe vor einer breiteren Veröffentlichung umfassen. Weitere Informationen finden Sie unter Strategien für Bereitstellung und Tests von Anwendungen.
Sie können Container mit Kubernetes verwenden, um Arbeitslasten portabel zu machen und Unterschiede zwischen Umgebungen durch Abstraktion zu überbrücken. 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
Für die kontinuierliche Freigabe sicherer und zuverlässiger Anwendungen sollten Sie Sicherheit als wesentlichen 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 Muster für Hybrid- und Multi-Cloud-Monitoring und -Logging.
Wenn verschiedene Teams Test- und Produktionsarbeitslasten verwalten, ist die Verwendung separater Tools möglicherweise akzeptabel. Wenn Sie jedoch dieselben Tools mit unterschiedlichen Ansichtsberechtigungen verwenden, können Sie den Trainingsaufwand und die Komplexität reduzieren.
Wenn Sie für Funktionstests Datenbank-, Speicher- und Nachrichtendienste auswählen, verwenden Sie Produkte, 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 Informationen empfehlen wir, die gesamte Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung auf Verbindungsebene erforderlich ist, sind je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen verfügbar. 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 |