Hybrid- und Multi-Cloud-Architekturen mit Google Cloud erstellen

Last reviewed 2023-12-14 UTC

Dieser Architekturleitfaden bietet praktische Anleitungen zur Planung und Architektur Ihrer Hybrid- und Multi-Cloud-Umgebungen mit Google Cloud. Dieses Dokument ist das erste von drei Dokumenten im Set. Es werden die Chancen und Überlegungen untersucht, die mit diesen Architekturen aus geschäftlicher und technologischer Sicht verbunden sind. Außerdem werden viele bewährte Hybrid- und Multi-Cloud-Architekturmuster analysiert und besprochen.

Der Dokumentensatz für Hybrid- und Multi-Cloud-Architekturmuster besteht aus den folgenden Teilen:

  • Hybrid- und Multi-Cloud-Architekturen erstellen: Hier erfahren Sie, wie Sie eine Strategie für die Entwicklung einer Hybrid- und Multi-Cloud-Einrichtung mit Google Cloud planen (dieser Artikel).
  • Hybrid- und Multi-Cloud-Architekturmuster: Hier erfahren Sie mehr über gängige Architekturmuster, die Sie im Rahmen einer Hybrid- und Multi-Cloud-Strategie verwenden können.
  • Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke: Hier werden Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke aus Netzwerkperspektive besprochen.

Sie können jeden dieser Architekturartikel unabhängig voneinander lesen. Wir empfehlen jedoch, sie in der richtigen Reihenfolge zu lesen, bevor Sie eine architektonische Entscheidung treffen.

Die rasante Veränderung der Marktanforderungen hat die Anforderungen und Erwartungen an die Unternehmens-IT erhöht, z. B. dynamische Skalierung, erhöhte Leistung für eine optimierte Nutzererfahrung und Sicherheit. Viele Unternehmen auf Unternehmensebene finden es schwierig, diese Anforderungen und Erwartungen nur mithilfe traditioneller Infrastrukturen und Prozesse zu erfüllen. IT-Abteilungen stehen außerdem unter Druck, ihre Kosteneffizienz zu steigern, was die Rechtfertigung zusätzlicher Investitionsausgaben in Rechenzentren und Geräte erschwert.

Eine Hybrid-Cloud-Strategie, die die Funktionen des öffentlichen Cloud-Computings nutzt, ist eine pragmatische Lösung. Durch Nutzung der öffentlichen Cloud können Sie die Kapazitäten und Möglichkeiten Ihrer Computing-Plattformen ohne Investitionen im Vorfeld ausbauen.

Wenn Sie Ihre vorhandene Infrastruktur um eine oder mehrere öffentlich zugängliche Cloud-basierte Lösungen wie Google Cloud erweitern, schützen Sie nicht nur Ihre vorhandenen Investitionen, sondern vermeiden auch die Abhängigkeit von einem einzigen Cloud-Anbieter. Außerdem lassen sich bei Verwendung einer Hybridstrategie Anwendungen und Prozesse schrittweise modernisieren, soweit es die Mittel erlauben.

Um Ihnen bei der Planung Ihrer Architekturentscheidung und der Hybrid- oder Multi-Cloud-Strategieplanung zu helfen, sollten Sie mehrere potenzielle Herausforderungen und Designüberlegungen berücksichtigen. In diesem mehrteiligen Architekturleitfaden werden sowohl die potenziellen Vorteile verschiedener Architekturen als auch die potenziellen Herausforderungen hervorgehoben.

Hybrid-Cloud und Multi-Cloud – Übersicht

Da Arbeitslasten, Infrastruktur und Prozesse in jedem Unternehmen anders sind, muss jede Hybrid-Cloud-Strategie an Ihre spezifischen Anforderungen angepasst werden. Diesem Umstand ist es geschuldet, dass die Begriffe Hybrid-Cloud und Multi-Cloud manchmal nicht einheitlich verwendet werden.

Im Kontext dieses Google Cloud-Architekturleitfadens beschreibt der Begriff Hybrid-Cloud eine Architektur, in der Arbeitslasten in mehreren Rechenumgebungen bereitgestellt werden, von denen eine in der öffentlichen Cloud und mindestens eine andere privat ist, z. B. ein lokales Rechenzentrum oder eine Colocation-Einrichtung.

Der Begriff Multi-Cloud beschreibt eine Architektur, die mindestens zwei öffentliche Cloud-Dienstanbieter kombiniert. Wie im folgenden Diagramm dargestellt, enthält diese Architektur manchmal eine private Rechenumgebung, die die Verwendung einer privaten Cloud-Komponente umfassen kann. Diese Anordnung wird als Hybrid- und Multi-Cloud-Architektur bezeichnet.

Diagramm der drei in dieser Reihe beschriebenen Architekturen: Hybrid-, Multi-Cloud- und eine Mischung aus Hybrid- und Multi-Cloud-Architekturen.

Beitragende

Autor: Marwan Al Shawi | Partner Customer Engineer

Weitere Beitragende:

Treiber, Überlegungen, Strategie und Ansätze

In diesem Dokument werden Geschäftsziele, Treiber und Anforderungen definiert und erläutert. Außerdem wird beschrieben, wie diese Faktoren Ihre Designentscheidungen beim Erstellen von Hybrid- und Multi-Cloud-Architekturen beeinflussen können.

Ziele

Eine Organisation kann eine Hybrid- oder Multi-Cloud-Architektur entweder als dauerhafte Lösung zur Erreichung bestimmter Geschäftsziele oder als vorübergehenden Zustand zur Erfüllung bestimmter Anforderungen wie einer Migration in die Cloud einführen.

Wenn Sie die folgenden Fragen zu Ihrem Unternehmen beantworten, können Sie Ihre Geschäftsanforderungen definieren und konkrete Erwartungen an die Erreichung einiger oder aller Ihrer Geschäftsziele festlegen. Bei diesen Fragen geht es darum, was für Ihr Unternehmen erforderlich ist, nicht darum, wie dies technisch erreicht werden kann.

  • Welche Geschäftsziele sind ausschlaggebend für die Entscheidung, eine Hybrid- oder Multi-Cloud-Architektur zu verwenden?
  • Welche Geschäfts- und technischen Ziele können mit einer Hybrid- oder Multi-Cloud-Architektur erreicht werden?
  • Welche geschäftlichen Faktoren haben diese Ziele beeinflusst?
  • Was sind die spezifischen Geschäftsanforderungen?

Im Kontext von Hybrid- und Multi-Cloud-Architekturen könnte ein Geschäftsziel für einen Enterprise-Kunden darin bestehen, den Onlineverkauf oder die Märkte aus einer einzelnen Region auszuweiten, um zu einem der globalen Marktführer in seinem Segment zu werden. Eines der Geschäftsziele könnte sein, innerhalb von sechs Monaten Bestellungen von Nutzern auf der ganzen Welt (oder aus bestimmten Regionen) anzunehmen.

Um die zuvor genannten Geschäftsanforderungen und -ziele zu unterstützen, besteht ein mögliches primäres technisches Ziel darin, die IT-Infrastruktur und die Anwendungsarchitektur eines Unternehmens von einem reinen On-Premises-Modell zu einer Hybridarchitektur zu erweitern, indem die globalen Funktionen und Dienste öffentlicher Clouds genutzt werden. Dieses Ziel sollte spezifisch und messbar sein und den Umfang der Expansion in Bezug auf Zielregionen und Zeitpläne klar definieren.

Im Allgemeinen ist eine Hybrid- oder Multi-Cloud-Architektur selten ein Ziel an sich, sondern vielmehr ein Mittel, um technische Ziele zu erreichen, die sich aus bestimmten Geschäftsanforderungen ergeben. Daher müssen zur Auswahl der richtigen Hybrid- oder Multi-Cloud-Architektur zuerst diese Anforderungen geklärt werden.

Es ist wichtig, zwischen den Geschäftszielen und den technischen Zielen Ihres IT-Projekts zu unterscheiden. Ihre Geschäftsziele sollten sich auf das Ziel und den Zweck Ihrer Organisation konzentrieren. Ihre technischen Ziele sollten sich darauf konzentrieren, eine technologische Grundlage zu schaffen, mit der Ihr Unternehmen seine Geschäftsanforderungen und -ziele erfüllen kann.

Geschäftstreiber beeinflussen die Erreichung der Geschäftsziele. Daher können Sie die Geschäftsziele so formulieren, dass sie besser zu den Marktanforderungen und -trends passen, wenn Sie die Geschäftstreiber klar identifizieren.

