Projekt anfragen
Türkisfarbene Glasfaser-Patchkabel an einem Verteilerfeld in einem Rechenzentrum, Schärfentiefe vor dunklem Hintergrund

Multi-Cloud · Hybrid-Cloud · Migration

Multi-Cloud- und Hybrid-Cloud-Migration

Ihre Systeme sollen bewusst auf Rechenzentrum und Cloud oder auf mehrere Anbieter verteilt laufen. SKAFFON entscheidet die Platzierung je Workload, baut die Verbindungen zwischen den Umgebungen und betreibt das Ganze über Plattformgrenzen hinweg.

Projekt anfragen Zur Platzierungsmatrix
  • AWS, Azure, Google Cloud, STACKIT
  • Hybrid: Rechenzentrum plus Cloud
  • Jede Verbindung im Kopplungsregister

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Wenn eine einzige Zielplattform nicht reicht

Diese Leistung richtet sich an IT-Leitung und CTOs, bei denen eine einzelne Zielplattform fachlich, technisch oder regulatorisch nicht ausreicht. Am Ende des Projekts sind Ihre Systeme bewusst verteilt: etwa auf Rechenzentrum und Cloud (Hybrid) oder auf zwei und mehr Anbieter wie AWS, Azure, Google Cloud und STACKIT (Multi-Cloud).

Dazu gehören die Platzierungsentscheidung je Workload, die Verbindung der Umgebungen (Netzwerk, Namensauflösung, Identitäten), die schrittweise Migration und der Betrieb über Plattformgrenzen hinweg.

Eine Migration auf genau eine Zielplattform behandelt die Seite Cloud-Migration. Dieses Projekt ist ein anderes, weil die Verbindungen zwischen den Plattformen selbst zum Gegenstand werden.

Blau beleuchtete Server-Einschübe mit Festplattenschächten in einem Serverschrank

02Begründung

Ein Verteilungsmodell muss sich in einem Satz begründen lassen

Jede zusätzliche Plattform bedeutet eine weitere Identitäts-, Netzwerk-, Kosten- und Betriebswelt. Im Assessment hinterfragen wir das Modell, auch wenn das Ergebnis „eine Plattform genügt“ lautet.

Gründe, die tragen

  • Daten oder Anwendungen müssen aus regulatorischen Gründen in einer bestimmten Umgebung bleiben.
  • Ein Dienst existiert nur bei einem Anbieter.
  • Teile des Bestands lassen sich (noch) nicht verlagern.
  • Eine Konzernstruktur hat bereits mehrere Plattformen geerbt.
  • Der Ausstieg aus einer Abhängigkeit läuft schrittweise über Jahre, siehe Cloud Exit und Portabilität.

Gründe, die nicht tragen

  • „Multi-Cloud, weil man das so macht“.
  • Es gibt nur einen echten Zielort und Multi-Cloud wäre Selbstzweck. Dann empfehlen wir die einfachere Cloud-Migration.
  • Niemand in Ihrem Haus ist für den Betrieb mehrerer Plattformen verantwortlich und es soll auch niemand aufgebaut werden. Alternativ kann SKAFFON den Betrieb übernehmen (Managed Cloud Services).

03Eingaben

Was wir für die Platzierung von Ihnen brauchen

Ohne diese Angaben bleibt die Platzierung eine Vermutung.

  • Inventar der Workloads mit Abhängigkeiten (Datenflüsse, Latenzempfindlichkeit, Datenvolumen), siehe Cloud Readiness Assessment
  • Regulatorische und vertragliche Vorgaben je Datenklasse (Standort, Betreiberkontrolle)
  • Bestehende Identitätsquelle und Netzwerkanbindung der Standorte
  • Vorhandene Cloud-Verträge und Konten, Laufzeiten, Lizenzbindungen
  • Betriebsmodell: Welches Team betreibt welche Plattform heute, mit welchen Werkzeugen
  • Termine mit harter Wirkung (Vertragsende, Lizenzablauf)

04Platzierung

Welcher Workload gehört wohin?

Die Matrix zeigt, welche Merkmale eines Workloads die Platzierung bestimmen. Sie ist ein Diskussionsraster für das Assessment, keine automatische Entscheidung.

