Dieser Artikel ist Teil einer Reihe.
- Teil 1: Digitale Souveränität – Ein Definitionsversuch
- Teil 2: CIO-Fragestellungen zur digitalen Souveränität
- Teil 3: Digitale Souveränität: Warum die Architektur zählt und wie Sie Ihr Unternehmen resilient machen
- Teil 4: EU-Datenverordnung: Der Anfang vom Ende der Cloud-Monokultur?
- Teil 5: Dateninventare im EU Data Act: Die Demokratisierung der IoT-Geräte
- Teil 6: Der Weg zur heterogenen Cloud Plattform (dieser Artikel)
Viele Unternehmen stehen bei der Integration von On-Premise-Systemen mit Cloud-Plattformen vor erheblichen Herausforderungen – insbesondere, wenn neue Infrastrukturen organisatorisch und technisch eingeführt werden. Diese Transformationen waren in der Regel mit großen Herausforderungen verbunden, vor allem in Bezug auf den organisatorischen und technischen Umgang mit neuen Cloud-Infrastrukturen. Ein unüberlegter Strategiewechsel birgt Risiken: Er kann Transformationsprojekte gefährden und wertvolle Ressourcen binden.
Statt bestehende Strategien zu ersetzen, ist es sinnvoller, die Cloud-Infrastruktur gezielt zu erweitern, indem mehrere Anbieter integriert werden. Beispielsweise kann die Kombination einer US-Cloud und europäischer Cloud-Anbieter Unternehmen den Zugriff auf innovative Dienste sichern und gleichzeitig sicherstellen, dass regulatorische Vorgaben – etwa im Bereich Datenschutz – eingehalten werden. So entsteht eine flexible, zukunftssichere Plattform, die sowohl den geschäftlichen als auch den technischen Anforderungen gerecht wird.
Grundlagen der Multi-Cloud-Verbindung: Der erste Schritt zur Integration
Auf den ersten Blick mögen die notwendigen Schritte und Technologien zur Nutzung mehrerer Cloud-Anbieter komplex erscheinen. Doch die gute Nachricht ist: Die meisten Ansätze und Tools dafür existieren bereits und werden zum Teil direkt von den Cloud-Anbietern bereitgestellt. Nahezu alle Anbieter stellen Dienste bereit, um ein On-Premise-Netzwerk mit der Cloud effizient zu verbinden – dieselben Lösungen lassen sich auch einsetzen, um Netzwerke zwischen verschiedenen Cloud-Anbietern aufzubauen.
Nachdem die Netzwerkverbindung zwischen Cloud-Anbietern als zentrale technische Voraussetzung keine nennenswerte Herausforderung ist, stellt sich die Frage: Wie lassen sich Anwendungen und Daten geschäfts- und regelkonform in eine heterogene Cloud-Infrastruktur integrieren?
Im Folgenden betrachten wir zwei unterschiedliche Strategien – die API-Only-Integration und die Data-Only-Integration –, die Ihnen helfen kann, technische und regulatorische Anforderungen reibungslos in Einklang zu bringen.
API-Only-Integration: Die einfache Lösung für modulare Systeme
Diese Integrationsvariante eignet sich besonders für Systeme, die auf Anwendungsebene modular aufgebaut sind, wie z. B. Microservices oder Self-Contained Systems (SCS). In diesem Ansatz wird die Logik in einem separaten System implementiert. Je nach Komplexität kann dies durch die Entwicklung eines Microservices oder eines vollständig neuen SCS realisiert werden.
Die API-Only-Integration ist dabei die einfachste Art der Integration, da sie keine direkte Netzwerkverbindung über VPN zwischen den beteiligten Systemen voraussetzt. APIs können über das Internet aufgerufen und durch entsprechende Sicherheitsmaßnahmen geschützt werden. Dies reduziert die infrastrukturellen Anforderungen und ermöglicht eine flexible Verbindung zwischen den beteiligten Komponenten.
Auch das Deployment gestaltet sich unkompliziert, da die jeweiligen Bereitstellungsmechanismen der genutzten Cloud-Anbieter direkt verwendet werden können. Ein bedeutender Vorteil dieser Variante ist ihre Flexibilität: API-Only-Integrationen ermöglichen sowohl den Zugriff von europäischen Clouds auf US-basierte Dienste als auch umgekehrt.
Die API-Only-Integration ist eine hervorragende Wahl für modular aufgebaute Systeme, die eine hohe Agilität und Flexibilität erfordern. Sie bietet eine einfache Möglichkeit, unabhängige Services miteinander zu verknüpfen. Allerdings sollten Unternehmen sicherstellen, dass die API-Integrationen robust gegen Latenz und Sicherheitsrisiken sind, insbesondere bei sensiblen Daten oder längeren Netzwerkstrecken. Genau hier setzt die Data-Only-Integration an, die sich stärker auf die Datenhaltung und spezielle regulatorische Anforderungen fokussiert.
Data-Only-Integration: Die Herausforderung der Multi-Cloud-Datenhaltung
Eine Data-Only-Integration erfordert besondere Voraussetzungen und Abwägungen. Vor der Umsetzung muss geprüft werden, ob eine kurzfristige Speicherung der Daten in einem Fremdsystem, z. B. aus technischen Gründen wie Caching, zulässig ist. Außerdem sind mögliche Auswirkungen auf Qualitätsziele zu evaluieren, da VPN-Tunnel tendenziell langsamer sind als eine Standleitung. Aktuell bietet keine Cloud eine Standleitung zu einer anderen Cloud an. Die Verbindung muss zudem redundant aufgebaut werden, um Ausfälle zu vermeiden.
Bei dieser Variante liegt der Fokus darauf, wo die Daten gespeichert werden. Sie ermöglicht es, flexibel auf Anforderungen zu reagieren, wie z. B. der verpflichtenden Speicherung sensibler Daten in einer europäischen Cloud. Zusätzlich erleichtert diese Methode eine spätere Migration der Anwendung in eine andere Cloud-Umgebung. Ein weiterer Anwendungsfall ist, wenn ein notwendiger Dienst in der US-Cloud verfügbar ist, jedoch (noch) nicht in einer europäischen Cloud angeboten wird.
Im Gegensatz zur API-Only-Integration vermeidet die Data-Only-Integration eine unnötige Aufteilung der Anwendung in mehrere Deployment-Einheiten, was zusätzliche Komplexität (wie strikte Reihenfolgen beim Deployment oder eine Verteilung des Datenmodels) mit sich bringen würde. Stattdessen wird ausschließlich die Datenhaltung in der europäischen Cloud realisiert, während die Komponenten mit der Applikationslogik in der US-Cloud betrieben werden. Da Datenbankzugriffe kritische Schnittstellen darstellen, die die Qualitätsziele unmittelbar beeinflusst, ist eine stabile Netzwerkverbindung essenziell. Die sichere direkte Anbindung von Datenbanken über das Internet ist zwar technisch möglich, birgt jedoch hohe Sicherheitsrisiken.
Zum Umsetzen der Datenhaltung aus einer anderen Cloud stehen verschiedene Lösungsansätze zur Verfügung, abhängig von der eingesetzten Technologie und den Anforderungen an Performance, Verfügbarkeit sowie der Richtlinie zur temporären Datenspeicherung. So können beispielsweise ganze Datenbanken in einem anderen Netzwerk bei einem anderen Anbieter betrieben werden. Dies stellt eine einfache Lösung dar, kann jedoch zu Performance-Einbußen führen, die durch Caching oder den Einsatz von Read-Instanzen kompensiert werden können.
Eine andere Möglichkeit besteht in der Nutzung von sogenannten „Remote-Tables“ bei unterstützenden Datenbanksystemen. Hierbei wird lediglich ein spezifischer Teil des Datenmodells – wie beispielsweise Tabellen mit sensiblen Daten – in eine andere Cloud ausgelagert. Dieser Ansatz ist für die Anwendung transparent und begrenzt potenzielle Latenzprobleme auf einen kleinen Teil des Datenmodells.
Die Umsetzung dieser Variante erfordert aufgrund der Abhängigkeiten und technischen Anforderungen etwas mehr Aufwand im Deployment. Lösungen wie „Infrastructure as Code“ (IaC) und die Unterstützung eines dedizierten Plattform-Teams sind hier entscheidend. Sie ermöglichen es, externe Datenhaltung nahtlos in die bestehende Infrastruktur zu integrieren. Manche US-Cloud-Anbieter bieten sogar erweiterbare IaC-Lösungen an, um Ressourcen in fremden Umgebungen bereitzustellen und so die Komplexität zu minimieren.
Strategievergleich: Beide Strategien im Überblick
Die Wahl der passenden Integrationsstrategie hängt stark von den Anforderungen Ihres Unternehmens ab. Im Idealfall können beide Ansätze kombiniert werden, um sowohl technologische als auch regulatorische Anforderungen effizient und flexibel zu erfüllen.
Die Data-Only-Integration ist ideal, um bestehende Systeme schnell und flexibel an neue Anforderungen – wie die Speicherung sensibler Daten in einer bestimmten Region – anzupassen. Im Gegensatz dazu eignet sich die API-Only-Integration hervorragend für die Integration neuer Systeme oder von Alt-Systemen, die in eine moderne Architektur migriert werden.
Von einer künstlichen Aufteilung in isolierte Systeme rate ich dringend ab, da dies zusätzliche Komplexität und potenzielle Probleme verursachen kann. Eine klare und zielgerichtete Strategie ist entscheidend für den Erfolg.
Die folgende Tabelle bietet eine Übersicht über die beiden Integrationsarten und deren Eigenschaften:
| Merkmal | API–Only–Integration | Data–Only–Integration | ||
|---|---|---|---|---|
| Zielsetzung | Integration von Cloud-Anbietern über die Bereitstellung von Schnittstellen. | Speicherung der Daten bei verschiedenen Cloud-Anbietern. | ||
| Architekturvoraussetzungen | Perfekt für modulare Systeme wie Microservices und SCS. | Systeme, die eine Datenhaltung in einer anderen Cloud erfordern; geeignet zur Vorbereitung eines Cloud-Wechsels. | ||
| Einschränkungen | Gefahr einer künstlichen Systemaufteilung, falls eine Abhängigkeit zu einem Cloud-Anbieter besteht. | Datenschutzanforderungen und Qualitätsziele (z.B. Latenz, Verfügbarkeit) müssen berücksichtigt werden. | ||
| Deployment | Nutzung nativer Technologien der jeweiligen Cloud-Anbieter | Integration externer Ressourcen über „Infrastructure as Code” (IaC). | ||
Mit dieser Übersicht können Sie besser abschätzen, welche Strategie – API-Only oder Data-Only – für Ihre spezifischen Anwendungsfälle sinnvoll ist. Wichtig ist, dass Sie eine klare Richtung für Ihre Integrationsstrategie festlegen und unnötige Komplexität vermeiden.
Handlungsempfehlungen
Die Integration mehrerer Cloud-Anbieter in eine heterogene Plattform bietet Unternehmen enorme Chancen, sowohl technische als auch regulatorische Anforderungen zu adressieren. Die beiden vorgestellten Integrationsstrategien – die API-Only-Integration und die Data-Only-Integration – eröffnen flexible Möglichkeiten, bestehende Systeme anzupassen und neue Lösungen in einer hybriden Architektur effizient zu gestalten.
Die wichtigsten Punkte lassen sich zusammenfassen:
- API-Only-Integration ermöglicht eine schnelle und modulare Verbindung zwischen Cloud-Diensten und eignet sich ideal für neue und migrierte Systeme.
- Data-Only-Integration bietet eine effektive Möglichkeit, die Datenhaltung an gesetzliche Vorgaben anzupassen und Systeme ohne unnötige Aufteilung flexibel zu erweitern.
- Beide Ansätze können kombiniert werden, um sowohl technische als auch organisatorische Ziele effizient zu erreichen.
Ein klarer und durchdachter Plan ist der Schlüssel zur erfolgreichen Umsetzung. Vermeiden Sie jedoch unnötige Komplexität, etwa durch die Aufteilung geschlossener Systeme, da dies die Entwicklungs-, Wartungs- und Betriebskosten erhöhen kann.
1.Analyse Ihrer Anwendungen: Identifizieren Sie, welche Anwendungen betroffen sind, und bewerten Sie ihre Abhängigkeit von spezifischen Cloud-Diensten.
2.Evaluierung der Anbieter: Prüfen Sie, welcher europäische Cloud-Anbieter die besten Dienste für Ihre Anforderungen bietet. Achten Sie dabei insbesondere auf die Erfüllung gesetzlicher Anforderungen, wie z. B. Datenschutz.
3.Segmentierung der Dienste: Überlegen Sie, welche Dienste oder Daten in eine europäische Cloud migriert werden können und welche in ihrer bestehenden Umgebung verbleiben müssen.
4.Planung der Integration: Entscheiden Sie auf Basis Ihrer Analyse, wo sich API-Only- oder Data-Only-Integrationen am besten umsetzen lassen. Führen Sie dazu eine Machbarkeitsbewertung durch, die Performance, Sicherheitsstandards und Latenz berücksichtigt.
5.Einbindung eines Plattform-Teams: Stellen Sie sicher, dass Sie über ein erfahrenes Team verfügen, das „Infrastructure as Code“ (IaC) nutzen kann, um eine nahtlose Integration und effizientes Deployment zu gewährleisten.