In diesem Dokument finden Sie eine Anleitung zu gängigen und bewährten Ansätzen und Überlegungen für die Migration Ihrer Arbeitslast in die Cloud. Es geht weiter auf die Anleitung in Strategie für Hybrid- und Multi-Cloud-Architekturen entwickeln ein, in der mehrere mögliche und empfohlene Schritte zum Entwickeln einer Strategie für den Einsatz einer Hybrid- oder Multi-Cloud-Architektur erörtert werden.
Cloud First
Bei der anfänglichen Umstellung auf die öffentliche Cloud wird häufig nach dem Prinzip Cloud First vorgegangen. Bei diesem Ansatz stellen Sie Ihre neuen Arbeitslasten in der öffentlichen Cloud bereit, während Ihre vorhandenen Arbeitslasten am gleichen Ort bleiben. Ziehen Sie in diesem Fall nur dann eine klassische Bereitstellung in einer privaten Rechenumgebung in Betracht, wenn die Bereitstellung einer öffentlichen Cloud aus technischen oder organisatorischen Gründen nicht möglich ist.
Die Cloud-First-Strategie hat Vor- und Nachteile. Positiv ist, dass diese Strategie vorwärts gerichtet ist. Sie können neue Arbeitslasten modernisiert bereitstellen und vermeiden (oder minimieren zumindest) die Probleme, die mit der Migration vorhandener Arbeitslasten einhergehen.
Ein Cloud-First-Ansatz bietet zwar bestimmte Vorteile, kann aber möglicherweise dazu führen, dass Ihnen Gelegenheiten zur Verbesserung oder Nutzung vorhandener Arbeitslasten entgehen. Neue Arbeitslasten machen vielleicht einen Bruchteil der gesamten IT-Landschaft aus, und ihre Auswirkungen auf die IT-Kosten und die Leistung sind begrenzt. Die Zuweisung von Zeit und Ressourcen für die Migration einer vorhandenen Arbeitslast kann zu erheblicheren Vorteilen oder Kosteneinsparungen führen als der Versuch, eine neue Arbeitslast in der Cloud-Umgebung unterzubringen.
Wenn Sie dem Cloud-First-Ansatz strikt folgen, besteht auch die Gefahr, dass die Komplexität Ihrer IT-Umgebung insgesamt steigt. Dies führt unter Umständen zu Redundanzen, niedrigerer Leistung aufgrund eventueller übermäßiger Kommunikation zwischen Umgebungen oder einer Rechenumgebung, die für einzelne Arbeitslasten nicht gut geeignet ist. Darüber hinaus kann die Einhaltung von Branchenvorschriften und Datenschutzgesetzen Unternehmen daran hindern, bestimmte Anwendungen zu migrieren, die sensible Daten enthalten.
In Anbetracht dieser Risiken kann es besser sein, den Cloud-First-Ansatz nur bei ausgewählten Arbeitslasten zu verfolgen. Mit einem Cloud-First-Ansatz können Sie sich auf die Arbeitslasten konzentrieren, die am meisten von einer Cloud-Bereitstellung oder -Migration profitieren. Bei diesem Ansatz wird auch die Modernisierung vorhandener Arbeitslasten berücksichtigt.
Ein gängiges Beispiel für eine Cloud-First-Hybridarchitektur ist, wenn Anwendungen und Dienste, die kritische Daten enthalten, in neue Daten oder Anwendungen integriert werden müssen. Zum Abschließen der Integration können Sie eine Hybrid-Architektur verwenden, die Legacy-Dienste mithilfe von API-Schnittstellen modernisiert. Dadurch können sie von neuen Cloud-Diensten und -Anwendungen genutzt werden. Mit einer API-Verwaltungsplattform in der Cloud wie Apigee können Sie solche Anwendungsfälle mit minimalen Anwendungsänderungen implementieren und Sicherheit, Analysen und Skalierbarkeit zu den Legacy-Diensten hinzufügen.
Migration und Modernisierung
Hybrid-/Multi-Cloud-Bereitstellung und IT-Modernisierung sind unterschiedliche Konzepte, die sich wechselseitig positiv beeinflussen. Der Einsatz der öffentlichen Cloud kann den Prozess zum Modernisieren von IT-Arbeitslasten vereinfachen. Durch die Modernisierung Ihrer IT-Arbeitslasten können Sie die Cloud noch besser nutzen.
Die wichtigsten Ziele der Arbeitslastmodernisierung sind:
- Steigerung der Flexibilität, um auf wechselnde Anforderungen reagieren zu können
- Reduzieren der Kosten für Ihre Infrastruktur und Ihren Betrieb
- Erhöhen der Zuverlässigkeit und Ausfallsicherheit, um Risiken zu minimieren
Es ist jedoch vielleicht nicht möglich, jede Anwendung im Migrationsprozess gleichzeitig zu modernisieren. Wie unter Migration zu Google Cloud beschrieben, können Sie einen der folgenden Migrationstypen umsetzen oder bei Bedarf mehrere Typen kombinieren:
- Hostwechsel (Lift-and-Shift)
- Plattformwechsel (Lift-and-Optimize)
- Refaktorierung (Verschieben und Verbessern)
- Umgestalten (Modernisierung fortsetzen)
- Neuerstellung (Entfernen und ersetzen, manchmal auch als Rip-and-Replace bezeichnet)
- Neukauf
Bei strategischen Entscheidungen zu Ihren Hybrid- und Multi-Cloud-Architekturen ist es wichtig, die Durchführbarkeit Ihrer Strategie im Hinblick auf Kosten und Zeit zu berücksichtigen. Sie können einen stufenweisen Migrationsansatz in Betracht ziehen, beginnend mit Lift-and-Shift oder Plattformwechsel und dann mit der Refaktorierung oder der Umgestaltung als nächsten Schritt. In der Regel hilft Lift-and-Shift aus Infrastrukturperspektive dabei, Anwendungen zu optimieren. Sobald Anwendungen in der Cloud ausgeführt werden, ist es einfacher, Cloud-Dienste zu nutzen und zu integrieren, um sie mit Cloud-First-Architekturen und -Funktionen weiter zu optimieren. Außerdem können diese Anwendungen weiterhin über eine hybride Netzwerkverbindung mit anderen Umgebungen kommunizieren.
Sie können beispielsweise eine große, monolithische VM-basierte Anwendung refaktorieren oder umgestalten und sie in mehrere unabhängige Mikrodienste basierend auf einer cloudbasierten Mikrodienstarchitektur umwandeln. In diesem Beispiel verwendet die Mikrodienstarchitektur von Google Cloud verwaltete Containerdienste wie Google Kubernetes Engine (GKE) oder Cloud Run Wenn die Architektur oder Infrastruktur einer Anwendung jedoch in der Ziel-Cloud-Umgebung nicht unterstützt wird, können Sie mit einem Plattformwechsel, einer Refaktorierung oder einer Umgestaltung Ihrer Migrationsstrategie beginnen, um diese Einschränkungen zu überwinden, wenn möglich.
Wenn Sie einen dieser Migrationsansätze verwenden, sollten Sie die Modernisierung Ihrer Anwendung in Betracht ziehen (sofern zutreffend und möglich). Für eine Modernisierung müssen Sie möglicherweise SRE-Prinzipien (Site Reliability Engineering) oder DevOps-Prinzipien übernehmen und implementieren. Daher müssen Sie in einem hybriden Szenario möglicherweise die Anwendungsmodernisierung auch auf Ihre private Umgebung ausweiten. Obwohl die Implementierung der SRE-Prinzipien im Kern das Engineering nutzt, ist dies eher ein Transformationsprozess als eine technische Herausforderung. Daher sind wahrscheinlich verfahrenstechnische und kulturelle Änderungen erforderlich. Weitere Informationen dazu, wie der erste Schritt zur Implementierung von SRE in einer Organisation darin besteht, Unterstützung der Führungsebene zu erhalten, finden Sie unter With SRE, failing to plan is planning to fail.
Migrationsansätze kombinieren und abstimmen
Jeder hier erläuterte Migrationsansatz hat bestimmte Stärken und Schwächen. Ein entscheidender Vorteil einer Hybrid- und Multi-Cloud-Strategie besteht darin, dass Sie sich nicht auf einen einzigen Ansatz festlegen müssen. Sie können vielmehr von Arbeitslast zu Arbeitslast entscheiden, welcher Ansatz für jede Arbeitslast oder jedes Anwendungspaket am besten funktioniert, wie im folgenden Diagramm dargestellt.
Dieses konzeptionelle Diagramm veranschaulicht die verschiedenen Migrations- und Modernisierungspfade oder -ansätze, die gleichzeitig auf verschiedene Arbeitslasten angewendet werden können, abhängig von den individuellen geschäftlichen, technischen Anforderungen und Zielen der einzelnen Arbeitslast oder Anwendung.
Außerdem ist es nicht notwendig, dass dieselben Komponenten des Anwendungs-Stacks demselben Migrationsansatz oder derselben Strategie folgen. Beispiel:
- Die lokale Back-End-Datenbank einer Anwendung kann von selbst gehostetem MySQL mithilfe von Cloud SQL in Google Cloud in eine verwaltete Datenbank übertragen werden.
- Die virtuellen Frontend-Maschinen der Anwendung können so refaktoriert werden, dass sie auf Containern mit GKE Autopilot ausgeführt werden. Hier verwaltet Google die Clusterkonfiguration, einschließlich Knoten, Skalierung, Sicherheit und anderen vorkonfigurierten Einstellungen.
- Die lokale Hardware-Load-Balancing-Lösung und die WAF-Funktionen (Web Application Firewall) können durch Cloud Load Balancing und Google Cloud Armor ersetzt werden.
Wählen Sie den Hostwechsel-Ansatz (Lift-and-Shift), wenn eine der folgenden Aussagen auf die Arbeitslasten zutrifft:
- Sie haben relativ wenige Abhängigkeiten mit ihrer Umgebung.
- Es lohnt sich nicht, sie zu refaktorieren oder sie zu refaktorieren, bevor die Migration machbar ist.
- Sie basieren auf Drittanbieter-Software.
Ziehen Sie einen Faktorwechsel (Verschieben und Verbessern) für diese Arten von Arbeitslasten in Betracht:
- Sie haben Abhängigkeiten, die aufgelöst werden müssen.
- Sie sind auf Betriebssysteme, Hardware oder Datenbanksysteme angewiesen, die nicht in der Cloud untergebracht werden können.
- Sie nutzen Rechen- oder Speicherressourcen nicht effizient.
- Sie können nicht ohne großen Aufwand automatisch bereitgestellt werden.
Überlegen Sie, ob die Neuerstellung (Entfernen und ersetzen) Ihren Anforderungen für diese Arten von Arbeitslasten entspricht:
- Sie werden den aktuellen Anforderungen nicht mehr gerecht.
- Sie können in andere Anwendungen integriert werden, die ähnliche Funktionen bieten, ohne dass die Geschäftsanforderungen gefährdet werden.
- Sie basieren auf einer Drittanbietertechnologie, die das Ende ihres Lebenszyklus erreicht hat.
- Sie sind mit Lizenzgebühren von Drittanbietern verbunden, die nicht mehr wirtschaftlich sind.
Das Rapid Migration Program zeigt, wie Google Cloud Kunden dabei unterstützt, Best Practices umzusetzen, Risiken zu senken, Kosten zu kontrollieren und ihren Weg in die Cloud zu vereinfachen.