Das folgende Flussdiagramm veranschaulicht die Geschäftstreiber, Ziele, Zielvorhaben und Anforderungen sowie die technischen Zielvorhaben und Anforderungen und wie sich all diese Faktoren gegenseitig beeinflussen:

Flussdiagramm mit den wichtigsten Aspekten, die bei der Entwicklung technischer Anforderungen zu berücksichtigen sind, einschließlich Geschäftstreiber, Ziele, Anforderungen und technischer Ziele.

Geschäfts- und technische Treiber

Überlegen Sie, wie sich Ihre Geschäftstreiber auf Ihre technischen Ziele auswirken. Zu den häufigsten geschäftlichen Faktoren, die bei der Auswahl einer Hybridarchitektur eine Rolle spielen, gehören:

  • Einhaltung von Gesetzen und Vorschriften zur Datenhoheit
  • Reduzierung der Kapitalausgaben (CAPEX) oder der allgemeinen IT-Ausgaben mithilfe von Cloud-Finanzmanagement und Kostenoptimierungsmethoden wie FinOps.
    • Die Cloud-Nutzung kann durch Szenarien vorangetrieben werden, die zur Senkung der CAPEX beitragen, z. B. die Erstellung einer Notfallwiederherstellungslösung in einer Hybrid- oder Multi-Cloud-Architektur.
  • Verbesserung des Nutzererlebnisses.
  • Steigerung der Flexibilität und der Reaktionsfähigkeit auf wechselnde Marktbedürfnisse.
  • Erhöhung der Transparenz in Bezug auf Kosten und Ressourcenverbrauch.

Sehen Sie sich Ihre Liste der geschäftlichen Gründe für die Einführung einer Hybrid- oder Multi-Cloud-Architektur an. Sie sollten sie nicht getrennt voneinander betrachten. Ihre endgültige Entscheidung sollte von der Balance Ihrer Geschäftsprioritäten abhängen.

Nachdem Ihre Organisation die Vorteile der Cloud erkannt hat, kann sie sich für eine vollständige Migration entscheiden, sofern keine Einschränkungen wie Kosten oder spezifische Compliance-Anforderungen vorliegen, die eine solche Migration verhindern.

Die Nutzung eines einzigen Cloud-Anbieters kann zwar mehrere Vorteile bieten, z. B. reduzierte Komplexität, integrierte Integrationen zwischen Diensten und Optionen zur Kostenoptimierung wie Rabatte für die nutzungsgebundene Laufzeit, es gibt jedoch einige Szenarien, in denen eine Multi-Cloud-Architektur für ein Unternehmen von Vorteil sein kann. Im Folgenden finden Sie die häufigsten geschäftlichen Gründe für die Einführung einer Multi-Cloud-Architektur sowie die zugehörigen Überlegungen für jeden Faktor:

  • Einhaltung von Gesetzen und Vorschriften zur Datenhoheit: Das häufigste Szenario ist, wenn ein Unternehmen sein Geschäft in eine neue Region oder ein neues Land ausweitet und neue Vorschriften für das Hosting von Daten einhalten muss.
    • Wenn der verwendete Cloud-Dienstanbieter (Cloud Service Provider, CSP) keine lokale Cloud-Region in diesem Land hat, wird aus Compliance-Gründen häufig ein anderer CSP mit einer lokalen Cloud-Region in diesem Land verwendet.
  • Kosten senken: Die Kostensenkung ist oft der häufigste geschäftliche Grund für die Einführung einer Technologie oder Architektur. Bei der Entscheidung, ob eine Multi-Cloud-Architektur eingeführt werden soll, sollten Sie jedoch nicht nur die Kosten für die Dienste und mögliche Preisnachlässe berücksichtigen. Berücksichtigen Sie die Kosten für die Erstellung und den Betrieb einer Lösung in mehreren Clouds sowie alle Architektureinschränkungen, die sich aus vorhandenen Systemen ergeben.

Manchmal überwiegen die potenziellen Herausforderungen einer Multi-Cloud-Strategie die Vorteile. Eine Multi-Cloud-Strategie kann später zu zusätzlichen Kosten führen.

Zu den häufigen Herausforderungen bei der Entwicklung einer Multi-Cloud-Strategie gehören:

  • Die Verwaltung wird immer komplexer.
  • Kontinuierliche Sicherheit.
  • Softwareumgebungen integrieren.
  • Cloudübergreifende Leistung und Zuverlässigkeit.
  • Die Zusammenstellung eines technischen Teams mit Multi-Cloud-Kompetenzen kann teuer sein und das Team muss möglicherweise erweitert werden, es sei denn, es wird von einem Drittanbieter verwaltet.
  • Preis- und Verwaltungstools der einzelnen Anbieter verwalten.
  • Die einzigartigen Funktionen der einzelnen Cloud-Anbieter nutzen: Mit einer Multi-Cloud-Architektur können Unternehmen zusätzliche neue Technologien nutzen, um ihre eigenen Geschäftsfunktionen zu verbessern, ohne auf die Auswahl eines einzelnen Cloud-Anbieters beschränkt zu sein.
    • Um unvorhergesehene Risiken oder Komplexitäten zu vermeiden, sollten Sie Ihre potenziellen Herausforderungen anhand einer Machbarkeits- und Effektivitätsbewertung bewerten, einschließlich der oben genannten häufigen Herausforderungen.
  • Vermeidung von Anbieterabhängigkeit: Manchmal möchten Unternehmen nicht an einen einzelnen Cloud-Anbieter gebunden sein. Mit einem Multi-Cloud-Ansatz können sie die beste Lösung für ihre Geschäftsanforderungen auswählen. Die Umsetzbarkeit dieser Entscheidung hängt jedoch von mehreren Faktoren ab, z. B.:
    • Technische Abhängigkeiten
    • Interoperabilität zwischen Anwendungen
    • Kosten für das Neuaufbauen oder Refaktorisieren von Anwendungen
    • Technische Kompetenzen
    • Einheitliche Sicherheit und Verwaltungsfreundlichkeit
  • Höhere Zuverlässigkeit und Verfügbarkeit geschäftskritischer Anwendungen: In einigen Fällen kann eine Multi-Cloud-Architektur Ausfallsicherheit bieten. Wenn beispielsweise eine Region eines Cloud-Dienstanbieters ausfällt, kann der Traffic an einen anderen Cloud-Dienstanbieter in derselben Region weitergeleitet werden. In diesem Szenario wird davon ausgegangen, dass beide Cloud-Anbieter die erforderlichen Funktionen oder Dienste in dieser Region unterstützen.

Wenn Vorschriften zum Datenstandort in einem bestimmten Land oder einer bestimmten Region die Speicherung vertraulicher Daten wie personenidentifizierbarer Informationen an diesem Standort vorschreiben, kann ein Multi-Cloud-Ansatz eine richtlinienkonforme Lösung bieten. Wenn Sie zwei Cloud-Dienstanbieter in einer Region verwenden, um Ausfallsicherheit zu gewährleisten, können Sie die Einhaltung behördlicher Einschränkungen erleichtern und gleichzeitig die Verfügbarkeitsanforderungen erfüllen.

Bevor Sie eine Multi-Cloud-Architektur einführen, sollten Sie die folgenden Aspekte zur Resilienz berücksichtigen:

  • Datenübertragung: Wie oft werden Daten in Ihrer Multi-Cloud-Umgebung verschoben?
    • Können beim Verschieben von Daten erhebliche Kosten für die Datenübertragung anfallen?
  • Sicherheit und Verwaltbarkeit: Gibt es potenzielle Sicherheitsrisiken oder Probleme bei der Verwaltbarkeit?
  • Funktionsübereinstimmung: Bieten beide CSPs in der ausgewählten Region die erforderlichen Funktionen und Dienste an?
  • Technisches Know-how: Verfügt das technische Team über die erforderlichen Fähigkeiten, um eine Multi-Cloud-Architektur zu verwalten?

Berücksichtigen Sie alle diese Faktoren, wenn Sie die Machbarkeit einer Multi-Cloud-Architektur zur Verbesserung der Ausfallsicherheit bewerten.

