Multicloud-Architektur mit Google Cloud meistern

Herausforderungen und Chancen beim Aufbau einer Hybrid- oder Multicloud-Lösung mit Google Cloud

Immer mehr Unternehmen setzen auf Hybrid- und Multicloud-Lösungen mit Google Cloud. Manche sind Startups, die ihren Kundenstamm gezielt dort aufbauen, wo ihre Kunden bereits sind; andere sind Großunternehmen auf der Suche nach dem passenden Werkzeug, um Probleme zu lösen, hohe Verfügbarkeit sicherzustellen oder ihre Anbieter zu diversifizieren und so Risiken zu senken. Bevor Unternehmen den Aufbau einer Hybrid-/Multicloud-Lösung angehen (üblicherweise als Teil eines umfassenderen Application-Modernization-Projekts), sollten sie die potenziellen Herausforderungen und Chancen kennen.

In diesem Beitrag beleuchte ich diese Themen, um zu zeigen, wer für diese Option infrage kommt, welche Stolpersteine zu beachten sind, welche Lösungen es gibt und wann man – zumindest auf absehbare Zeit – besser darauf verzichtet.

Definitionen

Beginnen wir mit ein paar Begriffsklärungen:

• Public Cloud – On-Demand-Rechendienste und Infrastruktur, die von einem Drittanbieter verwaltet und über das öffentliche Internet von mehreren Organisationen gemeinsam genutzt werden
• Private Cloud – Infrastruktur, die einer einzigen Organisation vorbehalten ist; sie kann entweder im eigenen Rechenzentrum oder in einer Colocation-Einrichtung eines Drittanbieters betrieben werden
• Hybrid Cloud – kombiniert On-Premises-, Private-Cloud- und Public-Cloud-Dienste von Drittanbietern und orchestriert zwischen den Plattformen
• Multicloud – kombiniert mehrere Cloud-Computing- und Storage-Dienste in einer einzigen heterogenen Architektur; bezeichnet auch die Verteilung von Cloud-Assets, Software, Anwendungen usw. auf mehrere Cloud-Hosting-Umgebungen
• Legacy-Anwendung – ein Informationssystem, das oftmals auf veralteten Technologien basiert, für den täglichen Betrieb aber unverzichtbar ist; meist dreischichtige monolithische Anwendungen, die fragil und schwer zu warten und zu aktualisieren sind
• Moderne Anwendung – meist eine App aus Microservices in einer N-Tier-Architektur. Sie ist so zuverlässig wie nötig und lässt sich mehrmals täglich aktualisieren, ohne den Produktivbetrieb zu stören (eine umfassendere Definition bietet die Twelve-Factor-App).

Anwendungsfälle

Diese Liste erhebt keinen Anspruch auf Vollständigkeit:

1. Zwischenstufe bei der Migration von IT-Infrastruktur, deren Verlagerung in die Cloud nur mäßig aufwendig ist: Ein Kunde verfügt etwa über eine erhebliche Anzahl an On-Prem-Servern (üblicherweise Linux oder Windows), eine Verbindung wird per VPN oder Interconnect aufgebaut, und Gruppen von VMs (entlang der Grenzen der Application Workloads) werden in die Cloud migriert. Die Kunden des Unternehmens werden über eine Hybrid-Cloud-Lösung bedient, in der ein Teil der Anwendungen On-Prem und ein Teil in der Cloud läuft, bis alle Workloads in die Public Cloud migriert sind (Hybrid Cloud).
2. Der Kunde möchte seine Lösung modernisieren, hat aber Anwendungen und Datenbanken, die sich nur sehr schwer in die Cloud verlagern lassen: etwa ein Kunde mit einem Mainframe oder einer Oracle-DB (heute nicht mehr ganz so schwierig) in seiner Private-Cloud-Umgebung, der die Anwendung auf eine moderne Architektur wie Kubernetes umstellen möchte (Hybrid Cloud).
3. Regulatorische Vorgaben: So können beispielsweise Anforderungen an die Datenregionalität bedeuten, dass bestimmte Informationen das Land nicht verlassen dürfen.
4. Cloudbursting: Hier wird automatisch zusätzliche Kapazität in der Cloud bereitgestellt und hochskaliert, sobald die On-Prem-Umgebung an ihre Grenzen stößt. Im Einzelhandel kann das etwa rund um Black Friday und Cyber Monday auftreten (Hybrid Cloud).
5. Hochverfügbarkeit und Disaster Recovery (Hybrid Cloud und Multicloud)
6. Die richtige Cloud für den richtigen Anwendungsfall: zum Beispiel Kubernetes- und Datenanalyse-Umgebungen auf der Google Cloud Platform (GCP) und Microsoft-basierte Anwendungen auf Azure.
7. Vermeidung von Vendor-Lock-in

