Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen

Last reviewed 2023-06-07 UTC

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 Anwendungen 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 Anwendungen und Arbeitslasten genau kennen.

Dieses Dokument ist Teil der folgenden mehrteiligen Reihe zur Migration zu Google Cloud:

Diese Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

Die Bewertungsphase ist die erste Phase der Migration zu Google Cloud. In dieser bestimmen Sie die Anforderungen und Abhängigkeiten, die für die Migration Ihrer Anwendungen zu Google Cloud gelten.

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.

Die Bewertungsphase ist für den Erfolg der Migration entscheidend. Sie benötigen umfassende Kenntnisse über die zu migrierenden Anwendungen, 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.

In dieser Phase führen Sie die folgenden Schritte aus:

  1. Ein umfassendes Inventar Ihrer Anwendungen erstellen.
  2. Die Anwendungen nach ihren Attributen und Abhängigkeiten katalogisieren.
  3. Die Teams auf Google Cloud vorbereiten.
  4. Einen Test und einen Proof of Concept für Google Cloud erstellen.
  5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
  6. Die Arbeitslasten auswählen, die als Erstes migriert werden sollen.

Inventar Ihrer Anwendungen erstellen

Um eine Migration durchführen zu können, müssen Sie als Erstes wissen, wie viele Elemente (z. B. Anwendungen 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 Anwendungen beschränkt sein, sondern mindestens Folgendes enthalten:

  • Abhängigkeiten der einzelnen Anwendungen, z. B. Datenbanken, Nachrichtenbroker, Konfigurationsspeichersysteme und andere Komponenten
  • Dienste, die Ihre Anwendungsinfrastruktur unterstützen, z. B. Quell-Repositories, CI-Tools (Continuous Integration) 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 verfügbar machen
  • Lizenzanforderungen für Software oder Hardware
  • Die Authentifizierung der Arbeitslast bei Ihrem Identitäts- und Zugriffsverwaltungssystem.

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 Anwendung 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 Anwendungen in einem automatisierten oder manuellen Bereitstellungsprozess.

Inventar erstellen

Es gibt verschiedene Möglichkeiten, ein Anwendungsinventar 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 auf falschen Annahmen beruhte.

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 Anwendungen finden Sie unter Migrationscenter: Asset-Erkennung starten.

Google arbeitet außerdem mit mehreren Unternehmen zusammen, um Sie bei Ihrer Migration zu unterstützen. Weitere Informationen finden Sie unter Hilfe.

Beispiel eines Anwendungsinventars

In diesem Beispiel wird eine Umgebung inventarisiert, die eine E-Commerce-Anwendung unterstützt. Das Inventar umfasst Hardware, Anwendungen, Abhängigkeiten sowie Dienste, die mehrere Anwendungen unterstützen.

Anwendungen

In der folgenden Tabelle werden für jede Anwendung 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-Anwendung Proprietäre Anwendung 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) Proprietäre Anwendung 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 Anwendungen. Diese Abhängigkeiten sind erforderlich, damit die Anwendungen 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 Anwendungen 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

Nachdem Sie das Inventare Ihrer Arbeitslasten erstellt haben, sollten Sie Ihre Bereitstellungs- und Betriebsprozesse bewerten. Ihre Bereitstellungs- und Betriebsprozesse sind ein grundlegender Teil der Praktiken, die die Produktionsumgebung und die dort ausgeführten Arbeitslasten vorbereiten und verwalten.

Diese Prozesse können die erforderliche Infrastruktur bereitstellen und die von Ihren Arbeitslasten benötigten Artefakte erstellen, z. B. Betriebssystempakete, Arbeitslastbereitstellungspakete, Betriebssystem-Images und Container-Images. Sammeln Sie für jede Arbeitslast Informationen darüber, wie viele Artefakte sie benötigt, der Typ der einzelnen Artefakte, wie Sie diese Artefakte erstellen, wie und wo Sie sie speichern und wie Sie Laufzeitkonfiguration neu einfügen, damit diese Artefakte in allen Umgebungen wiederverwendet werden können.