Bei der Bewertung der Durchführbarkeit einer Multi-Cloud-Architektur sind die langfristigen Vorteile zu berücksichtigen. Die Bereitstellung von Anwendungen in mehreren Clouds für die Notfallwiederherstellung oder die Erhöhung der Zuverlässigkeit kann beispielsweise die Kosten kurzfristig erhöhen, aber Ausfälle oder Fehler verhindern. Solche Fehler können zu langfristigen finanziellen und Reputationsschäden führen. Daher ist es wichtig, die kurzfristigen Kosten gegen den langfristigen potenziellen Wert der Einführung von Multi-Cloud abzuwägen. Außerdem kann der langfristige potenzielle Wert je nach Größe des Unternehmens, Umfang der Technologie, Wichtigkeit der Technologielösung und Branche variieren.

Organisationen, die eine Hybrid- oder Multi-Cloud-Umgebung erfolgreich einrichten möchten, sollten ein Cloud Cloud-Kompetenzzentrum (COE) einrichten. Ein COE-Team kann die Art und Weise verändern, wie interne Teams in Ihrem Unternehmen das Unternehmen während der Umstellung auf die Cloud unterstützen. Ein COE ist eine der Möglichkeiten, wie Ihr Unternehmen die Cloud schneller einführen, die Standardisierung vorantreiben und eine engere Abstimmung zwischen Ihrer Geschäftsstrategie und Ihren Cloud-Investitionen erreichen kann.

Wenn das Ziel der Hybrid- oder Multi-Cloud-Architektur darin besteht, einen vorübergehenden Zustand zu schaffen, sind häufige geschäftliche Treiber:

  • Die Notwendigkeit, die CAPEX- oder allgemeinen IT-Ausgaben für kurzfristige Projekte zu senken.
  • Die Möglichkeit, eine solche Infrastruktur schnell bereitzustellen, um einen Geschäftsfall zu unterstützen. Beispiel:
    • Diese Architektur kann für zeitlich begrenzte Projekte verwendet werden. Sie kann für ein Projekt verwendet werden, das eine verteilte Infrastruktur im großen Maßstab innerhalb eines begrenzten Zeitraums erfordert, während gleichzeitig lokal verfügbare Daten verwendet werden.
  • Die Notwendigkeit mehrjähriger digitaler Transformationsprojekte, die von einem großen Unternehmen eingerichtet werden müssen und für die eine Hybridarchitektur verwendet wird, um die Modernisierung der Infrastruktur und Anwendungen an die Geschäftsprioritäten anzupassen.
  • Die Notwendigkeit, nach einer Unternehmensfusion eine vorübergehende Hybrid-, Multi-Cloud- oder Mischarchitektur zu erstellen. So kann die neue Organisation eine Strategie für den Endzustand ihrer neuen Cloud-Architektur definieren. Es ist üblich, dass zwei fusionierende Unternehmen unterschiedliche Cloud-Anbieter nutzen oder dass ein Unternehmen ein lokales privates Rechenzentrum und das andere die Cloud verwendet. In beiden Fällen besteht der erste Schritt bei Fusionen und Übernahmen fast immer in der Integration der IT-Systeme.

Technische Treiber

Im vorherigen Abschnitt wurden die Geschäftstreiber besprochen. Für die Genehmigung wichtiger architektonischer Entscheidungen ist fast immer die Unterstützung dieser Treiber erforderlich. Technische Treiber, die entweder auf einem technischen Vorteil oder einer Einschränkung beruhen, können jedoch auch geschäftliche Treiber beeinflussen. In einigen Fällen ist es erforderlich, technische Treiber in Geschäftstreiber umzuwandeln und zu erklären, wie sie sich positiv oder negativ auf das Unternehmen auswirken können.

Die folgende Liste enthält einige gängige technische Gründe für die Einführung einer Hybrid- oder Multi-Cloud-Architektur:

  • Erweiterung der technologischen Ressourcen, beispielsweise auf komplexe Analysedienste und KI, die in vorhandenen Umgebungen möglicherweise schwer zu implementieren sind
  • Verbesserung der Qualität und Leistung von Diensten
  • Automatisierung und Beschleunigung von Anwendungs-Rollouts, um eine schnellere Markteinführung und kürzere Zykluszeiten zu erreichen.
  • Nutzung von High-Level-APIs und -Diensten, um die Entwicklung zu beschleunigen.
  • Beschleunigung der Bereitstellung von Rechen- und Speicherressourcen
  • Mit serverlosen Diensten lassen sich elastische Dienste und Funktionen schneller und in großem Umfang erstellen.
  • Globale Infrastrukturfunktionen nutzen, um globale oder mehrregionale Architekturen zu erstellen, die bestimmte technische Anforderungen erfüllen.

Der häufigste technische Grund für sowohl temporäre Hybrid- als auch temporäre Multi-Cloud-Architekturen ist die Erleichterung einer Migration von On-Premises-Umgebungen in die Cloud oder in eine zusätzliche Cloud. Im Allgemeinen führen Cloud-Migrationen fast immer zu einer Hybrid-Cloud-Einrichtung. Unternehmen müssen Anwendungen und Daten häufig basierend auf ihren Prioritäten systematisch umstellen. Ebenso kann eine kurzfristige Einrichtung dazu dienen, einen Proof of Concept mithilfe fortschrittlicher Technologien zu erstellen, die für einen bestimmten Zeitraum in der Cloud verfügbar sind.

Technische Designentscheidungen

Das identifizierte technische Ziel und seine Treiber sind entscheidend für die geschäftsorientierte Architekturentscheidung und die Auswahl eines der in diesem Leitfaden beschriebenen Architekturmuster. Um beispielsweise ein bestimmtes Geschäftsziel zu unterstützen, könnte ein Unternehmen das Ziel festlegen, für drei bis sechs Monate eine Forschungs- und Entwicklungspraxis aufzubauen. Die wichtigste Geschäftsanforderung zur Unterstützung dieses Ziels besteht darin, die erforderliche Technologieumgebung für Forschung und Design mit den geringstmöglichen CAPEX zu erstellen.

Das technische Ziel besteht in diesem Fall darin, eine vorübergehende Hybrid-Cloud-Umgebung einzurichten. Der Treiber für dieses technische Ziel ist die Nutzung des On-Demand-Preismodells der Cloud, um die zuvor genannte Geschäftsanforderung zu erfüllen. Ein weiterer Faktor ist die spezifische Technologieanforderung, die eine cloudbasierte Lösung mit hoher Rechenleistung und schneller Einrichtung erfordert.

Google Cloud für Hybrid- und Multi-Cloud-Architekturen verwenden

Open-Source-Lösungen können die Einführung eines Hybrid- und Multi-Cloud-Ansatzes erleichtern und die Anbieterabhängigkeit minimieren. Bei der Planung einer Architektur sollten Sie jedoch die folgenden potenziellen Komplexitäten berücksichtigen:

  • Interoperabilität
  • Verwaltung
  • Kosten
  • Sicherheit

Wenn Sie auf einer Cloud-Plattform aufbauen, die zu Open Source beiträgt und diese unterstützt, kann dies den Übergang zu Hybrid- und Multi-Cloud-Architekturen vereinfachen. Die offene Cloud bietet Ihnen einen Ansatz, der maximale Auswahlmöglichkeiten bietet und Komplexität abstrahiert. Darüber hinaus bietet Ihnen Google Cloud die Flexibilität, Anwendungen in Hybrid- und Multi-Cloud-Umgebungen zu migrieren, zu erstellen und zu optimieren und gleichzeitig die Anbieterabhängigkeit zu reduzieren, branchenführende Lösungen zu nutzen und behördliche Anforderungen zu erfüllen.

Google leistet einen signifikanten Beitrag zum Open-Source-Ökosystem und arbeitet mit der Open-Source-Community zusammen, um bekannte Open-Source-Technologien wie Kubernetes zu entwickeln. Wenn Kubernetes als verwalteter Dienst bereitgestellt wird, kann dies die Komplexität der Verwaltung und Sicherheit von Hybrid- und Multi-Cloud-Umgebungen verringern.

Hybrid- und Multi-Cloud-Strategie planen

In diesem Dokument geht es darum, wie Sie vordefinierte Geschäftsaspekte bei der Planung einer Hybrid- und Multi-Cloud-Strategie anwenden. Er erweitert die Informationen unter Erfolgsfaktoren, Überlegungen, Strategie und Ansätze. In diesem Artikel werden die Geschäftsaspekte definiert und analysiert, die Unternehmen bei der Planung einer solchen Strategie berücksichtigen sollten.

Vision und Ziele klären und vereinbaren

