Dieses Dokument hilft ihnen dabei, die Bewertungsphase Ihrer Migration zu Google Cloud zu planen, zu gestalten und zu implementieren. Sie können feststellen, welche Elemente in welcher Reihenfolge migriert werden müssen. Ermitteln Sie dazu den Bestand Ihrer Arbeitslasten und Dienste und dokumentieren Sie deren Abhängigkeiten. Wenn Sie eine Migration zu Google Cloud planen und konzipieren, müssen Sie zuerst Ihre aktuelle Umgebung sowie die zu migrierenden Arbeitslasten genau kennen.
Dieses Dokument ist Teil der folgenden mehrteiligen Reihe zur Migration zu Google Cloud:
- Zu Google Cloud migrieren: Erste Schritte
- Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen (dieses Dokument)
- Zu Google Cloud migrieren: Grundlage planen und erstellen
- Zu Google Cloud migrieren: Große Datasets übertragen
- Zu Google Cloud migrieren: Arbeitslasten bereitstellen
- Zu Google Cloud migrieren: Von manuellen zu automatisierten Containerbereitstellungen migrieren
- Zu Google Cloud migrieren: Umgebung optimieren
- Zu Google Cloud migrieren: Best Practices zur Validierung eines Migrationsplans
- Zu Google Cloud migrieren: Kosten minimieren
Diese Grafik veranschaulicht den Migrationsprozess:
Dieses Dokument bietet nützliche Informationen, wenn Sie von einer lokalen Umgebung, einer privaten Hosting-Umgebung oder einem anderen Cloudanbieter aus eine Migration vornehmen möchten oder die Möglichkeit einer Migration prüfen und untersuchen wollen, wie die Bewertungsphase aussehen könnte.
In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration Ihrer Quellumgebung zu Google Cloud.
Die Bewertungsphase ist für den Erfolg der Migration entscheidend. Sie benötigen umfassende Kenntnisse über die zu migrierenden Arbeitslasten, deren Anforderungen, Abhängigkeiten und über Ihre aktuelle Umgebung. Sie müssen Ihre Ausgangssituation verstehen, um eine Google Cloud-Migration erfolgreich planen und ausführen zu können.
Die Bewertungsphase umfasst die folgenden Aufgaben:
- Ein umfassendes Inventar Ihrer Arbeitslasten erstellen.
- Arbeitslasten nach ihren Attributen und Abhängigkeiten katalogisieren.
- Die Teams auf Google Cloud vorbereiten.
- Tests und Proofs of Concept in Google Cloud erstellen.
- Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
- Migrationsstrategie für Ihre Arbeitslasten auswählen.
- Tools für die Migration auswählen.
- Migrationsplan und Zeitplan definieren.
- Migrationsplan validieren.
Inventar Ihrer Arbeitslasten erstellen
Um den Umfang Ihrer Migration festzulegen, müssen Sie zuerst wissen, wie viele Elemente (z. B. Arbeitslasten und Hardware) in Ihrer aktuellen Umgebung vorhanden sind und welche Abhängigkeiten bestehen. Ein Inventar zu erstellen, ist keine triviale Aufgabe und erfordert einen erheblichen Aufwand. Vor allem, wenn kein automatisches Katalogisierungssystem vorhanden ist. Damit Sie ein umfassendes Inventar erstellen können, müssen Sie auf das Fachwissen der Teams zurückgreifen, die für den Entwurf, die Bereitstellung und den Betrieb der einzelnen Arbeitslasten in Ihrer aktuellen Umgebung sowie für die Umgebung selbst verantwortlich sind.
Das Inventar sollte nicht nur auf Arbeitslasten beschränkt sein, sondern mindestens Folgendes enthalten:
- Abhängigkeiten der einzelnen Arbeitslasten, z. B. Datenbanken, Nachrichtenbroker, Konfigurationsspeichersysteme und andere Komponenten
- Dienste, die Ihre Arbeitslastinfrastruktur unterstützen, z. B. Quell-Repositories, CI/CD-Tools (Continuous Integration/Continuous Deployment) und Artefakt-Repositories
- Server, entweder virtuell oder physisch, und Laufzeitumgebungen.
- Physische Appliances wie Netzwerkgeräte, Firewalls und andere dedizierte Hardware
Beim Zusammenstellen dieser Liste sollten Sie auch Informationen zu den einzelnen Elementen erfassen, darunter:
- Speicherort des Quellcodes und ob Sie diesen Quellcode ändern können.
- Bereitstellungsmethode für die Arbeitslast in einer Laufzeitumgebung, z. B. ob Sie eine automatisierte oder eine manuelle Bereitstellungspipeline verwenden
- Netzwerkeinschränkungen oder Sicherheitsanforderungen
- Anforderungen an IP-Adressen
- Wie Sie die Arbeitslast für Clients bereitstellen.
- Lizenzanforderungen für Software oder Hardware
- Wie sich die Arbeitslast bei Ihrem Identitäts- und Zugriffsverwaltungssystem authentifiziert.
Beispielsweise sollten Sie für jede Hardware die detaillierten Spezifikationen kennen, z. B. den Namen, den Hersteller, die Technologien und die Abhängigkeiten von anderen Elementen in Ihrem Inventar. Beispiel:
- Name: NAS-Appliance
- Anbieter und Modell: Anbieter Y, Modell Z
- Technologien: NFS, iSCSI
- Abhängigkeiten: Netzwerkverbindung zur VM-Computerhardware mit Jumbo Frames
Diese Liste sollte auch nichttechnische Informationen enthalten, z. B. unter welchen Lizenzbedingungen Sie die einzelnen Artikel verwenden dürfen, und sonstige Complianceanforderungen. Während Sie mit einigen Lizenzen eine Arbeitslast in einer Cloudumgebung bereitstellen können, verbieten andere ausdrücklich die Bereitstellung in einer Cloud. Einige Lizenzen werden basierend auf der Anzahl der verwendeten CPUs oder Sockets zugewiesen. Diese Konzepte sind möglicherweise nicht anwendbar, wenn sie auf Cloudtechnologie ausgeführt werden. Einige Ihrer Daten unterliegen möglicherweise Einschränkungen in Bezug auf die geografische Region, in der sie gespeichert sind. Außerdem ist es noch möglich, dass einige sensible Arbeitslasten einzelne Mandanten erfordern.
Es ist außerdem nützlich, zusammen mit dem Inventar Hilfsmittel für eine visuelle Interpretation der von Ihnen gesammelten Daten bereitzustellen. Sie können beispielsweise eine Abhängigkeitsgrafik und -diagramme bereitstellen, um wichtige Aspekte hervorzuheben, z. B. die Verteilung Ihrer Arbeitslasten in einem automatisierten oder manuellen Bereitstellungsprozess.
Inventar erstellen
Es gibt verschiedene Möglichkeiten, ein Arbeitslastinventar zu erstellen. Die manuelle Vorgehensweise ist zwar der schnellste Einstieg, kann jedoch bei einer großen Produktionsumgebung schwierig sein. Informationen in manuell erstellten Inventaren können schnell veraltet sein und die resultierende Migration schlägt möglicherweise fehl, da Sie den Inhalt Ihrer Inventare nicht bestätigt haben.
Der Aufbau des Inventars ist keine einmalige Übung. Wenn Ihre aktuelle Umgebung sehr dynamisch ist, sollten Sie sich auch um die Automatisierung der Inventarerstellung und -wartung bemühen, damit Sie am Ende jederzeit eine konsistente Ansicht aller Elemente in Ihrer Umgebung haben. Informationen zum Erstellen eines Inventars Ihrer Arbeitslasten finden Sie unter Migration Center: Asset-Erkennung starten.
Beispiel für ein Arbeitslasteninventar
In diesem Beispiel wird eine Umgebung inventarisiert, die eine E-Commerce-Anwendung unterstützt. Das Inventar umfasst Arbeitslasten, Abhängigkeiten, Dienste, die mehrere Arbeitslasten unterstützen, und Hardware-Appliance.
Arbeitslasten
In der folgenden Tabelle werden für jede Arbeitslast in der Umgebung die wichtigsten Technologien, das Bereitstellungsverfahren und andere Anforderungen aufgeführt.
Name | Speicherort des Quellcodes | Technologien | Bereitstellungsverfahren | Weitere Anforderungen | Abhängigkeiten | Systemressourcenanforderungen |
---|---|---|---|---|---|---|
Marketingwebsite | Unternehmens-Repository | Angular-Frontend | Automatisiert | Die Rechtsabteilung muss den Inhalt validieren | Caching-Dienst | 5 CPU-Kerne 8 GB RAM |
Backoffice | Unternehmens-Repository | Java-Backend, Angular-Frontend | Automatisiert | – | SQL-Datenbank | 4 CPU-Kerne 4 GB RAM |
E-Commerce-Arbeitslast | Benutzerdefinierte Arbeitslast | Anbieter X Modell Y Version 1.2.0 |
Manuell | Kundendaten müssen sich in der Europäischen Union befinden | SQL-Datenbank | 10 CPU-Kerne 32 GB RAM |
Warenwirtschaft (Enterprise Resource Planning, ERP) | Benutzerdefinierte Arbeitslast | Hersteller Z, Modell C, Version 7.0 | Manuell | – | SQL-Datenbank | 10 CPU-Kerne 32 GB RAM |
Zustandslose Mikrodienste | Unternehmens-Repository | Java | Automatisiert | – | Caching-Dienst | 4 CPU-Kerne 8 GB RAM |
Abhängigkeiten
Die folgende Tabelle ist ein Beispiel für die Abhängigkeiten der im Inventar aufgeführten Arbeitslasten. Diese Abhängigkeiten sind erforderlich, damit die Arbeitslasten ordnungsgemäß funktionieren.
Name | Technologien | Weitere Anforderungen | Abhängigkeiten | Systemressourcenanforderungen |
---|---|---|---|---|
SQL-Datenbank | postgresql | Kundendaten müssen sich in der Europäischen Union befinden | Sicherungs- und Archivierungssystem | 30 CPU-Kerne 512 GB RAM |
Unterstützende Dienste
In Ihrer Umgebung haben Sie möglicherweise Dienste, die mehrere Arbeitslasten unterstützen. In diesem E-Commerce-Beispiel sind folgende Dienste enthalten:
Name | Technologien | Weitere Anforderungen | Abhängigkeiten | Systemressourcenanforderungen |
---|---|---|---|---|
Quellcode-Repositories | Git | – | Sicherungs- und Archivierungssystem | 2 CPU-Kerne 4 GB RAM |
Sicherungs- und Archivierungssystem | Hersteller G, Modell H, Version 2.3.0 | Laut Gesetz ist für einige Artikel eine langfristige Speicherung erforderlich | – | 10 CPU-Kerne 8 GB RAM |
CI-Tool | Jenkins | – | Quellcode-Repositories Artefakt-Repository Sicherungs- und Archivierungssystem |
32 CPU-Kerne 128 GB RAM |
Artefakt-Repository | Anbieter A Modell N Version 5.0.0 |
– | Sicherungs- und Archivierungssystem | 4 CPU-Kerne 8 GB RAM |
Batchverarbeitungsdienst | Cronjobs, die im CI-Tool ausgeführt werden | – | CI-Tool | 4 CPU-Kerne 8 GB RAM |
Caching-Dienst | Memcached Redis |
– | – | 12 CPU-Kerne 50 GB RAM |
Hardware
Die Beispielumgebung enthält die folgende Hardware:
Name | Technologien | Weitere Anforderungen | Abhängigkeiten | Systemressourcenanforderungen |
---|---|---|---|---|
Firewall | Anbieter H Modell V |
– | – | – |
Instanzen von Server j | Anbieter K Modell B |
Muss außer Betrieb genommen werden, da sie nicht mehr unterstützt werden | – | – |
NAS-Appliance | Anbieter Y Modell Z NFS iSCSI |
– | – | – |
Bereitstellungs- und operative Prozesse bewerten
Es ist wichtig, ein klares Verständnis von der Funktionsweise Ihrer Bereitstellungs- und Betriebsprozesse zu haben. Diese Prozesse sind ein grundlegender Teil der Praktiken, die die Produktionsumgebung und die dort ausgeführten Arbeitslasten vorbereiten und verwalten.
Die Bereitstellungs- und Betriebsprozesse können die Artefakte erstellen, die Ihre Arbeitslasten benötigen. Daher sollten Sie Informationen zu jedem Artefakttyp erfassen. Ein Artefakt kann beispielsweise ein Betriebssystempaket, ein Bereitstellungspaket für Anwendungen, ein Betriebssystem-Image, ein Container-Image oder etwas anderes sein.
Berücksichtigen Sie zusätzlich zum Artefakttyp, wie Sie die folgenden Aufgaben ausführen:
- Entwickeln Sie Ihre Arbeitslasten: Bewerten Sie die Prozesse, die Entwicklungsteams zum Erstellen Ihrer Arbeitslasten eingerichtet haben. Wie entwerfen, codieren und testen Ihre Entwicklungsteams beispielsweise Ihre Arbeitslasten?
- Generieren Sie Artefakte, die Sie in Ihrer Quellumgebung bereitstellen. Zum Bereitstellen Ihrer Arbeitslasten in der Quellumgebung generieren Sie möglicherweise bereitstellbare Artefakte wie Container-Images oder Betriebssystem-Images oder passen vorhandene Artefakte an, z. B. Betriebssystemimages von Drittanbietern durch Installieren und Konfigurieren von Software. Durch Erfassen von Informationen zum Generieren dieser Artefakte können Sie dafür sorgen, dass die generierten Artefakte für die Bereitstellung in Google Cloud geeignet sind.
Artefakte speichern: Wenn Sie Artefakte in einer Artefakt-Registry in Ihrer Quellumgebung speichern, müssen Sie die Artefakte in Ihrer Google Cloud-Umgebung verfügbar machen. Verwenden Sie dazu Strategien wie die folgenden:
- Richten Sie eine Kommunikationskanal zwischen den Umgebungen ein: Artefakte in der Quellumgebung werden über die Google Cloud-Zielumgebung erreichbar.
- Refaktorieren Sie den Artefakt-Build-Prozess: Führen Sie eine geringfügige Refaktorierung Ihrer Quellumgebung durch, damit Sie Artefakte sowohl in der Quell- als auch in der Zielumgebung speichern können. Dieser Ansatz unterstützt die Migration durch Erstellen einer Infrastruktur wie ein Artefakt-Repository, bevor Sie Artefakterstellungsprozesse in der Google Cloud-Zielumgebung implementieren müssen. Sie können diesen Ansatz direkt implementieren oder auf dem vorherigen Ansatz aufbauen, der zuerst einen Kommunikationskanal einrichtet.
Wenn Artefakte sowohl in der Quell- als auch in der Zielumgebung verfügbar sind, können Sie sich auf die Migration konzentrieren, ohne im Rahmen der Migration Artefakterstellungsprozesse in der Google Cloud-Zielumgebung implementieren zu müssen.
Scannen und signieren Sie Code . Im Rahmen Ihrer Artefakterstellungsprozesse verwenden Sie möglicherweise Codescans, um sich vor allgemeinen Sicherheitslücken und unbeabsichtigten Netzwerken zu schützen, sowie Codesignaturen, die dafür sorgen, dass nur vertrauenswürdiger Code in Ihren Umgebungen ausgeführt wird.
Stellen Sie Artefakte in der Quellumgebung bereit. Nachdem Sie bereitstellbare Artefakte generiert haben, stellen Sie diese möglicherweise in Ihrer Quellumgebung bereit. Wir empfehlen, jeden Bereitstellungsprozess zu bewerten. Die Bewertung sorgt dafür, dass Ihre Bereitstellungsprozesse mit Google Cloud kompatibel sind. Außerdem können Sie damit den Aufwand ermitteln, der für eine eventuelle Refaktorierung der Prozesse erforderlich ist. Wenn Ihre Bereitstellungsprozesse beispielsweise nur mit Ihrer Quellumgebung funktionieren, müssen Sie sie unter Umständen so refaktorieren, dass sie auf Ihre Google Cloud-Umgebung abzielen.
Laufzeitkonfiguration einfügen. Sie können die Laufzeitkonfiguration für bestimmte Cluster, Laufzeitumgebungen oder Arbeitslastbereitstellungen einfügen. Die Konfiguration kann Umgebungsvariablen und andere Konfigurationswerte wie Secrets, Anmeldedaten und Schlüssel initialisieren. Damit Ihre Prozesse zur Einfügung von Laufzeitkonfigurationen in Google Cloud funktionieren, empfehlen wir Ihnen zu bewerten, wie Sie die Arbeitslasten konfigurieren, die in Ihrer Quellumgebung ausgeführt werden.
Logging, Monitoring und Profilerstellung: Bewerten Sie die Logging-, Monitoring- und Profilerstellungsprozesse, die Sie eingerichtet haben, um den Zustand Ihrer Quellumgebung, die relevanten Messwerte und die Verwendung der Daten zu überwachen, die von diesen Prozessen bereitgestellt werden.
Authentifizierung Prüfen Sie, wie Sie sich in Ihrer Quellumgebung authentifizieren.
Ressourcen bereitstellen und konfigurieren Zur Vorbereitung Ihrer Quellumgebung haben Sie möglicherweise Prozesse entwickelt und implementiert, die Ressourcen bereitstellen und konfigurieren. Beispielsweise verwenden Sie Terraform zusammen mit Konfigurationsverwaltungstools, um Ressourcen in der Quellumgebung bereitzustellen und zu konfigurieren.
Infrastruktur bewerten
Nachdem Sie Ihre Bereitstellungs- und Betriebsprozesse bewertet haben, sollten Sie die Infrastruktur bewerten, die Ihre Arbeitslasten derzeit in der Quellumgebung unterstützt.
Beachten Sie Folgendes, um diese Infrastruktur zu bewerten:
- Wie Sie die Ressourcen in der Quellumgebung organisiert haben. Einige Umgebungen unterstützen beispielsweise eine logische Trennung zwischen Ressourcen mithilfe von Konstrukten, die Ressourcengruppen voneinander isolieren, z. B. Organisationen, Projekte und Namespaces.
- Wie Sie Ihre Umgebung mit anderen Umgebungen wie lokalen Umgebungen und anderen Cloud-Anbietern verbunden haben.
Arbeitslasten kategorisieren
Nachdem Sie das Inventar abgeschlossen haben, müssen Sie Ihre Arbeitslasten in verschiedene Kategorien unterteilen. Mithilfe dieser Kategorisierung können Sie die Prioritäten für die Migration der Arbeitslasten entsprechend ihrer Komplexität und ihres Risikos beim Wechsel in die Cloud festlegen.
Eine Katalogmatrix sollte für jedes Bewertungskriterium, das Sie in Ihrer Umgebung berücksichtigen, eine Dimension haben. Wählen Sie einen Kriteriensatz aus, der alle Anforderungen Ihrer Umgebung abdeckt, einschließlich der Systemressourcen, die jede Arbeitslast benötigt. Beispielsweise könnte es Sie interessieren, ob eine Arbeitslast Abhängigkeiten aufweist oder zustandslos bzw. zustandsorientiert ist. Berücksichtigen Sie beim Erstellen der Katalogmatrix, dass Sie für jedes hinzugefügte Kriterium eine weitere darzustellende Dimension einfügen. Die daraus resultierende Matrix ist möglicherweise schwer darzustellen. Eine Lösung für dieses Problem könnte darin bestehen, mehrere kleinere Matrizen anstelle einer einzigen komplexen zu verwenden.
Außerdem sollten Sie neben jeder Arbeitslast einen Indikator für die Komplexität der Migration einfügen. Dieser Indikator schätzt den Schwierigkeitsgrad für die Migration jeder Arbeitslast. Die Granularität dieses Indikators hängt von der Umgebung ab. Für ein einfaches Beispiel könnten Sie drei Kategorien verwenden: einfach migrierbar, schwer migrierbar oder nicht migrierbar. Damit Sie diese Aktivität abschließen können, benötigen Sie für die einzenen Objekte im Inventar Experten, die für Sie die Komplexität der Migration abschätzen. Die Faktoren, von denen die Migrationskomplexität abhängt, sind spezifisch für den Geschäftskontext der Technologie und das Unternehmen.
Wenn der Katalog vollständig ist, können Sie auch Bilder und Diagramme erstellen, mit denen Sie und Ihr Team die relevanten Kennzahlen schnell auswerten können. Zeichnen Sie beispielsweise ein Diagramm, in dem hervorgehoben wird, wie viele Komponenten Abhängigkeiten haben, oder geben Sie den Schwierigkeitsgrad der Migration für die einzelnen Komponenten an.
Informationen zum Erstellen eines Inventars Ihrer Arbeitslasten finden Sie unter Migration Center: Asset-Erkennung starten.
Beispiel für einen Arbeitslastkatalog
In diesem Beispiel werden die folgenden Bewertungskriterien verwendet, eine für jede Matrixachse:
- Wie wichtig eine Arbeitslast für das Unternehmen ist.
- Ob eine Arbeitslast Abhängigkeiten hat oder für andere Arbeitslasten eine Abhängigkeit ist.
- Maximal zulässige Ausfallzeit für die Arbeitslast.
- Der Schwierigkeitsgrad der Migration einer Arbeitslast.
Bedeutung für das Unternehmen | Hat keine Abhängigkeiten oder abhängigen Elemente | Hat Abhängigkeiten oder abhängige Elemente | Maximal zulässige Ausfallzeit | Schwierigkeit |
---|---|---|---|---|
Geschäftskritisch | Zustandslose Mikrodienste | 2 Minuten | Einfach | |
Unternehmensressourcenplanung (ERP) | 24 Stunden | Schwer | ||
E-Commerce-Arbeitslast | Keine Ausfallzeiten | Schwer | ||
Hardware-Firewall | Keine Ausfallzeiten | Kann nicht verschoben werden | ||
SQL-Datenbank | 10 Minuten | Einfach | ||
Quellcode-Repositories | 12 Stunden | Einfach | ||
Nicht geschäftskritisch | Marketingwebsite | 2 Stunden | Einfach | |
Sicherung und Archivierung | 24 Stunden | Einfach | ||
Batchverarbeitungsdienst | 48 Stunden | Einfach | ||
Caching-Dienst | 30 Minuten | Einfach | ||
Backoffice | 48 Stunden | Schwer | ||
CI-Tool | 24 Stunden | Einfach | ||
Artefakt-Repository | 30 Minuten | Einfach |
Sie können Visualisierungen und Diagramme erstellen, die Ihnen die Darstellung der Ergebnisse im Katalog erleichtern. Das folgende Diagramm verdeutlicht den jeweiligen Schwierigkeitsgrad der Migration:
In der obigen Tabelle sind die meisten Arbeitslasten leicht zu verschieben, drei können nur schwer und eine von ihnen gar nicht verschoben werden.
Im Unternehmen über Google Cloud informieren
Ihre Organisation muss sich mit den Diensten, Produkten und Technologien vertraut machen, die sie auf Google Cloud verwenden kann, um die Vorteile voll ausschöpfen zu können. Ihre Mitarbeiter können mit kostenlosen Google Cloud-Testkonten beginnen. Diese enthalten Guthaben, mit denen sie experimentieren und lernen können. Für die Lernerfahrung Ihrer Mitarbeiter ist es von entscheidender Bedeutung, eine freie Umgebung zum Testen und Lernen zu schaffen.
Sie haben mehrere Trainingsoptionen:
- Öffentliche und offene Ressourcen: Kostenlose praktische Labs, Videoreihen, Cloud OnAir-Webinare und Cloud OnBoard-Schulungsveranstaltungen bieten einen Einstieg in Google Cloud.
- Vertiefende Kurse: Wenn Sie tiefer in die Funktionsweise von Google Cloud einsteigen möchten, können Sie in Ihrem eigenen Tempo online an On-Demand-Kursen von Google Cloud Skills Boost oder Schulungsspezialisierungen für Google Cloud von Coursera teilnehmen. Außerdem stehen Ihnen Präsenzschulungen zur Auswahl, die weltweit von unseren autorisierten Trainingspartnern angeboten werden. Diese Kurse dauern normalerweise einen bis mehrere Tage.
- Rollenbasierte Lernpfade: Sie können Ihre Entwickler entsprechend ihrer Rolle in der Organisation ausbilden. Beispielsweise können Sie in Schulungen Ihren Arbeitslastentwicklern oder Infrastrukturbetreibern die jeweils bestmöglichen Einsatzformen von Google Cloud-Diensten aufzeigen.
Sie können außerdem die Kenntnisse Ihrer Entwickler über Google Cloud mit verschiedenen Zertifizierungen auf verschiedenen Stufen zertifizieren:
- Associate-Zertifizierungen: Ein Start für Google Cloud-Neulinge, der Zugang zu professionellen Zertifizierungen wie der Zertifizierung als Associate Cloud Engineer bieten kann.
- Professionelle Zertifizierungen: Wenn Sie sich die in jahrelanger Erfahrung erworbenen erweiterten Design- und Implementierungsfähigkeiten für Google Cloud bestätigen lassen möchten, können Sie ebenfalls Zertifizierungen erhalten, z. B. den Professional Cloud Architect oder den Professional Data Engineer.
- Zertifizierungen für Google Workspace: Mit dieser Zertifizierung für Google Workspace können Sie die Fähigkeiten der Zusammenarbeit mit Google Workspace demonstrieren.
- Apigee-Zertifizierungen: Mit der Zertifizierung als zertifizierter API-Entwickler von Apigee können Sie nachweisen, dass Sie robuste, sichere und skalierbare APIs entwerfen und entwickeln können.
- Google Developers-Zertifizierungen: Mit den Zertifizierungen Associate Android Developer (Diese Zertifizierung wird aktualisiert) und Mobile Web Specialist können Sie Ihre Fähigkeiten als Entwickler unter Beweis stellen.
Neben Schulungen und Zertifizierungen besteht eine der besten Möglichkeiten, Erfahrungen mit Google Cloud zu sammeln, darin, mithilfe des Produkts Proof-of-Concept-Beispiele für Unternehmen zu erstellen.
Experimentieren und Proofs of Concept erstellen
Sie sollten in Ihrem Arbeitslastkatalog einen oder mehrere Proofs of Concept (PoCs) pro Arbeitslastkategorie entwerfen und entwickeln, mit denen Sie die Vorteile und die Effektivität von Google Cloud unter Beweis stellen. Durch Ausprobieren und Testen können Sie Annahmen validieren und Unternehmensleitern den Wert der Cloud demonstrieren.
Ihr PoC sollte mindestens Folgendes enthalten:
- Eine umfassende Liste der von Ihren Arbeitslasten unterstützten Anwendungsfälle, einschließlich seltener und Sonderfälle.
- Alle Anforderungen für jeden Anwendungsfall, z. B. Leistungs-, Skalierbarkeits- und Konsistenzanforderungen, Failover-Mechanismen und Netzwerkanforderungen.
- Eine potenzielle Liste von Technologien und Produkten, die Sie untersuchen und testen möchten.
Sie sollten PoCs und Tests entwerfen, um alle Anwendungsfälle in der Liste zu validieren. Jeder Test sollte den Gültigkeitskontext, den Umfang, die erwarteten Ergebnisse und die messbaren unternehmerischen Auswirkungen genau festlegen.
Beispielsweise soll eine Ihrer CPU-gebundenen Arbeitslasten schnell skaliert werden können, um Anforderungsspitzen zu erfüllen. Führen Sie dazu einen Test durch, um zu überprüfen, ob eine Zone viele virtuelle CPU-Kerne erstellen kann und wie viel Zeit hierfür erforderlich ist. Wenn Sie einen erheblichen Mehrwert erzielen, wie z. B. eine Verkürzung der Skalierungszeit für eine neue Arbeitslast um 95 % im Vergleich zu Ihrer aktuellen Umgebung, kann dies auf einen sofortigen geschäftlichen Nutzen hinweisen.
Wenn Sie die Leistung Ihrer lokalen Datenbanken im Vergleich zu Cloud SQL, Spanner, Firestore oder Bigtable bewerten möchten, können Sie einen PoC implementieren, bei dem dieselbe Geschäftslogik unterschiedliche Datenbanken verwendet. Dieser PoC bietet Ihnen die risikoarme Möglichkeit, die richtige Lösung für verwaltete Datenbanken für Ihre Arbeitslast über mehrere Benchmarks und Betriebskosten hinweg zu ermitteln.
Wenn Sie die Leistung des VM-Bereitstellungsprozesses in Google Cloud bewerten möchten, können Sie ein Drittanbietertool wie PerfKit Benchmarker verwenden und Google Cloud mit anderen Cloudanbietern vergleichen. Sie können die End-to-End-Zeit für die Bereitstellung von Ressourcen in der Cloud messen und darüber hinaus Standardmesswerte für die Spitzenleistung angeben, einschließlich Latenz, Durchsatz und Zeit bis zur Fertigstellung. Vielleicht interessieren Sie sich beispielsweise dafür, wie viel Zeit und Aufwand für die Bereitstellung vieler Kubernetes-Cluster erforderlich ist. PerfKit Benchmarker ist ein Open-Source-Communityprojekt, an dem über 500 Teilnehmer wie Forscher, akademische Einrichtungen und Unternehmen, einschließlich Google, beteiligt sind.
Gesamtbetriebskosten berechnen
Wenn Sie eine gute Übersicht über die Ressourcen haben, die Sie in der neuen Umgebung benötigen, können Sie ein Modell der Gesamtbetriebskosten erstellen, mit dem Sie Ihre Google Cloud-Kosten mit den Kosten Ihrer aktuellen Umgebung vergleichen können.
Wenn Sie dieses Kostenmodell erstellen, sollten Sie neben den Kosten für Hardware und Software auch alle Betriebskosten für den Betrieb Ihres eigenen Rechenzentrums berücksichtigen, z. B. Strom, Kühlung, Wartung und andere Supportdienste. Bedenken Sie, dass es im Vergleich zu einem unflexiblen lokalen Rechenzentrum in der Regel dank der elastischen Skalierbarkeit der Google Cloud-Ressourcen einfacher ist, Kosten zu senken.
Ein häufig übersehener Kostenfaktor bei der Berücksichtigung von Cloudmigrationen ist die Verwendung eines Cloudnetzwerks. In einem Rechenzentrum sind der Kauf einer Netzwerkinfrastruktur wie Router und Switches sowie die anschließende Installation einer geeigneten Netzwerkverkabelung einmalig anfallende Kosten. Danach können Sie die gesamte Netzwerkkapazität nutzen. In einer Cloudumgebung gibt es viele Möglichkeiten, wie die Netzwerknutzung in Rechnung gestellt werden kann. Bei datenintensiven Arbeitslasten oder solchen, die einen hohen Netzwerktraffic generieren, müssen Sie möglicherweise neue Architekturen und Netzwerkflüsse in Betracht ziehen, um die Netzwerkkosten in der Cloud zu senken.
Google Cloud bietet außerdem eine breite Palette von Optionen zur intelligenten Skalierung von Ressourcen und Kosten. In Compute Engine können Sie beispielsweise während der Migration mit Migrate for Compute Engine, nachdem VMs bereits ausgeführt werden oder beim Erstellen von Instanzgruppen mit Autoscaling Anpassungen vornehmen. Diese Optionen können einen großen Einfluss auf die Kosten für den Betrieb von Diensten haben und sollten genauer betrachtet werden, um die Gesamtbetriebskosten (TCO) zu berechnen.
Sie können den Preisrechner verwenden, um die Gesamtkosten der Google Cloud-Ressourcen zu berechnen.
Migrationsstrategie für Ihre Arbeitslasten auswählen
Bewerten Sie für jede zu migrierende Arbeitslast eine Migrationsstrategie und wählen Sie diejenige aus, die am besten zu ihrem Anwendungsfall passt. Für Ihre Arbeitslasten gelten beispielsweise die folgenden Bedingungen:
- Sie tolerieren keine Ausfallzeiten oder Datenverluste, z. B. bei geschäftskritischen Arbeitslasten. Für diese Arbeitslasten können Sie Migrationsstrategien mit einer Ausfallzeit von null oder nahezu null auswählen.
- Sie tolerieren Ausfallzeiten, z. B. bei sekundären oder Backend-Arbeitslasten. Für diese Arbeitslasten können Sie Migrationsstrategien auswählen, die eine Ausfallzeit erfordern.
Berücksichtigen Sie bei der Auswahl von Migrationsstrategien, dass Migrationsstrategien mit null oder nahezu null Ausfallzeiten in der Regel teurer und komplexer in der Entwicklung und Implementierung sind als Migrationsstrategien, die eine Ausfallzeit erfordern.
Auswahl der Tools für die Migration
Nachdem Sie eine Migrationsstrategie für Ihre Arbeitslasten ausgewählt haben, prüfen und entscheiden Sie sich für die Migrationstools.
Es gibt viele Migrationstools, die jeweils für bestimmte Migrationsanwendungsfälle optimiert sind. Anwendungsfälle können Folgendes umfassen:
- Migrationsstrategie
- Quell- und Zielumgebungen
- Daten- und Arbeitslastgröße
- Häufigkeit von Änderungen an Daten und Arbeitslasten
- Verfügbarkeit von verwalteten Diensten für die Migration
Für eine nahtlose Migration und Umstellung können Sie Anwendungsbereitstellungsmuster, Infrastrukturorchestrierung und benutzerdefinierte Migrationsanwendungen verwenden. Spezielle Tools, sogenannte verwaltete Migrationsdienste, können jedoch den Prozess der Migration von Daten, Arbeitslasten oder sogar ganzer Infrastrukturen von einer Umgebung in eine andere erleichtern. Mit diesen Funktionen kapseln sie die komplexe Logik der Migration ein und bieten Funktionen zur Überwachung der Migration.
Migrationsplan und Zeitplan definieren
Nachdem Sie einen umfassenden Überblick über Ihre aktuelle Umgebung erhalten haben, müssen Sie Ihren Migrationsplan vervollständigen. Gehen Sie dazu so vor:
- Gruppieren Sie die zu migrierenden Arbeitslasten und Daten in Batches (in einigen Kontexten auch Sprints genannt).
- Wählen Sie die Reihenfolge aus, in der die Batches migriert werden sollen.
- Die Reihenfolge festlegen, in der die Arbeitslasten innerhalb der einzelnen Batches migriert werden sollen.
Im Rahmen Ihres Migrationsplans empfehlen wir Ihnen, auch die folgenden Dokumente zu erstellen:
- Technisches Designdokument
- RACI-Matrix
- Zeitplan (z. B. ein T-Minus-Plan)
Wenn Sie mehr Erfahrung mit Google Cloud und der Migration sammeln und Ihre Umgebung besser kennen, können Sie Folgendes tun:
- Gruppieren Sie die zu migrierenden Arbeitslasten und Daten weiter.
- Erhöhen Sie die Größe der Migrationsbatches.
- Aktualisieren Sie die Reihenfolge, in der Sie Batches und Arbeitslasten innerhalb von Batches migrieren.
- Aktualisieren Sie die Zusammensetzung der Batches.
Um die zu migrierenden Arbeitslasten und Daten in Batches zu gruppieren und die Migrationsreihenfolge zu definieren, bewerten Sie Ihre Arbeitslasten anhand verschiedener Kriterien, z. B.:
- Geschäftswert der Arbeitslast.
- Bewertung, ob die Arbeitslast im Vergleich zur übrigen Infrastruktur auf spezifische Weise bereitgestellt oder ausgeführt wird
- Teams, die für die Entwicklung, Bereitstellung und den Betrieb der Arbeitslast verantwortlich sind
- Anzahl, Typ und Umfang der Abhängigkeiten der Arbeitslast
- Refaktorierungsaufwand, damit die Arbeitslast in der neuen Umgebung funktioniert
- Compliance- und Lizenzanforderungen der Arbeitslast.
- Verfügbarkeits- und Zuverlässigkeitsanforderungen der Arbeitslast.
Ihre Teams sammeln mit den Arbeitslasten, die Sie zuerst migrieren, Wissen und Erfahrung mit Google Cloud. Mehr Erfahrung im Umgang mit der Cloud verringert das Risiko von Komplikationen während der Migrationsphase Ihrer Migration. Außerdem sind nachfolgende Migrationen dann einfacher und schneller möglich. Aus diesem Grund ist die Entscheidung, welche Anwendungen zuerst migriert werden sollen, entscheidend für eine erfolgreiche Migration.
Nutzen für das Unternehmen
Wenn Sie eine Arbeitslast auswählen, die nicht geschäftskritisch ist, schützen Sie Ihre Hauptgeschäftssparte und verringern die Auswirkungen auf das Geschäft durch unentdeckte Risiken und Fehler. Außerdem bekommt Ihr Team Erfahrung mit Cloudtechnologien. Wenn Sie beispielsweise als zuerst zu migrierende Anwendung die Komponente auswählen, in der die Hauptlogik für Finanztransaktionen Ihrer E-Commerce-Arbeitslast implementiert ist, kann ein Fehler während der Migration Auswirkungen auf Ihr Hauptgeschäftsfeld haben. Eine bessere Wahl ist die SQL-Datenbank, die Ihre Arbeitslasten unterstützt, oder noch besser die Staging-Datenbank.
Sie sollten selten verwendete Arbeitslasten vermeiden. Wenn Sie beispielsweise eine Arbeitslast auswählen, die nur wenige Male pro Jahr von einer geringen Anzahl von Nutzern verwendet wird, auch wenn es sich um eine Migration mit geringem Risiko handelt, erhöht dies nicht die Dynamik Ihrer Migration. Außerdem kann es schwierig sein, Probleme zu erkennen und auf sie zu reagieren.
Sonderfälle
Sie sollten auch Grenzfälle vermeiden, damit Sie in dieser Migration typische Muster erkennen können, die Sie nach Möglichkeit auf die Migration anderer Arbeitslasten übertragen können. Ein Hauptziel bei der Auswahl zuerst zu migrierender Anwendungen ist es, Erfahrung mit gängigen Mustern in Ihrem Unternehmen zu bekommen, damit Sie eine Wissensbasis aufbauen können. Sie können das, was Sie bei den zuerst zu migrierenden Arbeitslasten gelernt haben, bei zukünftigen zu migrierenden Arbeitslasten einsetzen.
Wenn die meisten Ihrer Arbeitslasten beispielsweise nach der Methode der testgetriebenen Entwicklung entworfen und mit der Programmiersprache Python entwickelt wurden, können Sie mit einer Arbeitslast mit geringer Testabdeckung, die mit der Programmiersprache Java entwickelt wurde, kein Muster finden, das Sie bei der Migration der Python-Arbeitslasten anwenden können.
Teams
Achten Sie bei der Auswahl Ihrer zuerst zu migrierenden Arbeitslasten auf die Teams, die für die jeweilige Arbeitslast verantwortlich sind. Das Team, das für solch eine Anwendung verantwortlich ist, sollte hochmotiviert sein und Google Cloud und seine Dienste ausprobieren wollen. Darüber hinaus sollte die Unternehmensführung klare Ziele für diese Teams haben und sie während des Prozesses aktiv fördern und unterstützen.
Ein leistungsstarkes Team in der Zentrale, mit einer nachgewiesenen Erfahrung in der Implementierung moderner Entwicklungsverfahren wie DevOps und Disziplinen wie Site Reliability Engineering kann beispielsweise ein guter Kandidat sein. Wenn es in dem Team außerdem Führungspersönlichkeiten gibt und es klare Ziele für jede Arbeitslastmigration hat, könnte es sich hervorragend eignen.
Abhängigkeiten
Außerdem sollten Sie sich auf Arbeitslasten konzentrieren, die die geringste Anzahl von Abhängigkeiten haben, entweder von anderen Arbeitslasten oder von Diensten. Wenn Sie nur begrenzte Erfahrung mit Google Cloud haben, ist die Migration einer Arbeitslast ohne Abhängigkeiten einfacher.
Wenn Sie Arbeitslasten auswählen müssen, die Abhängigkeiten mit anderen Komponenten aufweisen, wählen Sie diejenigen aus, die nur lose mit ihren Abhängigkeiten verbunden sind. Wenn eine Arbeitslast bereits dafür entwickelt wurde, dass ihre Abhängigkeiten letztlich nicht verfügbar sind, lassen sich durch die Auswahl dieser Arbeitslast Beeinträchtigungen bei der Migration in die Zielumgebung verringern. Locker gekoppelte Kandidaten sind beispielsweise Arbeitslasten, die über einen Message Broker kommunizieren, offline arbeiten oder die die Nichtverfügbarkeit der übrigen Infrastruktur tolerieren sollen.
Obwohl es Strategien zum Migrieren von Daten zustandsorientierter Arbeitslasten gibt, erfordert eine zustandslose Arbeitslast selten eine Datenmigration. Das Migrieren einer zustandslosen Arbeitslast kann einfacher sein, da Sie sich keine Gedanken über eine Übergangsphase machen müssen, in der sich Daten teilweise in Ihrer aktuellen Umgebung und teilweise in Ihrer Zielumgebung befinden. Beispielsweise sind zustandslose Mikrodienste gute Anwendungen für eine erste Migration, da sie sich nicht auf lokale zustandsorientierte Daten stützen.
Refaktorierungsaufwand
Eine zuerst zu migrierende Anwendung sollte ein Minimum an Refaktorierung erfordern, damit Sie sich auf die Migration selbst und auf Google Cloud konzentrieren können, statt viel Aufwand in Änderungen am Code und die Konfiguration Ihrer Arbeitslasten investieren zu müssen. Die Refaktorierung sollte sich auf die notwendigen Änderungen konzentrieren, die es Ihren Arbeitslasten ermöglichen, in der Zielumgebung ausgeführt zu werden. Die Modernisierung und Optimierung Ihrer Arbeitslasten erfolgen dann in späteren Migrationsphasen.
Beispielsweise eignet sich eine Arbeitslast, für die nur Konfigurationsänderungen erforderlich sind, sehr gut für die erste Migration, da Sie keine Änderungen an der Codebasis vornehmen müssen und die vorhandenen Artefakte verwenden können.
Lizenzierung und Compliance
Lizenzen spielen auch bei der Auswahl der zuerst zu migrierenden Arbeitslasten eine Rolle, da einige davon möglicherweise unter Bedingungen lizenziert wurden, die sich auf Ihre Migration auswirken. Beispielsweise verbieten manche Lizenzen ausdrücklich die Ausführung von Arbeitslasten in einer Cloudumgebung.
Vergessen Sie bei der Prüfung der Lizenzbedingungen nicht die Complianceanforderungen, da einige Ihrer Arbeitslasten möglicherweise nur von einzelnen Mandanten verwendet werden dürfen. Aus diesen Gründen sollten Sie Arbeitslasten auswählen, für die die geringsten Lizenz- und Complianceeinschränkungen gelten.
Beispielsweise haben Ihre Kunden möglicherweise das gesetzliche Recht zu wählen, in welcher Region Sie ihre Daten speichern, oder die Daten Ihrer Kunden sind möglicherweise auf eine bestimmte Region beschränkt.
Verfügbarkeit und Zuverlässigkeit
Gute Anwendungen für eine erste Migration können Ausfallzeiten tolerieren, die durch einen Umstellungszeitraum verursacht werden. Wenn Sie sich für eine Arbeitslast mit strengen Verfügbarkeitsanforderungen entscheiden, müssen Sie eine Strategie für eine Datenmigration ohne Ausfallzeiten umsetzen, z. B. Y (Schreiben und Lesen) oder einen Datenzugriffsmikrodienst entwickeln. Diese Vorgehensweise ist zwar möglich, hält jedoch Ihre Teams davon ab, die erforderliche Erfahrung mit Google Cloud sammeln zu können, da sie Zeit für die Umsetzung solcher Strategien aufwenden müssen.
Beispielsweise können die Verfügbarkeitsanforderungen einer Batchverarbeitungs-Engine längere Ausfallzeiten tolerieren als die kundenbezogene Arbeitslast Ihrer E-Commerce-Website, in der Ihre Nutzer ihre Transaktionen abschließen.
Migrationsplan validieren
Bevor Sie mit der Umsetzung Ihres Migrationsplans beginnen, sollten Sie dessen Machbarkeit prüfen. Weitere Informationen finden Sie unter Best Practices zur Validierung eines Migrationsplans.
Nächste Schritte
- Migration planen und Ihre Grundlage in Google Cloud erstellen
- Hilfe für Migrationen erhalten
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.
Beitragende
Autor: Marco Ferrari | Cloud Solutions Architect