Platzierung nach Workload-Merkmal
Merkmal des WorkloadsHinweis für die PlatzierungZu prüfen
Strenge Vorgaben zu Datenstandort oder BetreiberkontrollePlattform wählen, die die Vorgabe erfüllt; ggf. souveräne Cloud oder STACKITVertragliche und rechtliche Prüfung liegt bei Ihnen, technische Umsetzung bei uns
Eng gekoppelt an eine DatenbankAnwendung und Datenbank gemeinsam platzierenLatenz und Datenvolumen zwischen den Umgebungen; Datenbank-Strategie in Datenbankmigration
Nutzt einen plattformspezifischen Dienst ohne EntsprechungBei dieser Plattform belassen oder Portabilität bewusst herstellenAufwand der Ablösung, Folgekosten des Verbleibs
Zustandslos, containerisiertFrei platzierbar; Kubernetes als gemeinsame Schicht möglichNur sinnvoll, wenn Ihr Team Kubernetes betreibt, siehe Kubernetes-Beratung
Hohe Datenmengen, viel Verkehr zu anderen SystemenNahe an den Datenquellen platzierenDatenübertragungsentgelte zwischen den Umgebungen
Spezialhardware (z. B. GPU)Dort, wo Kapazität und Preismodell passenVerfügbarkeit, siehe GPU- und KI-Infrastruktur
Ohne Änderungsdruck, stabil im RechenzentrumHybrid: im Rechenzentrum belassen, Anbindung bauenRestlaufzeit der Hardware und Verträge

05Zielbild

Vier Umgebungen auf einer gemeinsamen Grundlage

Rechenzentrum, Public Cloud, souveräne Cloud und eine weitere Plattform hängen verschlüsselt an derselben Grundlage aus Identität, DNS, Protokollen und Infrastructure as Code.

Hybrid- und Multi-Cloud-Zielbild mit Kopplungsregister Vier Umgebungen (Rechenzentrum, Public Cloud, souveräne Cloud, weitere Plattform) sind über verschlüsselte Verbindungen mit einer gemeinsamen Identitätsquelle und zentraler Beobachtung verbunden. Jede Verbindung ist im Kopplungsregister erfasst. Gemeinsame Grundlage Identität · DNS Protokolle · IaC RechenzentrumPublic Cloud Souveräne CloudWeitere Plattform Bestand, stabile SystemeElastische Workloads Strenge DatenvorgabenDienst ohne Entsprechung Verbindung mit Latenz-, Volumen- und Ausfallverhalten Jede Verbindung steht im Kopplungsregister verschlüsseltverschlüsselt verschlüsseltverschlüsselt Zielbild: bewusst verteilt, gemeinsam betrieben
Hybrid- und Multi-Cloud-Zielbild mit Kopplungsregister Vier Umgebungen (Rechenzentrum, Public Cloud, souveräne Cloud, weitere Plattform) sind über verschlüsselte Verbindungen mit einer gemeinsamen Grundlage aus Identität, DNS, Protokollen und Infrastructure as Code verbunden. Jede Verbindung ist im Kopplungsregister erfasst. Zielbild: bewusst verteilt, gemeinsam betrieben RechenzentrumPublic Cloud Souveräne CloudWeitere Plattform Bestand, stabileSysteme ElastischeWorkloads StrengeDatenvorgaben Dienst ohneEntsprechung verschlüsseltverschlüsselt verschlüsseltverschlüsselt Gemeinsame Grundlage Identität · DNS Protokolle · IaC Verbindung mit Latenz-, Volumen- und Ausfallverhalten Jede Verbindung steht im Kopplungsregister

06Ablauf

Von der Platzierung zum Betrieb über Plattformgrenzen