Der Hauptzweck einer Hybrid- oder Multi-Cloud-Strategie besteht letztendlich darin, die identifizierten Geschäftsanforderungen und die zugehörigen technischen Ziele für jeden Geschäftsfall zu erreichen, der mit bestimmten Geschäftszielen übereinstimmt. Um dieses Ziel zu erreichen, erstellen Sie einen gut strukturierten Plan, der die folgenden Aspekte berücksichtigt:

Die Ausarbeitung eines Plans, der alle Arbeitslasten und Anforderungen berücksichtigt, ist in diesem Netz von Abhängigkeiten und Beschränkungen bestenfalls schwierig, insbesondere in einer komplexen IT-Umgebung. Darüber hinaus erfordert die Planung Zeit und kann zu konkurrierenden Visionen der Stakeholder führen.

Um solche Situationen zu vermeiden, sollten Sie zuerst eine Visionsbeschreibung formulieren, die mindestens die folgenden Fragen beantwortet:

  • Welchen Geschäftsfall möchten Sie mit dem Tool lösen, um bestimmte Geschäftsziele zu erreichen?
  • Warum reichen der aktuelle Ansatz und die aktuelle Rechenumgebung nicht aus, um die Geschäftsziele zu erreichen?
  • Welche technologischen Aspekte sollten mithilfe der öffentlichen Cloud optimiert werden?
  • Warum und wie wird der neue Ansatz Ihre Geschäftsziele optimieren und erreichen?
  • Wie lange möchten Sie Ihre Hybrid- oder Multi-Cloud-Umgebung verwenden?

Die Einigung auf die wichtigsten Geschäfts- und technischen Ziele und Treiber und die anschließende Zustimmung der relevanten Stakeholder können eine Grundlage für die nächsten Schritte im Planungsprozess bilden. Damit Ihre vorgeschlagene Lösung effektiv mit der übergeordneten Architekturvision Ihres Unternehmens übereinstimmt, sollten Sie sich mit Ihrem Team und den Stakeholdern abstimmen, die für die Leitung und Förderung dieser Initiative verantwortlich sind.

Weitere Aspekte identifizieren und klären

Bei der Planung einer Hybrid- oder Multi-Cloud-Architektur ist es wichtig, die architektonischen und betrieblichen Einschränkungen Ihres Projekts zu identifizieren und zu vereinbaren.

Im Hinblick auf die Betriebsanforderungen enthält die folgende unvollständige Liste einige Anforderungen, die bei der Planung Ihrer Architektur berücksichtigt werden sollten:

  • Mehrere Clouds separat verwalten und konfigurieren oder ein ganzheitliches Modell zum Verwalten und Schützen der verschiedenen Cloud-Umgebungen erstellen
  • Gewährleistung konsistenter Authentifizierungs-, Autorisierungs-, Audit- und Richtlinienverfahren in allen Umgebungen
  • Verwenden Sie konsistente Tools und Prozesse in allen Umgebungen, um einen ganzheitlichen Überblick über Sicherheit, Kosten und Optimierungsmöglichkeiten zu erhalten.
  • Einheitliche Compliance- und Sicherheitsstandards verwenden, um eine einheitliche Governance anzuwenden.

Aus architektonischer Sicht gehen die größten Beschränkungen oft auf vorhandene Systeme zurück und können Folgendes umfassen:

  • Abhängigkeiten zwischen Anwendungen
  • Leistungs- und Latenzanforderungen an die Kommunikation zwischen Systemen
  • Abhängigkeit von Hardware- oder Betriebssystemen, die in der öffentlichen Cloud unter Umständen nicht verfügbar sind
  • Lizenzeinschränkungen
  • Abhängigkeit von der Verfügbarkeit der erforderlichen Funktionen in den ausgewählten Regionen einer Multi-Cloud-Architektur

Weitere Informationen zu anderen Aspekten in Bezug auf die Portabilität von Arbeitslasten, die Datenübertragung und die Sicherheit finden Sie unter Weitere Überlegungen.

Strategie für Hybrid- und Multi-Cloud-Architekturen entwickeln

Nachdem Sie die geschäftlichen und technischen Ziele mit den zugehörigen Geschäftsanforderungen geklärt und idealerweise eine Visionsbeschreibung formuliert und vereinbart haben, können Sie Ihre Strategie für eine Hybrid- oder Multi-Cloud-Architektur entwickeln.

Im folgenden Flussdiagramm sind die logischen Schritte zum Erstellen einer solchen Strategie zusammengefasst.

Berücksichtigen Sie bei der Strategieentwicklung Ihre Geschäftsziele, holen Sie sich das Einverständnis der Beteiligten ein, erstellen Sie einen groben Plan und nutzen Sie diesen dann als Grundlage für Ihre Strategie.

Damit Sie die technischen Ziele und Anforderungen Ihrer Hybrid- oder Multi-Cloud-Architektur besser bestimmen können, beginnen die Schritte im vorherigen Flussdiagramm mit den Geschäftsanforderungen und -zielen. Wie Sie Ihre Strategie umsetzen, kann je nach den Zielen, Treibern und dem technologischen Migrationspfad jedes Geschäftsfalles variieren.

Eine Migration ist mit einer Reise vergleichbar. Das folgende Diagramm veranschaulicht die Phasen dieses Prozesses, wie in Zu Google Cloud migrieren beschrieben.

Migrationspfad mit vier Phasen

In diesem Abschnitt finden Sie Informationen zu den Phasen „Bewerten“, „Planen“, „Bereitstellen“ und „Optimieren“ im vorherigen Diagramm. Diese Informationen werden im Kontext einer Hybrid- oder Multi-Cloud-Migration präsentiert. Sie sollten jede Migration an die Anleitungen und Best Practices anpassen, die im Abschnitt zum Migrationspfad des Leitfadens „Zu Google Cloud migrieren“ beschrieben sind. Diese Phasen können für jede Arbeitslast einzeln gelten, nicht für alle Arbeitslasten gleichzeitig. Es kann sein, dass sich mehrere Arbeitslasten zu einem bestimmten Zeitpunkt in verschiedenen Phasen befinden:

Bewertungsphase

In der Phase Bewerten führen Sie eine erste Bewertung der Arbeitslast durch. Berücksichtigen Sie in dieser Phase die in Ihren Dokumenten zur Visions- und Strategieplanung beschriebenen Ziele. Legen Sie einen Migrationsplan fest, indem Sie zuerst eine Liste der Arbeitslasten erstellen, die von einer Bereitstellung oder Migration in die öffentliche Cloud profitieren könnten.

Wählen Sie zuerst eine Arbeitslast aus, die nicht geschäftskritisch oder zu schwierig zu migrieren ist (mit minimalen oder keinen Abhängigkeiten von Arbeitslasten in anderen Umgebungen) und gleichzeitig typisch genug ist, um als Vorlage für zukünftige Bereitstellungen oder Migrationen zu dienen.

Im Idealfall sollte die ausgewählte Arbeitslast oder Anwendung Teil eines gezielten Geschäftsnutzungsfalls oder einer Funktion sein, die nach Abschluss eine messbare Auswirkung auf das Unternehmen hat.

Führen Sie eine Bewertung der Migrationsrisiken durch, um potenzielle Migrationsrisiken zu bewerten und zu minimieren. Es ist wichtig, die Arbeitslast zu bewerten, um ihre Eignung für die Migration in eine Multi-Cloud-Umgebung zu bestimmen. Dabei werden verschiedene Aspekte der Anwendungen und Infrastruktur bewertet, darunter:

  • Anforderungen an die Anwendungskompatibilität mit den ausgewählten Cloud-Anbietern
  • Preismodelle
  • Sicherheitsfunktionen der ausgewählten Cloud-Anbieter
  • Anforderungen an die Interoperabilität von Anwendungen

Eine Bewertung hilft Ihnen auch, Anforderungen an den Datenschutz, Compliance-Anforderungen, Konsistenzanforderungen und Lösungen in mehreren Cloud-Umgebungen zu identifizieren. Die von Ihnen ermittelten Risiken können sich auf die Arbeitslasten auswirken, die Sie migrieren oder ausführen möchten.

Es gibt verschiedene Tools, z. B. das Google Cloud-Migrationscenter, mit denen Sie vorhandene Arbeitslasten bewerten können. Weitere Informationen finden Sie unter Migration zu Google Cloud: Bewertungstool auswählen.