Tech-Stack und nötige Fähigkeiten

Werfen wir nun einen Blick auf den Tech-Stack und die Fähigkeiten, die Sie aufbauen müssen – und auf die Herausforderungen, die dabei auf Unternehmen in unterschiedlichen Phasen ihres Weges zukommen können:

Compute:

• Verständnis der Private-Cloud-Umgebung – VMs und die verschiedenen Technologien auf Hypervisor-Ebene: Für Unternehmen, die bereits in einer Private Cloud unterwegs sind, ist das natürlich kein Thema. Für Digital Natives, die sich noch nie mit dem Tech-Stack und den internen Befindlichkeiten rund um eine Cloud-Lösung in einer Private-Cloud-Umgebung auseinandersetzen mussten, kann das hingegen eine erhebliche Hürde sein.
• Verständnis der Public-Cloud-Umgebung: Für Digital Natives kein Thema, für Unternehmen, die derzeit On-Premises arbeiten, jedoch eine spürbare Hürde – sowohl in puncto Sicherheit als auch im Hinblick auf interne Politik. Sie müssen einen neuen Stack mit neuen Methoden zur Verwaltung von VMs, Autoscaling usw. erlernen.

Datenbanken und Storage:

• Für Unternehmen in der Private Cloud besteht die Herausforderung darin, eine passende cloud-native Datenbank kennenzulernen und auszuwählen. Naheliegend ist der Wechsel zu managed SQL Server/PostgreSQL/MySQL; je nach geschäftlichen und technischen Zielen wollen oder müssen einige Unternehmen aber auf Technologien wie Spanner, BigTable und BigQuery umsteigen. Das kann anspruchsvoll werden.
• Zwei Tech-Stacks parallel zu betreiben kann mühsam sein: Ein Unternehmen mit einer On-Prem-Anwendung auf Oracle-Datenbankbasis, die auf eine PostgreSQL-Datenbank umgestellt werden soll, hat – je nach Komplexität und genutzten Features – zwei Optionen. Erstens: Lift-and-Shift auf eine Bare-Metal-Option mit anschließender Modernisierung. Zweitens: zunächst belassen, in der Private Cloud modernisieren und anschließend in die Cloud migrieren. In beiden Szenarien muss das Unternehmen zwei DB-Typen parallel betreiben, bis die Modernisierung abgeschlossen ist und eine der DBs abgeschaltet werden kann.

Networking:

• Zwischen dem Networking in Public und Private Clouds – und sogar zwischen den verschiedenen Clouds – gibt es erhebliche Unterschiede. Die Global VPC in Google Cloud ist beispielsweise ein enormer Vorteil und vereinfacht das Networking deutlich. Viele Private-Cloud-Unternehmen müssen das erst einmal kennenlernen. Außerdem fällt es ihnen schwer, sich bewusst dagegen zu entscheiden, ihre Vorgehensweisen aus der Private Cloud eins zu eins in die Public Cloud zu übertragen.
• Das Einrichten von VPNs, Partner-Interconnects und Interconnects ist in manchen Fällen unkompliziert, kann je nach Standort der Private Cloud des Kunden aber auch Wochen oder Monate dauern.

Security:

• Einheitliche, produktionsreife Sicherheitsmaßnahmen über Hybrid- und Multicloud-Umgebungen hinweg umzusetzen, kann knifflig werden. Jeder Cloud-Anbieter setzt unterschiedliche Sicherheitsmechanismen auf unterschiedliche Weise um. Wie Sie Software ausrollen und während des Deployment-Prozesses auf Sicherheitslücken prüfen, kann allein schon ein Projekt für sich sein.
• Security-Monitoring-Systeme über mehrere Clouds hinweg zu betreiben, ist eine Herausforderung für sich.

CI/CD:

• Eine zuverlässige Continuous-Integration- und Continuous-Deployment-Pipeline (CI/CD) aufzubauen, mit der sich sowohl Infrastruktur (IaC – etwa Terraform oder Pulumi) als auch Anwendungen über mehrere Umgebungen hinweg bauen, testen, absichern und ausrollen lassen, ist eine enorme Aufgabe. Sie erfordert zudem hochversierte, leistungsstarke Engineering-Teams und entsprechendes Tooling.

Modernisierung:

• Zu entscheiden, was und wie an Anwendungen und DBs modernisiert werden soll, ist alles andere als trivial und erfordert ausführliche Bewertungs- und Planungsphasen. Für Private-Cloud-Kunden kann es Monate oder sogar Jahre dauern – inklusive umfangreichem organisatorischem Change Management –, bis sie K8s und die optimale Arbeitsweise mit dem System wirklich beherrschen.

