AWS, Azure, Google Cloud, Huawei, Alibaba und Oracle Cloud für die STACKIT-Migration im Vergleich

Dieselbe Datenbank als Entwurf aus Azure

Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links der PostgreSQL Flexible Server der Azure-Eingabe. Rechts die STACKIT-PostgreSQL-Flex-Instanz, die die Engine daraus geschrieben hat (die Prüfkommentare über dem Block in der Datei sind ausgelassen). Die Umgebungen für AWS und Google Cloud ergeben dieselbe Instanz mit ihren eigenen Quellwerten.

resource "azurerm_postgresql_flexible_server" "orders" {
  name                   = "pg-orders"
  resource_group_name    = azurerm_resource_group.orders.name
  location               = azurerm_resource_group.orders.location
  version                = "16"
  administrator_login    = "orders"
  administrator_password = var.db_password
  sku_name               = "GP_Standard_D4s_v3"
  storage_mb             = 204800
  backup_retention_days  = 14
  zone                   = "1"

  high_availability {
    mode                      = "ZoneRedundant"
    standby_availability_zone = "2"
  }
}

resource "stackit_postgresflex_instance" "orders" {
  project_id = var.project_id
  name       = "pg-orders"
  version    = "16"
  flavor_id  = "4.32-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 200
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.orders_allowed_cidrs
  }
  retention_days = 32
}

• Die Größe kommt aus der Quelle

  Die Quell-SKU hat 4 vCPU und 16 GiB. Der Entwurf wählt den Flavor 4.32-replica (4 vCPU, 32 GiB), den kleinsten PostgreSQL-Flex-Flavor mit Hochverfügbarkeit im vom Lauf gelesenen eu01-Katalog, weil die Quelle einen zonenredundanten Standby betreibt. STACKIT beschreibt ein Replica-Set als drei Knoten, die einander spiegeln; zur Zonenverteilung und zum Failover macht der Lauf keine Aussage.

• Die Aufbewahrung wird umgewandelt

  Die Quelle hält Backups 14 Tage. Der Entwurf setzt retention_days auf 32 und markiert die Zeile im Ledger als TRANSFORMED, damit niemand sie für eine gleichwertige Einstellung hält.

• Zugriff und Zonen entscheiden Sie

  Die Instanz erhält eine Zugriffsliste aus einer Variable ohne Standardwert. Quell- und Standby-Zone werden nicht erzeugt; der Lauf hält beides als nicht übernommen fest.

Wo ein Entwurf endet: Huawei Cloud und Oracle Cloud

Aus zwei der Läufe. Die Läufe für Huawei Cloud, Alibaba Cloud und Oracle Cloud schreiben in diesem Build keine STACKIT-Ressourcenblöcke, nur Bewertung, Plan und Variablen; der Beleg ist deshalb der Bewertungseintrag. Links die Huawei-RDS-Einheit, rechts das Oracle-Datenbanksystem. Beide Einträge sind auf id, class, confidence, target und reason gekürzt; der Oracle-Eintrag hat gar kein target.

{
  "id": "huaweicloud_rds_instance.orders",
  "class": "REPLATFORM",
  "confidence": "MEDIUM",
  "target": {
    "service": "STACKIT PostgreSQL Flex"
  },
  "reason": "Managed PostgreSQL to managed PostgreSQL: data moves with pg_dump/pg_restore or logical replication, and the flavor becomes a Flex flavor."
}

{
  "id": "oci_database_db_system.orders",
  "class": "REDESIGN",
  "confidence": "LOW",
  "reason": "STACKIT has no Oracle Database service. Decide whether the database changes engine, with a schema and procedure conversion, or stays on self-managed Oracle under your own licence."
}

• Gleiche Engine, klares Ziel

  Verwaltetes PostgreSQL bei Huawei Cloud, Alibaba Cloud, AWS, Azure und Google Cloud ist REPLATFORM mit MEDIUM-Konfidenz und landet in PostgreSQL Flex. Die Daten werden mit pg_dump und pg_restore oder per logischer Replikation übertragen.

• Kein Oracle-Dienst bei STACKIT

  Das Oracle-Datenbanksystem ist REDESIGN mit LOW-Konfidenz und ohne Zieldienst. Der Eintrag verlangt die Entscheidung zwischen einer neuen Engine mit Schema- und Prozedurkonvertierung und selbst betriebenem Oracle unter eigener Lizenz.

