Eine erfolgreiche Multicloud-Strategie erfordert eine Architektur, die auf die Anforderungen Ihres Application-Workload-Portfolios zugeschnitten ist. Erfahren Sie, welche verteilten und redundanten Deployment-Muster dabei weiterhelfen.
Mit dem richtigen Deployment-Muster zum Multicloud-Erfolg
Eine durchdachte Multicloud-Strategie hilft Unternehmen, ihre Geschäftsziele zu erreichen. Doch der Weg durch die Multicloud verlangt einen klugen architektonischen Ansatz, damit die verschiedenen Cloud-Dienste reibungslos zusammenspielen. Sie müssen Ihre Architektur an die Anforderungen Ihres individuellen Portfolios an Application Workloads anpassen – zum Glück können Sie sich dabei auf einige bewährte Muster stützen.
Diese Muster basieren entweder auf verteiltem oder auf redundantem Deployment:
- Verteilte Deployment-Muster führen Anwendungen jeweils in der am besten geeigneten Computing-Umgebung aus und nutzen dabei die unterschiedlichen Eigenschaften und Stärken der einzelnen Umgebungen.
- Redundante Deployment-Muster stellen dieselben Anwendungen in mehreren Computing-Umgebungen bereit, um Kapazität oder Ausfallsicherheit zu erhöhen.
Verteilte Deployment-Muster
Verteilte Muster suchen die Balance zwischen den Einschränkungen bestehender Anwendungen und dem besonderen Potenzial jeder Computing-Umgebung. Bei der Wahl des passenden Musters sollten Sie Faktoren wie Agilität, Skalierungspotenzial, Sicherheit und Zuverlässigkeit berücksichtigen.
Tiered Hybrid
Beim Tiered-Hybrid-Deployment-Muster verlagern Sie zunächst bestehende Frontend-Anwendungen fallweise in die Public Cloud, während bestehende Backend-Anwendungen in ihrer privaten Computing-Umgebung verbleiben. Mit der Zeit verlagern Sie womöglich auch Backend-Anwendungen in die Public Cloud, denn der Anteil der in der Cloud betriebenen Anwendungen wächst stetig.
Frontend-Anwendungen zuerst zu priorisieren, ist aus gutem Grund sinnvoll: Frontends hängen von Backends ab, umgekehrt gilt das nicht. Dank ihrer wenigen Abhängigkeiten lassen sich Frontend-Anwendungen in der Regel leichter isolieren und migrieren als Backends. Die Bereitstellung in der Public Cloud bietet sich an, weil sie häufiger Änderungen unterworfen sind als Backends und stark von der Flexibilität der Cloud profitieren. Die Cloud vereinfacht den Aufbau eines Continuous-Integration-/Continuous-Deployment-Prozesses (CI/CD) für effiziente, automatisierte Updates, und Funktionen wie Load Balancing, multiregionale Deployments und Autoscaling steigern die Performance.
Bei Backends, die Daten mit strengen Compliance-Anforderungen verwalten, kann es klug sein, sie in einer privaten Computing-Umgebung zu belassen. Viele Länder schreiben Datenlokalisierung vor – Unternehmen müssen Daten also lokal speichern und verarbeiten. So enthält etwa die EU-Datenschutz-Grundverordnung (DSGVO) strenge Vorgaben zur Speicherung personenbezogener Daten, die sich oft am besten mit einer On-Premises-Lösung umsetzen lassen.
Partitioned Multicloud
Das Partitioned-Multicloud-Muster ermöglicht es Ihnen, workloads zwischen den Public-Cloud-Umgebungen verschiedener Anbieter zu verschieben. Workload-Portabilität ist entscheidend, um Anwendungen flexibel in der jeweils am besten geeigneten Computing-Umgebung zu betreiben. Dazu müssen Sie die Unterschiede zwischen den Umgebungen abstrahieren, sodass sich workloads zwischen mehreren Computing-Umgebungen verschieben lassen.
Partitioned-Multicloud-Muster helfen Ihnen, Vendor-Lock-in zu vermeiden, weil Sie nicht an einen einzelnen Cloud-Anbieter gebunden sind. workloads bei Bedarf in alternative Umgebungen zu verlagern, schützt vor Ausfallrisiken und gibt Ihnen die Freiheit, bei jedem Anbieter genau die Funktionen auszuwählen, die am besten passen.
Die für dieses Muster nötige Workload-Portabilität ermöglicht es zudem, den Betrieb beim Verlagern von workloads von einer Umgebung in die andere zu optimieren. Workload-Portabilität hat jedoch auch Schattenseiten: Sie verursacht zusätzlichen Aufwand in Entwicklung, Test und Betrieb. Wer konsequent auf Workload-Portabilität entwickelt, riskiert außerdem, die gewählte Cloud-Plattform auf den kleinsten gemeinsamen Nenner zu reduzieren – die voll verwalteten Dienste des Cloud-Anbieters bleiben dann ungenutzt. Auch Egress-Kosten können schnell aus dem Ruder laufen.
Containerisierung erleichtert die Workload-Portabilität, und Kubernetes baut darauf auf, indem es Unternehmen hilft, Vendor-Lock-in zu vermeiden.
Analytics- und ML-Hybrid und -Multicloud
Bei diesem Muster bleiben transaktionale Systeme On-Premises, während analytische workloads in die Cloud wandern und bei Bedarf Daten zurückspielen. Transaktionale Systeme erledigen das Tagesgeschäft in Bereichen wie Finanzen, Kommunikation und Vertrieb. Analytische workloads umfassen Anwendungen, die Daten verarbeiten oder visualisieren, um entscheidungsrelevante Erkenntnisse zu liefern. Dieses Muster nutzt die Trennung zwischen beiden Systemen, um jede Art von Workload in einer eigenen Computing-Umgebung zu betreiben.
Wenn Sie Analytics-workloads in der Cloud betreiben, können Sie Compute-Ressourcen dynamisch skalieren und große Datenmengen schnell verarbeiten, ohne Ressourcen überdimensionieren zu müssen. Die großen Cloud-Anbieter stellen zudem umfassende Dienste bereit, mit denen sich Daten von der Erfassung über den gesamten Lebenszyklus hinweg verwalten lassen.
Edge Hybrid
Eine durchgehende Konnektivität ist Voraussetzung, um workloads in der Cloud zu betreiben – doch die ist nicht immer gegeben. Standorte wie Schiffe, Supermärkte oder bestimmte Produktionsanlagen verfügen oft nicht über zuverlässigen Internetzugang, sind aber zugleich zentrale Schauplätze für das Internet of Things (IoT), das Konnektivität benötigt, damit eingebettete Sensoren und Chips wertvolle Daten senden und empfangen können. Hier kommt das Edge-Hybrid-Muster ins Spiel: Es führt zeit- und geschäftskritische workloads lokal am Rand des Netzwerks aus und betreibt alle übrigen workloads in der Cloud.
Werden zeit- und geschäftskritische workloads lokal ausgeführt, sorgt das für niedrige Latenzen und Eigenständigkeit. Wichtige Transaktionen laufen selbst dann durch, wenn die Internetverbindung wackelt. Mit diesem Muster profitieren Sie weiterhin davon, dass ein erheblicher Teil Ihrer workloads in der Cloud läuft. Damit das funktioniert, sollten die Abhängigkeiten zwischen Edge-Systemen und Systemen in der Cloud-Umgebung so gering wie möglich gehalten werden.
Redundante Deployment-Muster
Bei redundanten Deployment-Mustern werden dieselben Anwendungen in mehreren Computing-Umgebungen bereitgestellt, um Kapazität oder Ausfallsicherheit zu erhöhen.
Hybrid Environment
Ein Hybrid-Environment-Muster kann sowohl redundant als auch verteilt sein. Es nutzt Public-Cloud-Umgebungen für Entwicklung, Test und UAT und betreibt produktive workloads in privaten Rechenzentren. Vorgaben aus Regulierung und Compliance können die Cloud-Migration für Produktivumgebungen und deren Daten erschweren – für andere Umgebungen jedoch nicht.
Wenn Sie die Public Cloud für Entwicklung und funktionale Tests einsetzen, können Sie Umgebungen nach Bedarf hochfahren und wieder abbauen. Außerdem lassen sich Kosten steuern, indem Sie ungenutzte virtuelle Maschinen stoppen oder Umgebungen ausschließlich on demand bereitstellen.
Business-Continuity-Hybrid und -Multicloud
Disaster-Recovery-Planung (DR) ist unerlässlich, um Systeme nach Naturkatastrophen oder von Menschen verursachten Vorfällen wiederherzustellen. Ein zentrales Element sind häufige Daten-Backups an unterschiedlichen geografischen Standorten, um das Recovery Point Objective (RPO) zu minimieren. Standby-Systeme (kalt, warm oder heiß, je nach Latenz) an einem zweiten Standort können zudem helfen, das Recovery Time Objective (RTO) zu senken.
Ein kostengünstigerer Ansatz ist es jedoch, die Public Cloud als DR-Umgebung zu nutzen – das ist die Grundidee des Business-Continuity-Hybrid-Musters. Dieses Muster kann im Ernstfall sogar die tatsächliche Wiederherstellungszeit verkürzen, weil sich die DR-Umgebung mit Infrastructure as Code schneller hochfahren lässt.
Cloud Bursting
Die Kosten für stark schwankende workloads in On-Premises-Umgebungen können schnell aus dem Ruder laufen, weil Sie Ressourcen überdimensionieren müssen, um Lastspitzen abzudecken. Das Bursting-Deployment-Muster setzt für Grundlasten auf eine private Computing-Umgebung und weicht nur dann in die Cloud aus, wenn zusätzlich skaliert werden muss. Deshalb eignet es sich besser für Batch-workloads als für interaktive workloads. Entscheidend ist die Workload-Portabilität.
Einer der Hauptvorteile dieses Musters: Sie nutzen Ihre bestehenden Investitionen in On-Premises-Umgebungen weiter. Womöglich lassen sich Ihre privaten Computing-Umgebungen sogar effizienter auslasten, weil Sie keine Ressourcen für Lastspitzen vorhalten müssen.
Wie geht es weiter?
Der Aufbau einer Hybrid- oder Multicloud-Lösung ist mit komplexen Entscheidungen verbunden – nicht zuletzt beim Design der passenden Architektur. Bevor Sie Entscheidungen treffen, sollten Sie Ihre Unternehmenskultur, Ihre DevOps-Praktiken und Ihren Tech-Stack auf den Prüfstand stellen. Keine einzelne technische Lösung wird Ihren individuellen Anforderungen vollständig gerecht – die Antwort liegt aber häufig in einer Kombination der hier beschriebenen verteilten und redundanten Deployment-Muster. Ein erfahrener Cloud-Partner zeigt Ihnen, wie Sie Multicloud optimal für Ihre konkreten Geschäftsziele nutzen.