Aus Sicht der Arbeitslastmodernisierung hilft das Eignungsbewertungstool, eine VM-Arbeitslast zu bewerten, um festzustellen, ob sie für die Modernisierung in einen Container oder die Migration zu Compute Engine geeignet ist.

Planungsphase

Beginnen Sie in der Phase Planen mit den identifizierten Anwendungen und erforderlichen Cloud-Workloads und führen Sie die folgenden Aufgaben aus:

  1. Entwickeln Sie eine priorisierte Migrationsstrategie, die Migrationswellen und ‑pfade für Anwendungen definiert.
  2. Das übergeordnete Muster für die Hybrid- oder Multi-Cloud-Anwendungsarchitektur ermitteln
  3. Wählen Sie ein Netzwerkarchitekturmuster aus, das das ausgewählte Anwendungsarchitekturmuster unterstützt.

Idealerweise sollten Sie das Cloud-Netzwerkmuster in das Design der Landing Zone einbinden. Das Design der Landing Zone dient als wichtiges Grundelement der gesamten Hybrid- und Multi-Cloud-Architekturen. Das Design muss nahtlos in diese Muster integriert werden. Entwerfen Sie die Landing Zone nicht isoliert. Betrachten Sie diese Netzwerkmuster als Teil des Landingpage-Designs.

Eine Landingzone kann aus verschiedenen Anwendungen mit jeweils einem anderen Netzwerkarchitekturmuster bestehen. In dieser Phase ist es außerdem wichtig, das Design der Google Cloud-Organisation, -Projekte und -Ressourcenhierarchie zu bestimmen, um die Landing Zone Ihrer Cloud-Umgebung auf die Hybrid- oder Multi-Cloud-Integration und -Bereitstellung vorzubereiten.

In dieser Phase sollten Sie Folgendes berücksichtigen:

  • Definieren Sie den Ansatz für Migration und Modernisierung. Weitere Informationen zu Migrationsansätzen finden Sie weiter unten in diesem Leitfaden. Weitere Informationen finden Sie auch im Abschnitt Migrationstypen des Artikels Zu Google Cloud migrieren.
  • Nutzen Sie die Ergebnisse aus der Bewertungs- und Erkenntnisphase. Passen Sie sie an die Arbeitslast an, die Sie migrieren möchten. Entwickeln Sie dann einen Migrationsplan für Migrationswellen für die Anwendung. Der Plan sollte die geschätzten Anforderungen an die Ressourcengröße enthalten, die Sie in der Bewertungsphase ermittelt haben.
  • Definieren Sie das Kommunikationsmodell, das zwischen den verteilten Anwendungen und den Anwendungskomponenten für die beabsichtigte Hybrid- oder Multi-Cloud-Architektur erforderlich ist.
  • Entscheiden Sie sich für einen geeigneten Bereitstellungsarchetyp, um Ihre Arbeitslast für das ausgewählte Architekturmuster bereitzustellen, z. B. zonal, regional, multiregional oder global. Der von Ihnen ausgewählte Archetyp bildet die Grundlage für die Erstellung anwendungsspezifischer Bereitstellungsarchitekturen, die auf Ihre geschäftlichen und technischen Anforderungen zugeschnitten sind.
  • Legen Sie messbare Erfolgskriterien für die Migration fest, mit klaren Meilensteinen für jede Migrationsphase oder -welle. Die Auswahl von Kriterien ist unerlässlich, auch wenn das technische Ziel darin besteht, die Hybridarchitektur als kurzfristige Einrichtung zu haben.
  • Definieren Sie SLAs und KPIs für Anwendungen, die in einer Hybridumgebung ausgeführt werden, insbesondere für Anwendungen, deren Komponenten auf mehrere Umgebungen verteilt sind.

Weitere Informationen finden Sie unter Migration planen. Dort erfahren Sie, wie Sie eine erfolgreiche Migration planen und die damit verbundenen Risiken minimieren.

Bereitstellungsphase

In der Phase Bereitstellen können Sie mit der Umsetzung Ihrer Migrationsstrategie beginnen. Aufgrund der potenziellen Anzahl von Anforderungen ist es am besten, einen iterativen Ansatz zu verfolgen.

Priorisieren Sie Ihre Arbeitslasten anhand der Migrations- und Anwendungswellen, die Sie in der Planungsphase entwickelt haben. Bei Hybrid- und Multi-Cloud-Architekturen müssen Sie zuerst die erforderliche Verbindung zwischen Google Cloud und den anderen Rechenumgebungen herstellen. Um das erforderliche Kommunikationsmodell für Ihre Hybrid- oder Multi-Cloud-Architektur zu ermöglichen, sollten Sie die Bereitstellung auf dem ausgewählten Design und dem Typ der Netzwerkverbindung sowie dem anwendbaren Netzwerkmuster basieren lassen. Wir empfehlen, diesen Ansatz für die Gesamtgestaltung der Landing-Zone zu verwenden.

Außerdem müssen Sie die Anwendung oder den Dienst anhand der definierten Erfolgskriterien für die Anwendung testen und validieren. Idealerweise sollten diese Kriterien sowohl funktionale als auch Lasttests (nicht funktionale) umfassen, bevor die Produktion gestartet wird.

Optimierungsphase

Testen Sie in der Phase Optimieren Ihre Bereitstellung: Wenn die Anwendung oder der Dienst die Erwartungen an Funktionalität und Leistungskapazität erfüllt, können Sie sie in die Produktion übernehmen. Cloud-Monitoring- und -Transparenztools wie Cloud Monitoring können Ihnen Aufschluss über die Leistung, Verfügbarkeit und Integrität Ihrer Anwendungen und Infrastruktur geben und Sie bei Bedarf bei der Optimierung unterstützen.

Weitere Informationen finden Sie unter Migration zu Google Cloud: Umgebung optimieren. Weitere Informationen zum Entwerfen solcher Tools für Hybrid- oder Multi-Cloud-Architekturen finden Sie unter Hybrid- und Multi-Cloud-Monitoring- und -Logging-Muster.

Arbeitslasten bewerten

Die Wahl der Rechenumgebungen für verschiedene Arbeitslasten wirkt sich erheblich auf den Erfolg einer Hybrid- und Multi-Cloud-Strategie aus. Entscheidungen zur Platzierung von Arbeitslasten sollten auf spezifische Geschäftsziele abgestimmt sein. Daher sollten diese Entscheidungen anhand gezielter geschäftlicher Anwendungsfälle getroffen werden, die messbare Geschäftseffekte ermöglichen. Es ist jedoch nicht immer notwendig und auch nicht empfehlenswert, mit der geschäftskritischsten Arbeitslast oder Anwendung zu beginnen. Weitere Informationen finden Sie im Leitfaden „Zu Google Cloud migrieren“ unter Anwendungen auswählen, die zuerst migriert werden sollen.

Wie im Abschnitt Geschäftliche und technische Treiber erläutert, gibt es verschiedene Arten von Treibern und Überlegungen für Hybrid- und Multi-Cloud-Architekturen.

Die folgende Liste von Faktoren kann Ihnen helfen, Ihren Migrationsfall im Kontext einer Hybrid- oder Multi-Cloud-Architektur zu bewerten, mit Möglichkeiten, messbare Geschäftseffekte zu erzielen:

  • Mögliche Marktdifferenzierung oder Innovation, die sich aus der Verwendung von Cloud-Diensten ergibt, um bestimmte Geschäftsfunktionen oder -fähigkeiten zu ermöglichen, z. B. Funktionen für künstliche Intelligenz, bei denen vorhandene lokale Daten zum Trainieren von Modellen für maschinelles Lernen verwendet werden.
  • Mögliche Einsparungen bei den Gesamtbetriebskosten einer Anwendung.
  • Mögliche Verbesserungen der Verfügbarkeit, Ausfallsicherheit, Sicherheit oder Leistung, z. B. durch Hinzufügen einer Notfallwiederherstellungs-Website (Disaster Recovery, DR) in der Cloud.
  • Mögliche Beschleunigung der Entwicklungs- und Releaseprozesse, z. B. durch das Erstellen von Entwicklungs- und Testumgebungen in der Cloud.

Die folgenden Faktoren können Ihnen beim Evaluieren der Migrationsrisiken helfen:

  • Die potenziellen Auswirkungen von Ausfällen, die durch eine Migration verursacht werden.
  • Die Erfahrung Ihres Teams mit Bereitstellungen in der öffentlichen Cloud oder mit Bereitstellungen für einen neuen oder zweiten Cloud-Anbieter.
  • Die Notwendigkeit, bestehende gesetzliche oder behördliche Auflagen einzuhalten.