Authentifizierung:

• Die Herausforderung besteht darin, SSO Federation, AD Federation usw. plattformübergreifend über eine einzige Single Source of Truth abzubilden.

Team:

• Engineers/Architects zu finden, die in mehreren Plattformen wirklich versiert sind, ist schwierig. Sie müssen daher in die Weiterbildung Ihrer Teams investieren.
• Die Alternative: in einer sich rasant verändernden Cloud-Welt in mehreren Umgebungen am Ball bleiben, getrennte Teams mit unterschiedlichen Skill-Sets aufbauen und einen Geschäftsprozess etablieren, in dem diese Teams effizient zusammenarbeiten.

Kosten:

• Ähnlich wie der Aufbau einer Multi-Region- bzw. Hochverfügbarkeitsumgebung (HA) kann auch der Aufbau einer Multicloud- oder Hybrid-Cloud-Lösung bis zu zehnmal teurer ausfallen. Es geht eben nicht nur darum, eine weitere VM oder Datenbank einzurichten und dafür zu zahlen: Day-2-Operationen wie Orchestrierung, Replikation, Network-Egress-Kosten sowie der Support für Menschen und Mechanismen hinter diesen Systemen summieren sich.
• Unternehmen müssen FinOps mitdenken und eine Kultur etablieren, in der Teams ihre Cloud-Kosten selbst steuern, jeder Verantwortung für seine Cloud-Nutzung übernimmt, eine zentrale Best-Practice-Gruppe Unterstützung leistet und so ein 360°-Blick auf die Hybrid-/Multicloud-Kosten entsteht.

Eine Lösung definieren

An dieser Stelle denken Sie wahrscheinlich, dass Multicloud und Hybrid Cloud wirklich anspruchsvoll sind – aber weil die Branche genau in diese Richtung geht, führt an einer Lösung kein Weg vorbei.

Wichtig ist zu verstehen, dass solche Projekte Zeit brauchen. Gehen Sie anschließend nach folgender Methodik vor:

1. Bewerten Sie Ihre Unternehmenskultur, Ihre DevOps-Praktiken, Ihren Tech-Stack usw.
2. Planen Sie auf Basis der geschäftlichen und technologischen Ziele Ihres Unternehmens und der Ergebnisse der Bewertung. Bedenken Sie, dass Änderungen am System sowohl intern als auch bei Ihren Kunden eine erhebliche Lernkurve auslösen. Das braucht Zeit, und Sie müssen den Menschen Raum geben, sich an die neuen Arbeitsweisen und Technologien zu gewöhnen.
3. Migrieren/Refactoring: Beginnen Sie langsam und in kleinen Schritten, lassen Sie schnelle Fehler zu, lernen Sie daraus und verbessern Sie sich kontinuierlich. Wer langsam startet, steigert das Tempo Stück für Stück. Versuchen Sie nicht, beim Wechsel von Plattform, Codebasis usw. gleichzeitig zu optimieren.
4. Optimieren Sie, sobald die initiale Veränderung abgeschlossen ist und ein neues System läuft. Arbeiten Sie an der Optimierung sowohl mit Blick auf Performance als auch auf Kosten.

Den optimalen hybriden Tech-Stack aufbauen

Keine Technologielösung am Markt deckt alles ab. Sie müssen Ihren Stack bewerten und Lösungen kombinieren, um einen vollständigen hybriden Tech-Stack zu schaffen.

Application Layer:

GCP Anthos ist eine hervorragende Lösung, die viele der Bausteine abdeckt, die Sie für den Betrieb der Code-/Application-Layer Ihrer Lösung benötigen. Sie umfasst die folgenden Schichten und ermöglicht es Ihnen, Kubernetes-Cluster und sogar VMs (in Private Preview) auf GCP, AWS, Azure, Private Cloud und Bare Metal zu orchestrieren und zu betreiben.

Google Cloud Anthos Application Layers

Anthos clusters, die managed Kubernetes-Schicht am Fuß des Stacks, machen Day-2-Operationen deutlich einfacher als der Betrieb eigener Open-Source-Kubernetes-Cluster.

Anthos Ingress ist ein cloud-gehosteter Multi-Cluster-Ingress-Controller für GKE-Cluster.

Anthos Service Mesh ist eine Tool-Suite, mit der Sie ein zuverlässiges Service Mesh on-premises oder in Google Cloud überwachen und verwalten können.