Sechs Schritte, in denen die Verbindungen zwischen den Umgebungen immer mitgeplant werden.

  1. 01

    Platzierung

    Ergebnis: Entscheidungen

    Für jeden Workload eine begründete Zielplattform nach den Kriterien der Matrix. Ergebnis sind Entscheidungen mit Begründung und offenen Punkten.

  2. 02

    Zielarchitektur

    Ergebnis: Zielarchitektur

    Cross-Cloud-Netzwerk (Adressplan ohne Überschneidung, Verbindungsart, Routing), Namensauflösung (DNS) über Plattformgrenzen, hybride Identitäten (eine maßgebliche Identitätsquelle, Rollenmodell je Plattform), Protokollierung und Überwachung an einem Ort.

  3. 03

    Grundlage je Plattform

    Ergebnis: Landing Zones als Code

    Je Zielplattform eine Landing Zone mit identischer Struktur, soweit die Plattformen das zulassen, als Code.

  4. 04

    Pilot mit Anbindung

    Ergebnis: erste Kopplung

    Ein Workload mit überschaubarer Kopplung wandert zuerst, inklusive der Verbindung zum Rest.

  5. 05

    Migrationswellen mit Cutover und Rollback

    Ergebnis: Wellen mit Rückweg

    Gruppierung nach Abhängigkeit, nicht nach Plattform. Vorgehen wie in der Cloud-Migration; zusätzlich wird die Kopplung zwischen Wellen geprüft, die auf verschiedenen Plattformen landen.

  6. 06

    Betrieb über Plattformen

    Ergebnis: laufender Betrieb

    Gemeinsame Beobachtung, einheitliche Bereitstellung per Infrastructure as Code (Infrastructure as Code), Kostenzuordnung über Plattformen (Cloud-Kostenoptimierung).

07Kopplungsregister

Jede Verbindung zwischen Umgebungen wird erfasst

Der wichtigste Unterschied zur Einzel-Plattform-Migration: Verbindungen zwischen Umgebungen sind Betriebsrisiko und Kostenpunkt. Wir führen sie in einem Register.

Zu Entgelten: Für den parallelen Betrieb von Datenverarbeitungsdiensten erlaubt der EU Data Act den Anbietern, Datenübertragungsentgelte zu erheben, allerdings nur zur Weitergabe der tatsächlich entstandenen Kosten (Art. 34 Abs. 2 der Verordnung (EU) 2023/2854). Welche Entgelte Ihre Anbieter konkret berechnen, entnehmen wir Ihren Verträgen und Preislisten und rechnen sie im Register durch. Weiteres zum Thema: Cloud Exit und Portabilität.

  • Quelle und Ziel (Workload, Plattform, Netz)
  • Art: Anwendungsaufruf, Datenreplikation, Batch, Verwaltungszugriff
  • Verbindungsweg (etwa IPsec-VPN oder dedizierte Leitung, je nach Anforderung) und Redundanz
  • Latenz-Toleranz und Verhalten bei Ausfall der Verbindung (degradiert, wartet, fällt aus)
  • Datenvolumen pro Zeiteinheit und erwartete Übertragungsentgelte
  • Sicherheitsmaßnahme (Verschlüsselung, Zugriffsbeschränkung, Protokollierung)
  • Verantwortlicher und Überwachungs-Messgröße
Draufsicht auf ein Glasfaser-Patchfeld mit zahlreichen angeschlossenen Kabeln

08Grenzen

Wo Sicherheit und Zuständigkeit verlaufen

  • Eine maßgebliche Identitätsquelle

    Berechtigungen je Plattform werden aus Rollen abgeleitet, nicht von Hand gepflegt. Siehe IAM und Zero Trust.

  • Verschlüsselte, begrenzte Verbindungen

    Verbindungen zwischen Umgebungen sind verschlüsselt und auf die im Register genannten Flüsse beschränkt.

  • Protokolle an einem Ort

    Protokolle werden zentral gesammelt; Aufbewahrung und Zugriff legen Sie fest.

  • Technik bei uns, Recht bei Ihnen

    Wir bewerten und setzen technische Maßnahmen um. Rechtliche Bewertung (etwa Auftragsverarbeitung je Anbieter) bleibt bei Ihnen. Siehe Cloud Security.

Abgrenzung

Aktiv-aktiv bei mehreren Anbietern ist kein Migrationsversprechen

Wenn dieselbe Anwendung ohne Änderung gleichzeitig „aktiv-aktiv“ bei mehreren Anbietern laufen soll, ohne die Kosten und die Anwendungsänderungen dafür zu betrachten, passen wir nicht. Das ist ein Architekturprojekt mit eigener Bewertung.

09Angebot

Was ein Angebot für mehrere Plattformen bestimmt

Was den Aufwand bestimmt, steht unten; Umfang und Preis des Angebots folgen daraus. Es entsteht nach Inventar und Platzierungsworkshop, mit Phasen, Ergebnissen und Annahmen.

10Nachbarthemen

Wenn nur ein Zielort bleibt oder der Betrieb fehlt

Anfrage

Nennen Sie uns Plattformen, Gründe und ersten Termin

Welche Plattformen sind beteiligt, warum soll verteilt werden und welcher Termin ist der erste harte?

Projekt anfragen Alle Leistungen