Die folgenden Faktoren können Ihnen beim Evaluieren der technischen Schwierigkeiten einer Migration helfen:

  • Größe, Komplexität und Alter der Anwendung.
  • Die Anzahl der Abhängigkeiten von anderen Anwendungen und Diensten in verschiedenen Computing-Umgebungen.
  • Alle Einschränkungen, die durch Lizenzen von Drittanbietern auferlegt werden.
  • Abhängigkeiten von bestimmten Versionen von Betriebssystemen, Datenbanken oder anderen Umgebungskonfigurationen

Nachdem Sie Ihre anfänglichen Arbeitslasten bewertet haben, können Sie mit dem Priorisieren der Arbeitslasten und dem Definieren der Migrationswellen und Ansätze beginnen. Anschließend können Sie geeignete Architekturmuster und unterstützende Netzwerkmuster identifizieren. Unter Umständen muss dieser Schritt mehrmals wiederholt werden, da sich Ihre Einschätzung im Laufe der Zeit ändern kann. Daher empfiehlt es sich, die Arbeitslasten nach den ersten Cloudbereitstellungen noch einmal neu zu bewerten.

Architekturansätze für eine Hybrid- oder Multi-Cloud-Architektur

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.

Flussdiagramm mit verschiedenen Ansätzen zur Migration von Arbeitslasten aus Ihrer Cloud-Umgebung.

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.

Weitere Hinweise

In diesem Dokument werden die wichtigsten Designaspekte erläutert, die eine entscheidende Rolle bei der Gestaltung Ihrer gesamten Hybrid- und Multi-Cloud-Architektur spielen. Analysieren und bewerten Sie diese Überlegungen über die gesamte Lösungsarchitektur hinweg und berücksichtigen Sie dabei alle Arbeitslasten, nicht nur bestimmte.

Refaktorieren

Bei einer Refaktorierungsmigration ändern Sie Ihre Arbeitslasten, um die Cloud-Funktionen nutzen zu können, nicht nur, damit sie in der neuen Umgebung funktionieren. Sie können die einzelnen Arbeitslasten in Bezug auf Leistung, Funktionen, Kosten und Nutzungskomfort optimieren. Wie in Refaktorieren: Verschieben und Verbessern hervorgehoben, können Sie In einigen Refaktorierungsszenarien Arbeitslasten anpassen, bevor sie in die Cloud migriert werden. Dieser Refaktorierungsansatz bietet die folgenden Vorteile, insbesondere wenn Sie eine Hybridarchitektur als langfristige Zielarchitektur erstellen möchten:

  • Sie können den Deployment-Prozess verbessern.
  • Durch die Nutzung der CI/CD-Infrastruktur und -Tools (Continuous Integration/Continuous Deployment, CI/CD) können Sie den Releaserhythmus beschleunigen und Feedbackzyklen verkürzen.
  • Sie können die Refaktorierung als Grundlage verwenden, um eine hybride Architektur mit Anwendungsportabilität zu erstellen und zu verwalten.

Damit dieser Ansatz gut funktioniert, erfordert er in der Regel bestimmte Investitionen in lokale Infrastrukturen und Tools. Beispiel: Einrichtung einer lokale Container Registry und Bereitstellung von Kubernetes-Clustern für die Containerisierung von Anwendungen. Die Google Kubernetes Engine (GKE) Enterprise-Version kann bei diesem Ansatz für Hybridumgebungen nützlich sein. Weitere Informationen zu GKE Enterprise finden Sie im folgenden Abschnitt. Weitere Informationen finden Sie auch in der GKE Enterprise Hybrid Referenzarchitektur der Umgebung .

Arbeitslastportabilität

Bei Hybrid- und Multi-Cloud-Architekturen möchten Sie möglicherweise Arbeitslasten zwischen den Rechenumgebungen verschieben, in denen Ihre Daten gehostet werden. Berücksichtigen Sie die folgenden Faktoren, um ein nahtloses Verschieben von Arbeitslasten zwischen Umgebungen zu ermöglichen:

  • Sie können eine Anwendung von einer Rechenumgebung in eine andere verschieben, ohne die Anwendung und ihr Betriebsmodell wesentlich zu ändern:
    • Anwendungsbereitstellung und ‐verwaltung sind auf allen Computing-Umgebungen einheitlich.
    • Transparenz, Konfiguration und Sicherheit sind in allen Rechenumgebungen einheitlich.
  • Die Möglichkeit, eine Arbeitslast portierbar zu machen, sollte nicht mit der Cloud-First-Arbeitslast in Konflikt stehen.

Automatisierung der Infrastruktur

Automatisierung der Infrastruktur ist für die Übertragbarkeit in Hybrid- und Multi-Cloud-Architekturen unerlässlich Ein gängiger Ansatz zur Automatisierung der Infrastrukturerstellung ist die Infrastruktur als Code (IaC). IaC umfasst die Verwaltung Ihrer Infrastruktur in Dateien, anstatt Ressourcen wie eine VM, eine Sicherheitsgruppe oder einen Load-Balancer manuell in einer Benutzeroberfläche zu konfigurieren. Terraform ist ein beliebtes IaC-Tool, mit dem Infrastrukturressourcen in einer Datei definiert werden. Mit Terraform können Sie auch die Erstellung dieser Ressourcen in heterogenen Umgebungen automatisieren.

Weitere Informationen zu den Terraform-Kernfunktionen, die Ihnen bei der Automatisierung von Bereitstellung und Verwaltung von Google Cloud-Ressourcen helfen können, siehe Terraform-Blueprints und -Module für Google Cloud

Darüber hinaus stehen Ihnen Konfigurationsverwaltungstools wie Ansible, Puppet oder Chef zur Verfügung, um einen gemeinsamen Bereitstellungs- und Konfigurationsprozess einzurichten. Alternativ können Sie ein Bildverankerungstool wie Packer zum Erstellen von VM-Images für verschiedene Plattformen verwenden. Mithilfe einer einzigen, gemeinsamen Konfigurationsdatei können Sie mit Packer und Cloud Build ein VM-Image zur Verwendung in Compute Engine erstellen. Schließlich gibt es Lösungen wie Prometheus und Grafana, die ein konsistentes Monitoring in allen Umgebungen gewährleisten.

Mithilfe dieser Tools können Sie eine gemeinsame Toolchain zusammenstellen, wie im folgenden logischen Diagramm dargestellt. Diese gängige Toolchain abstrahiert die Unterschiede zwischen Rechenumgebungen. Außerdem können Sie die Bereitstellung, Management und Monitoring vereinheitlichen.

Eine Toolchain ermöglicht die Portabilität von Anwendungen.

Obwohl eine gemeinsame Toolchain Ihnen dabei helfen kann, Portabilität zu ermöglichen, weist sie einige der folgenden Schwachstellen auf:

  • Die Verwendung von VMs als gemeinsame Grundlage kann die Implementierung echter Cloud-First-Anwendungen erschweren. Außerdem können Sie durch die Verwendung von VMs nur verhindern, dass Sie Cloud-verwaltete Dienste nutzen. Möglicherweise verpassen Sie Gelegenheiten, den Verwaltungsaufwand zu reduzieren.
  • Der Aufbau und die Pflege einer gemeinsamen Toolchain verursacht Gemein- und Betriebskosten.
  • Wenn die Toolchain erweitert wird, kann sie auf die spezifischen Anforderungen Ihres Unternehmens zugeschnitten sein. Diese erhöhte Komplexität kann zu steigenden Schulungskosten beitragen.

Bevor Sie sich für die Entwicklung von Tools und Automatisierung entscheiden, sollten Sie sich mit den verwalteten Diensten Ihres Cloud-Anbieters vertraut machen. Wenn Ihr Anbieter verwaltete Dienste anbietet, die denselben Anwendungsfall unterstützen, können Sie einen Teil der Komplexität abstrahieren. So können Sie sich auf die Arbeitslast und die Anwendungsarchitektur konzentrieren, anstatt auf die zugrunde liegenden Infrastruktur.