Anthos Config Management ist ein Service für Konfigurations- und Policy-Management, der drei Komponenten vereint: Policy Controller, Config Sync und Config Controller. Gemeinsam ermöglichen sie es Anthos Config Management, Ihre Google-Cloud- und Kubernetes-Ressourcen kontinuierlich abzusichern und zu konfigurieren.

Anthos Fleets (früher Environs) sind ein Google-Cloud-Konzept zur logischen Organisation von Clustern und anderen Ressourcen. So können Sie Multi-Cluster-Funktionen nutzen und verwalten und konsistente Richtlinien systemübergreifend anwenden.

Einschränkungen: Wichtig zu wissen: Der Service kann ausschließlich diejenigen Teile Ihrer Lösung steuern und überwachen, die innerhalb der Anthos-Umgebung laufen.

Datenbank- und Storage-Layer:

• Wenn Sie Ihre Storage- und DB-Schichten außerhalb des Clusters betreiben, können Sie unter Umständen managed DB-Services wie CloudSQL oder RDS nutzen.
• Wenn Sie die DB innerhalb Ihres Kubernetes-Clusters betreiben (z. B. mySQL oder MongoDB), entsteht durch den Eigenbetrieb der DB im Cluster ein erheblicher Mehraufwand im Betrieb – verglichen mit den managed Versionen des Cloud-Anbieters.

Security + Monitoring:

• SIEM + Monitoring: Achten Sie auf Tools, die eine Multicloud-/Hybrid-Cloud-Lösung bieten, etwa Splunk, Datadog oder PagerDuty.
• Security & Secrets Management: Beispiele sind HashiCorp Vault und AWS Secrets Manager.

CI/CD:

• Marktlösungen wie Gitlab und Jenkins funktionieren über verschiedene Umgebungen hinweg und ermöglichen es Ihnen, sowohl Container als auch VMs zu bauen und auszurollen.

Wenn Sie keine VMs bauen und ausrollen müssen, werfen Sie einen Blick auf spinnaker.

Infrastructure Provisioning:

• Zu den Optionen zählen HashiCorp Terraform, Red Hat Ansible und Pulumi.

Fazit:

• Eine Hybrid-/Multicloud-Lösung aufzubauen ist sehr anspruchsvoll und sehr teuer – sowohl mit Blick auf Menschen und Prozesse als auch aus technologischer Sicht.
• Technologien wie GCP Anthos unterstützen Multicloud-Szenarien, doch keine einzelne Technologie liefert eine End-to-End-Lösung. Das sollten Sie beim Design Ihrer Lösungsarchitektur berücksichtigen.
• Für Unternehmen, die Kubernetes bereits produktiv und im großen Maßstab betreiben – ob On-Prem oder in der Cloud –, ist dieser Prozess einfacher.
• Am schwersten fällt er:

  • Unternehmen, die monolithische Legacy-Anwendungen On-Prem betreiben. Der Aufbau einer Hybrid-Lösung und die nötige Transformation von Geschäftsprozessen, Mitarbeiterbefähigung und Tech-Stack können – je nach Komplexität und Umfang – zwischen zwei und zehn Jahren in Anspruch nehmen.

    Genau dorthin entwickelt sich der Markt, und Unternehmen, die diesen Weg gehen, erzielen einen erheblichen ROI. Wer sich auf eine solche Reise begibt, sollte seine Erwartungen jedoch im Bewusstsein der Größenordnung dieser Herausforderung kalibrieren.

  • Startups mit kleinen Teams: Kubernetes ist spannend und reizvoll, und Ihr Startup möchte jeden Kunden in jeder Umgebung bedienen – doch die Ressourcen sind begrenzt, und Sie brauchen ein funktionierendes Produkt mit möglichst geringem operativem und finanziellem Overhead. Angesichts dieser inhärenten Herausforderungen sollten Sie sich zunächst auf ein tragfähiges Produkt (mit Blick auf Workflow-Portabilität) und einen Kundenstamm in einer einzigen Cloud konzentrieren – und dabei so viele vollständig managed Services wie möglich nutzen. Sobald Ihr Team groß genug und die Lösung ausreichend stabil ist, können Sie damit beginnen, Refactoring und den Betrieb einer Multicloud-Lösung auszuloten.

Wenn Sie mehr zu diesem Thema erfahren und auch eine Demo sehen möchten, wie Anthos in einer Multicloud-Umgebung funktioniert, melden Sie sich gerne für unser Event am 22. Februar 2022 um 13:00 Uhr GMT an.

Kontaktieren Sie uns jederzeit, wenn Sie Fragen haben oder Ihren Weg zu einer modernen Anwendung in einer Hybrid- oder Multicloud-Umgebung besprechen möchten.