Nachdem Sie Ihre Bereitstellungs- und operativen Prozesse geprüft haben, sollten Sie auch prüfen, wie diese Prozesse Ihre Migration zu Google Cloud erleichtern und wie Sie damit den Umfang und das Risiko der Migration reduzieren können. Sie können beispielsweise die Prozesse für die Artefakterstellung refaktorieren, um Artefakte sowohl in Ihrer Quellumgebung als auch in Google Cloud zu speichern, während die Migration ausgeführt wird. Mit Artefakten in beiden Umgebungen können Sie sich auf die Migration Ihrer Arbeitslasten und Daten aus der Quellumgebung zu Google Cloud konzentrieren, ohne Artefakt-Build-Prozesse von Anfang des Migrationsprozess an in der Google Cloud-Zielumgebung implementieren zu müssen.

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 für die Bewertung dieser Infrastruktur Folgendes:

  • Die Prozesse, die Sie zur Bereitstellung der von der Arbeitslast benötigten Ressourcen verwendet haben, z. B. Infrastruktur als Code.
  • Wie Sie Ressourcen in Ihrer Quellumgebung organisiert haben. Einige Umgebungen unterstützen beispielsweise eine logische Trennung zwischen Ressourcen mithilfe von Konstrukten, die Ressourcengruppen wie Organisationen und Projekte voneinander isolieren.
  • Wie Sie Ihre Umgebung mit anderen Umgebungen verbunden haben, z. B. lokalen Umgebungen und anderen Cloud-Anbietern

Anwendungen kategorisieren

Nachdem Sie das Inventar abgeschlossen haben, müssen Sie Ihre Anwendungen in verschiedene Kategorien unterteilen. Mithilfe dieser Kategorisierung können Sie die Prioritäten für die Migration der Anwendungen 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 Anwendung benötigt. Beispielsweise könnte es Sie interessieren, ob eine Anwendung 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 Anwendung einen Indikator für die Komplexität der Migration einfügen. Dieser Indikator dient als Schätzung des Schwierigkeitsgrads für die Migration jeder Anwendung. 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 Anwendungen finden Sie unter Migrationscenter: Asset-Erkennung starten.

Beispiel eines Anwendungskatalogs

In diesem Beispiel werden die folgenden Bewertungskriterien verwendet, eine für jede Matrixachse:

  1. Wie wichtig eine Anwendung für das Unternehmen ist.
  2. Ob eine Anwendung Abhängigkeiten hat oder für andere Anwendungen eine Abhängigkeit ist.
  3. Maximal zulässige Ausfallzeit für die Anwendung
  4. Der Schwierigkeitsgrad der Migration einer Anwendung.
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-Anwendung 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:

Diagramm zur Darstellung des Schwierigkeitsgrads beim Verschieben von Anwendungen nach Google Cloud.

In der obigen Tabelle sind die meisten Anwendungen 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 praktische Erfahrungen sammeln 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:

  1. Öffentliche und offene Ressourcen: Kostenlose praktische Labs, Videoreihen, Cloud OnAir-Webinare und Cloud OnBoard-Schulungsveranstaltungen bieten einen Einstieg in Google Cloud.
  2. 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.
  3. Rollenbasierte Lernpfade: Sie können Ihre Entwickler entsprechend ihrer Rolle in der Organisation ausbilden. Beispielsweise können Sie in Schulungen Ihren Anwendungsentwicklern 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:

  1. Associate-Zertifizierungen: Ein Start für Google Cloud-Neulinge, der Zugang zu professionellen Zertifizierungen wie der Zertifizierung als Associate Cloud Engineer bieten kann.
  2. 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.
  3. Zertifizierungen für Google Workspace: Mit dieser Zertifizierung für Google Workspace können Sie die Fähigkeiten der Zusammenarbeit mit Google Workspace demonstrieren.
  4. 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.
  5. 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.

Proofs of Concept ausprobieren und erstellen

Sie sollten in Ihrem Anwendungskatalog einen oder mehrere Proofs of Concept (PoCs) pro Anwendungskategorie 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 Anwendungen unterstützten Anwendungsfälle, einschließlich seltener und Sonderfälle.
  • Alle Anforderungen für jeden Anwendungsfall, z. B. Leistungs- und Skalierbarkeitsanforderungen, erwartete Konsistenzgarantien, 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 Anwendungen schnell skaliert werden können, um Anfragespitzen gerecht zu werden. 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 Anwendung um 95 % im Vergleich zu Ihrer aktuellen Umgebung, kann dies sofortigen geschäftlichen Nutzen bedeuten.

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. Für datenintensive Anwendungen oder solche, 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.

Anwendungen auswählen, die zuerst migriert werden sollen

Nachdem Sie einen umfassenden Überblick über Ihre aktuelle Umgebung erhalten haben, müssen Sie Ihren Migrationsplan vervollständigen. Wählen Sie dazu die ursprüngliche Reihenfolge aus, in der Sie Ihre Anwendungen migrieren möchten. Sie können diese Reihenfolge während der Migration optimieren, wenn Sie sich besser mit Google Cloud auskennen und Ihre Umgebung und Anwendungen verstehen.