Beispielsweise können Sie das Kubernetes-Ressourcenmodell zur Automatisierung der Erstellung von Kubernetes-Clustern mithilfe eines deklarativen Konfigurationsansatz nutzen. Sie können die Konvertierung in Deployment Manager zum Konvertieren Ihrer Deployment Manager-Konfigurationen und -Vorlagen auf andere deklarative Konfigurationsformate nutzen, die von Google Cloud unterstützt werden (wie Terraform und das Kubernetes-Ressourcenmodell), damit sie portierbar sind, wenn Sie veröffentlichen.

Sie können auch überlegen, die Erstellung von Projekten und die Erstellung von Ressourcen innerhalb dieser Projekte zu automatisieren. Diese Automatisierung kann Ihnen helfen, einen Infrastruktur-als-Code-Ansatz für der Projektbereitstellung zu implementieren.

Container und Kubernetes

Mit in der Cloud verwalteten Funktionen lässt sich die Komplexität des Aufbaus und der Pflege einer benutzerdefinierten Toolkette reduzieren, um die Automatisierung und Portabilität von Workloads zu erreichen. Wenn jedoch nur VMs als gemeinsame Grundlage verwendet werden, ist die Implementierung echter Cloud-First-Anwendungen schwierig.. Sie können diese allerdings umgehen, wenn Sie stattdessen Container und Kubernetes verwenden.

Dank Containern kann Ihre Software auch dann noch zuverlässig ausgeführt werden, wenn Sie sie von einer Umgebung in eine andere verschieben. Da Container Anwendungen von der zugrunde liegenden Hostinfrastruktur entkoppeln, erleichtern sie die Bereitstellung in allen Rechenumgebungen, z. B. in Hybrid- und Multi-Cloud-Umgebungen.

Kubernetes übernimmt die Orchestrierung, Bereitstellung, Skalierung und Verwaltung für Ihre Containeranwendungen. Es ist Open Source und unterliegt der Cloud Native Computing Foundation Mit Kubernetes werden die Dienste bereitgestellt, die die Grundlage eines Cloud-First-Ansatzes bilden. Weil Sie Kubernetes auf vielen Computing-Plattformen installieren und ausführen können können Sie damit auch eine gemeinsame Laufzeitebene in Rechenumgebungen etablieren.

  • Kubernetes bietet dieselben Dienste und APIs in einer cloudbasierten und privaten Rechenumgebung. Darüber hinaus ist der Abstraktionsgrad viel höher als bei Verwendung von VMs, was generell weniger Vorarbeit bedeutet und die Produktivität der Entwickler verbessert.
  • Im Gegensatz zu einer benutzerdefinierten Toolchain ist Kubernetes sowohl in der Entwicklung als auch der Anwendungsverwaltung weit verbreitet, sodass Sie auf vorhandene Expertise, Dokumentation und Unterstützung von Drittanbietern zurückgreifen können.
  • Kubernetes unterstützt alle Containerimplementierungen, die:

Wenn eine Arbeitslast in Google Cloud ausgeführt wird, können Sie den Aufwand für die Installation und den Betrieb von Kubernetes mithilfe einer verwalteten Kubernetes-Plattform wie Google Kubernetes Engine (GKE) vermeiden. So können die Betriebsmitarbeiter ihren Schwerpunkt von der Erstellung und Wartung der Infrastruktur auf die Erstellung und Wartung von Anwendungen verlagern.

Sie können auch Autopilot verwenden, einen GKE-Betriebsmodus, der die Clusterkonfiguration verwaltet, einschließlich der Knoten, Skalierung, Sicherheit und anderer vorkonfigurierter Einstellungen. Berücksichtigen Sie bei der Verwendung von GKE Autopilot Ihre Skalierungsanforderungen und seine Skalierungslimits.

Technisch gesehen können Sie Kubernetes in vielen Rechenumgebungen installieren und ausführen, um eine gemeinsame Laufzeitebene einzurichten. In der Praxis kann das Erstellen und Betreiben einer solchen Architektur jedoch komplexer werden. Die Architektur wird noch komplexer, wenn Sie eine Sicherheitskontrolle auf Containerebene (Service Mesh) benötigen.

Um die Verwaltung von Multi-Cluster-Bereitstellungen zu vereinfachen, können Sie GKE Enterprise verwenden, um moderne Anwendungen überall in großem Maßstab auszuführen. GKE enthält leistungsstarke verwaltete Open-Source-Komponenten, mit denen Arbeitslasten gesichert, Compliancerichtlinien erzwungen und eine umfassende Beobachtbarkeit und Fehlerbehebung im Netzwerk bereitgestellt werden können.

Wie im folgenden Diagramm dargestellt, können Sie mit GKE Enterprise Multi-Cluster-Anwendungen als Flotten betreiben.

Stackdiagramm, das die Möglichkeiten der Flottenverwaltung von GKE Enterprise zeigt.

GKE Enterprise unterstützt die folgenden Designoptionen zur Unterstützung von hybriden und Multi-Cloud-Architekturen:

  • Design und Aufbau von Cloud-ähnlichen Erfahrungen vor Ort oder einheitliche Lösungen für den Übergang von Anwendungen in die GKE Enterprise Hybrid-Umgebung. Weitere Informationen siehe Referenzarchitektur der hybriden GKE Enterprise-Umgebung

  • Entwerfen und erstellen Sie eine Lösung, um die Multi-Cloud-Komplexität mit einer konsistenten Governance, einem konsistenten Betrieb und einem Sicherheitsstatus mit GKE Multi-Cloud zu bewältigen. Weitere Informationen finden Sie in der GKE Multi-Cloud Dokumentation.

GKE Enterprise bietet auch logische Gruppierungen ähnlicher Umgebungen mit konsistenter Sicherheit, Konfiguration und Dienstverwaltung. GKE Enterprise unterstützt beispielsweise verteilten Zero-Trust-Architektur. In einer verteilten Zero-Trust-Architektur können Dienste, die vor Ort oder in einer anderen Cloud-Umgebung bereitgestellt werden, über eine sichere End-to-End mTLS-Kommunikation von Dienst zu Dienst miteinander kommunizieren.

Überlegungen zur Portabilität von Arbeitslasten

Kubernetes und GKE Enterprise bieten eine Abstraktionsebene für Arbeitslasten, hinter der sich die vielen Komplexitäten und Unterschiede zwischen Computing-Umgebungen verbergen können. In der folgenden Liste werden einige dieser Abstraktionen beschrieben:

  • Eine Anwendung könnte zwar mit minimalen Änderungen in eine andere Umgebung portierbar sein, aber nicht unbedingt in beiden Umgebungen die gleiche Leistung bringen.
    • Unterschiede bei den zugrunde liegenden Rechen-, Infrastruktur- oder Netzwerkinfrastrukturen sowie bei der Nähe zu abhängigen Diensten können zu erheblichen Unterschieden in der Leistung führen.
  • Das Verschieben einer Arbeitslast zwischen Rechenumgebungen kann auch bedeuten, dass Sie Daten verschieben müssen.
    • Unterschiedliche Umgebungen können unterschiedliche Datenspeicherung und Managementdienstleistungen und Einrichtungen haben.
  • Das Verhalten und die Leistung von Load-Balancern, die mit Kubernetes oder GKE Enterprise bereitgestellt werden, können zwischen Umgebungen variieren.

Datenverschiebung

Da es komplex sein kann, Daten in großem Umfang zwischen Computerumgebungen zu verschieben, freizugeben und darauf zuzugreifen, zögern Unternehmen möglicherweise, eine Hybrid- oder Multi-Cloud-Architektur aufzubauen. Diese Notwendigkeit kann zunehmen, wenn der Großteil ihrer Daten bereits lokal oder in einer Cloud gespeichert wird.

Die verschiedenen Optionen für die Datenverschiebung, die von Google Cloud angeboten werden, bieten Unternehmen jedoch ein umfassendes Angebot an Lösungen für die Verschiebung, Integration und Transformation ihrer Daten. Mit diesen Optionen können Unternehmen Daten in verschiedenen Umgebungen entsprechend ihren spezifischen Anwendungsfällen speichern, freigeben und darauf zugreifen. Diese Fähigkeit erleichtert es den Entscheidungsträgern von Unternehmen und Technologien letztendlich, Hybrid- und Multi-Cloud-Architekturen zu implementieren.

Die Datenverschiebung ist ein wichtiger Aspekt für die Hybrid- und Multi-Cloud-Strategie und -Architekturplanung. Ihr Team muss die verschiedenen geschäftlichen Anwendungsfälle und die dafür erforderlichen Daten identifizieren. Sie sollten auch über Speicherplatz, Kapazität, Barrierefreiheit und Verschiebungsmöglichkeiten nachdenken.