Sechs Quellen, eine Anwendung

Jede Zeile ist ein Lauf derselben Anwendungsform: Netzwerk mit Subnetz, virtuelle Maschine, verwaltete PostgreSQL-Datenbank und Objekt-Bucket. Die AWS-Umgebung hat ein zweites Subnetz für die Datenbank; die Umgebungen für Huawei Cloud und Alibaba Cloud enthalten zusätzlich die Security Group, die Datenbank oder Server brauchen, und jeder der beiden Läufe ordnet sie STACKIT Security Groups zu.

Zahlen wie in den Läufen ausgewiesen. Jede Einheit hat MEDIUM-Konfidenz, außer dem Oracle-Datenbanksystem mit LOW. Es sind kleine Umgebungen; sie zeigen die Form jeder Quelle, nicht den Aufwand Ihrer Umgebung.

Dienst für Dienst: wo sich die Quellen unterscheiden

Die Kubernetes-Zeilen stammen aus getrennten Läufen eines Clusters samt Netzwerk, je einem pro Quell-Cloud. Die Node-Pool-Zeilen zeigen eine Abdeckungslücke dieses Builds, keine Eigenschaft der Clouds. In den Läufen für EKS, AKS und GKE wird der Node Pool als Teil der Cluster-Einheit bewertet (seine Einstellungen stehen in assessment.json bei dieser Einheit); deshalb hat er dort keine eigene Zeile.

Optionen, eine gemischte Umgebung zu staffeln

Allgemeine Praxis für Umgebungen, die aus mehr als einer Cloud stammen. Jeder StackToIT-Lauf liest ein Root-Modul; eine gemischte Umgebung besteht daher aus mehreren Läufen.

So entscheiden Sie

1. 01

   Von den Klassen ausgehen, nicht von der Cloud

   Lesen Sie die Klassenspalte jedes Laufs, bevor Sie die Quellen reihen. REDESIGN- und MANUAL_REVIEW-Einheiten, etwa eine Oracle Database oder ein Node Pool ohne Katalogeintrag, bestimmen den Zeitplan stärker als die Zahl der Ressourcen.

2. 02

   Prüfen, was der Lauf geschrieben hat

   Öffnen Sie terraform/ in jeder Ausgabe. Ein Ordner nur mit terraform.tf, variables.tf und README.md heißt: Der Plan existiert, aber die Ressourcenblöcke schreibt der Architekt.

3. 03

   Das Projektlayout einmal festlegen

   Der Migrationsplan jedes der sechs Läufe beginnt mit demselben offenen Punkt: STACKIT-Organisation, Ordner und Projekte sind angelegt, üblich ist zum Start ein Projekt je Umgebung. Klären Sie das einmal für die Gesamtumgebung und übernehmen Sie die Antwort in jeden Quelllauf.

4. 04

   Ein Entscheidungsregister für die ganze Umgebung

   decisions.json unterscheidet sich je Lauf: 16 offene Entscheidungen bei AWS, 12 bei Azure, 10 bei Google Cloud und keine bei Huawei Cloud, Alibaba Cloud und Oracle Cloud, deren Einheiten vollständig beim Architekten liegen. Führen Sie die offenen Entscheidungen vor der Planung der ersten Welle in einer Liste zusammen, ergänzen Sie eigene für die drei Quellen ohne Entwurf und geben Sie jeder einen Verantwortlichen.

5. 05

   Engine-spezifische Punkte früh testen

   Die Prüfzeilen jeder Datenbankeinheit nennen, was zu testen ist. In der AWS-Datenumgebung hinter unserem Leitfaden zur Datenbankarchitektur waren das die Erweiterungsliste bei PostgreSQL, SQL-Agent-Jobs, Linked Server und CLR-Assemblies bei SQL Server sowie Authentifizierungs-Plugins bei MySQL auf dem Weg zu MariaDB.

Fragen von Architekten

Quellen

• STACKIT Object Storage: Überblick
• STACKIT Kubernetes Engine: Überblick
• STACKIT PostgreSQL Flex: Überblick
• Architektur von STACKIT PostgreSQL Flex