Ihre Teams sammeln mit den Anwendungen, 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. Sie können dafür eine Anwendung auswählen oder mehrere Anwendungen aus Ihrer Anwendungsmatrix in die Liste der zuerst zu migrierenden Anwendungen aufnehmen.

Die zuerst zu migrierenden Anwendungen auszuwählen, ist eine komplexe Aufgabe. Die folgenden Kriterien können Ihnen aber bei der Entscheidung helfen:

  • Nutzen der Anwendung für das Unternehmen
  • Bewertung, ob die Anwendung im Vergleich zur übrigen Infrastruktur auf spezifische Weise bereitgestellt oder ausgeführt wird
  • Teams, die für die Entwicklung, Bereitstellung und den Betrieb der Anwendung verantwortlich sind
  • Anzahl, Typ und Umfang der Abhängigkeiten der Anwendung
  • Refaktorierungsaufwand, damit die Anwendung in der neuen Umgebung funktioniert
  • Compliance- und Lizenzanforderungen der Anwendung
  • Verfügbarkeits- und Zuverlässigkeitsanforderungen der Anwendung

Stellenwert für das Unternehmen

Wenn Sie eine Anwendung 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-Anwendung implementiert ist, kann ein Fehler während der Migration Auswirkungen auf Ihr Hauptgeschäftsfeld haben. Eine bessere Wahl ist die SQL-Datenbank, die Ihre Anwendungen unterstützt, oder noch besser die Staging-Datenbank.

Sie sollten selten genutzte Anwendungen vermeiden. Wenn Sie beispielsweise eine Anwendung 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.

Grenzfä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 Anwendungen ü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 Anwendungen gelernt haben, bei zukünftigen zu migrierenden Anwendungen einsetzen.

Beispiel: Die meisten Ihrer Anwendungen werden nach einer testbasierten Entwicklungsmethode entworfen und mit der Programmiersprache Python entwickelt. Wenn Sie aber eine Anwendung mit geringer Testabdeckung auswählen, die mit der Programmiersprache Java entwickelt wurde, können Sie kein Muster erkennen, das auf die Migration der Python-Anwendungen übertragbar ist.

Teams

Achten Sie bei der Auswahl Ihrer zuerst zu migrierenden Anwendungen auf die Teams, die für die jeweilige Anwendung verantwortlich sind. Das für eine zuerst zu migrierende Anwendung verantwortliche Team sollte hoch motiviert und gerne bereit sein, Google Cloud und dessen Dienste einzusetzen. 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 Anwendungsmigration hat, könnte es sich hervorragend eignen.

Abhängigkeiten

Außerdem sollten Sie sich auf Anwendungen konzentrieren, die die geringste Anzahl von Abhängigkeiten haben, entweder von anderen Anwendungen oder von Diensten. Wenn Sie nur begrenzte Erfahrung mit Google Cloud haben, ist die Migration einer Anwendung ohne Abhängigkeiten einfacher.

Wenn Sie Anwendungen 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 Anwendung bereits dafür entwickelt wurde, dass ihre Abhängigkeiten letztlich nicht verfügbar sind, lassen sich durch die Auswahl dieser Anwendung Beeinträchtigungen bei der Migration in die Zielumgebung verringern. Locker gekoppelte Kandidaten sind beispielsweise Anwendungen, 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 Anwendungen gibt, erfordert eine zustandslose Anwendung selten eine Datenmigration. Das Migrieren einer zustandslosen Anwendung 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 Anwendungen investieren zu müssen. Die Refaktorierung sollte sich auf die notwendigen Änderungen konzentrieren, die es Ihren Anwendungen ermöglichen, in der Zielumgebung ausgeführt zu werden. Die Modernisierung und Optimierung Ihrer Anwendungen erfolgen dann in späteren Migrationsphasen.

Beispielsweise eignet sich eine Anwendung, 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 Anwendungen 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 Anwendungen in einer Cloudumgebung.

Vergessen Sie bei der Prüfung der Lizenzbedingungen nicht die Complianceanforderungen, da einige Ihrer Anwendungen möglicherweise nur von einzelnen Mandanten verwendet werden dürfen. Aus diesen Gründen sollten Sie Anwendungen 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 Anwendung 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 Anwendung Ihrer E-Commerce-Site, in der Ihre Nutzer ihre Transaktionen beenden.

Nächste Schritte