Wenn ein Unternehmen eine Datenklassifizierung für regulierte Branchen hat, kann diese Klassifizierung dabei helfen, Speicherorte und regionsübergreifende Datenbewegungsbeschränkungen für bestimmte Datenklassen zu identifizieren. Weitere Informationen finden Sie unter Schutz sensibler Daten: Der Schutz sensibler Daten ist ein vollständig verwalteter Dienst, mit dem Sie Ihre Datenbestände ermitteln, klassifizieren und schützen können.

Weitere Informationen zum Prozess von der Planung einer Datenübertragung bis zur Verwendung von Best Practices bei der Umsetzung eines Plans finden Sie unter Migration zu Google Cloud: Große Datasets übertragen.

Sicherheit

Wenn Organisationen Hybrid- und Multi-Cloud-Architekturen einführen, kann ihre Angriffsfläche zunehmen, je nachdem, wie ihre Systeme und Daten auf verschiedene Umgebungen verteilt sind. In Verbindung mit der sich ständig weiterentwickelnden Bedrohungslandschaft können größere Angriffsflächen zu einem erhöhten Risiko von unbefugtem Zugriff, Datenverlust und anderen Sicherheitsvorfällen führen. Achten Sie bei der Planung und Implementierung von Hybrid- oder Multi-Cloud-Strategien sorgfältig auf die Sicherheit.

Weitere Informationen finden Sie unter Attack Surface Management für Google Cloud

Bei der Architektur einer Hybridarchitektur ist es technisch nicht immer machbar oder praktikabel, lokale Sicherheitsansätze auf die Cloud zu erweitern. Viele der Netzwerksicherheitsfunktionen von Hardware-Appliances sind jedoch Cloud-First-Funktionen und arbeiten auf verteilte Weise. Weitere Informationen über die Cloud-First-Netzwerksicherheitsfunktionen von Google Cloud finden Sie unter Cloud-Netzwerksicherheit.

Hybrid- und Multi-Cloud-Architekturen können die Sicherheit erhöhen wie Konsistenz und Beobachtbarkeit. Jeder Anbieter öffentlicher Clouds hat seinen eigenen Sicherheitsansatz, einschließlich verschiedener Modelle, Best Practices, Infrastruktur- und Anwendungssicherheitsfunktionen, Complianceverpflichtungen und sogar den Namen von Sicherheitsdiensten. Diese Inkonsistenzen können das Sicherheitsrisiko erhöhen. Das Modell der geteilten Verantwortung der einzelnen Cloud-Anbieter kann sich unterscheiden. Es ist wichtig, den genauen Abschluss der Verantwortlichkeiten in einer Multi-Cloud-Architektur zu identifizieren und zu verstehen.

Beobachtbarkeit ist wichtig, um Erkenntnisse und Messwerte aus den verschiedenen Umgebungen. In einer Multi-Cloud-Architektur bietet jede Cloud in der Regel Tools zum Monitoring des Sicherheitsstatus und von Fehlkonfigurationen. Diese Tools bieten jedoch eine isolierte Sichtbarkeit, wodurch die Entwicklung erweiterter Bedrohungsdaten im gesamten verhindert wird. Daher muss das Sicherheitsteam zwischen Tools und Dashboards wechseln, um die Cloud zu schützen. Ohne eine umfassende End-to-End-Sicherheitstransparenz für hybride und Multi-Cloud-Umgebungen ist es schwierig, Schwachstellen zu priorisieren und zu entschärfen.

Um die vollständige Sichtbarkeit und Status aller Umgebungen zu erhalten, priorisieren Sie Ihre Sicherheitslücken und minimieren Sie die von Ihnen erkannten Sicherheitslücken. Wir empfehlen ein zentralisiertes Sichtbarkeitsmodell. Ein zentralisiertes Sichtbarkeitsmodell vermeidet die Notwendigkeit einer manuellen Korrelation zwischen verschiedenen Tools und Dashboards von unterschiedlichen Plattformen. Weitere Informationen finden Sie unter Hybrid- und Multi-Cloud-Monitoring- und -Logging-Muster.

Als Teil Ihrer Planung, um Sicherheitsrisiken zu minimieren und Arbeitslasten in der Google Cloud bereitzustellen, und um Sie bei der Planung und Gestaltung Ihrer Cloud-Lösung zu unterstützen, damit Sie Ihre Sicherheits- und Compliance-Ziele erreichen, sollten Sie das Google Cloud Security Best Practices Center und den Enterprise Foundations Blueprint kennenlernen.

Complianceziele können variieren, da sie von sowohl branchenspezifischen Vorschriften als auch den unterschiedlichen regulatorischen Anforderungen verschiedener Regionen und Länder beeinflusst werden. Weitere Informationen finden Sie in der Compliance-Ressourcen-Center. Hier einige der wichtigsten Empfehlungen: für eine sichere Hybrid- und Multi-Cloud-Architektur:

  • Entwickeln Sie eine einheitliche, maßgeschneiderte Cloud-Sicherheitsstrategie und -architektur. Hybrid- und Multi-Cloud-Sicherheitsstrategien sollten auf die spezifischen Anforderungen und Ziele Ihrer Organisation zugeschnitten sein.

    Es ist wichtig, die ausgewählte Architektur und die Zielumgebung zu verstehen, bevor Sie Sicherheitskontrollen implementieren, da jede Umgebung unterschiedliche Features, Konfigurationen und Dienste verwenden kann.

  • Einheitliche Sicherheitsarchitektur für Hybrid- und Multi-Cloud-Umgebungen nutzen.

  • Cloud-Design und -Bereitstellungen standardisieren, insbesondere Sicherheitsdesign und Funktionen. Dies kann die Effizienz verbessern und eine einheitliche Governance und Tools ermöglichen.

  • Verwenden Sie mehrere Sicherheitskontrollen.

    In der Regel kann keine einzelne Sicherheitskontrolle alle Sicherheitsanforderungen angemessen erfüllen. Daher sollten Organisationen eine Kombination aus Sicherheitskontrollen in einem mehrschichtigen Verteidigungsansatz verwenden, der auch als Defense-in-Depth bezeichnet wird.

  • Sicherheitsmaßnahmen überwachen und kontinuierlich verbessern: Ihre Organisation sollte ihre verschiedenen Umgebungen auf Sicherheitsbedrohungen und Sicherheitslücken überwachen. Außerdem sollte es versuchen, seinen Sicherheitsstatus kontinuierlich zu verbessern.

  • Erwägen Sie die Verwendung von Cloud Security Posture Management (CSPM), um Fehlkonfigurationen und Cyberbedrohungen zu beheben. CSPM bietet Bewertungen von Sicherheitslücken in Hybrid- und Multi-Cloud-Umgebungen.

Security Command Center ist eine integrierte Sicherheits- und Risikomanagementlösung für Google Cloud mit der Sie unter anderem Fehlkonfigurationen und Sicherheitslücken identifizieren können. Security Health Analytics ist ein verwaltetes Tool zum Prüfen von Sicherheitslücken. Das ist ein Feature von Security Command Center, das Sicherheitsrisiken und Sicherheitslücken in Ihrer Google Cloud-Umgebung identifiziert und Empfehlungen zur Behebung dieser Probleme gibt.

Mit Mandiant Attack Surface Management für Google Cloud kann Ihre Organisation die Assets ihrer Multi-Cloud- oder Hybrid-Cloud-Umgebung besser erkennen. Assets. Er erkennt automatisch Assets von mehreren Cloud-Anbietern, DNS und die erweiterte externe Angriffsfläche, um Ihrem Unternehmen ein tieferes Verständnis der Umgebung zu vermitteln. Nutzen Sie diese Informationen, um die Schwachstellen und Gefährdungen, die das größte Risiko darstellen, vorrangig zu beseitigen.

  • Cloud Security Information and Event Management-Lösung (SIEM): zum Erfassen und Analysieren von Sicherheitslogs aus Hybrid- und Multi-Cloud-Umgebungen um Bedrohungen zu erkennen und darauf zu reagieren. Google Security Operations SIEM von Google Cloud unterstützt Sie bei der Bereitstellung von Sicherheitsinformationen und -ereignissen. Dazu werden alle Ihre Sicherheitsdaten zentral erfasst, analysiert, erkannt und untersucht.

Hybrid- und Multi-Cloud-Architekturen mit Google Cloud erstellen: Nächste Schritte