Google Cloud vs STACKIT: Service-Mapping

Die zwölf Ressourcen des Laufs

Eine für diese Seite geschriebene Umgebung: ein Netzwerk mit einem Subnetz, einer Firewall-Regel und einer virtuellen Maschine, dazu Cloud SQL für PostgreSQL, ein Bucket, Memorystore, ein Pub/Sub-Topic, ein Secret, eine DNS-Zone, Bigtable und ein BigQuery-Dataset. StackToIT hat es am 4. November 2026 bewertet. Die Klassen sind so, wie der Lauf sie festgelegt hat.

Der Lauf zählte 1 DIRECT, 7 RECONFIGURE, 2 REPLATFORM und 2 REDESIGN. Welle 1 enthält neun Einheiten ohne Abhängigkeit, Welle 2 Subnetz und Firewall-Regel, Welle 3 die virtuelle Maschine. Alle zwölf tragen höchstens die Konfidenz MEDIUM: Keine Lock-Datei pinnt den Google-Provider, und der Lauf sagt, dass die Version, die ein Plan nutzen würde, nicht belegt ist.

Drei Datendienste, umgewandelt

Derselbe Lauf. Erster Ausschnitt: die drei Datenblöcke der Eingabe in Dateireihenfolge (main.tf, Zeilen 56 bis 79). Danach ein Ausschnitt je STACKIT-Ressourcenblock, den die Engine geschrieben hat, aus terraform/data.tf und terraform/storage.tf, ohne die Prüfkommentare über jedem Block. Plannamen, Versionen und Zugriffslisten bleiben Variablen, weil die Quelle dafür nichts angibt.

resource "google_sql_database_instance" "main" {
  name             = "shop-db"
  region           = "europe-west3"
  database_version = "POSTGRES_16"

  settings {
    tier = "db-custom-4-15360"
  }

  deletion_protection = true
}

resource "google_storage_bucket" "media" {
  name                        = "shop-platform-prod-media"
  location                    = "EUROPE-WEST3"
  uniform_bucket_level_access = true
}

resource "google_redis_instance" "cache" {
  name           = "shop-cache"
  tier           = "STANDARD_HA"
  memory_size_gb = 4
  region         = "europe-west3"
}

resource "stackit_valkey_instance" "cache" {
  project_id = var.project_id
  name       = "shop-cache"
  plan_name  = var.cache_plan_name
  version    = var.cache_version
  parameters = {
    sgw_acl = join(",", var.cache_allowed_cidrs)
  }
}

resource "stackit_postgresflex_instance" "main" {
  project_id = var.project_id
  name       = "shop-db"
  version    = "16"
  flavor_id  = "4.32"
  storage = {
    class = var.postgresflex_storage_class
    size  = 20
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.main_allowed_cidrs
  }
  retention_days = 32
}

resource "stackit_objectstorage_bucket" "media" {
  project_id = var.project_id
  name       = "shop-platform-prod-media"
}

• Werte zum Bestätigen

  Der Datenbank-Tier db-custom-4-15360 (4 vCPU, 15 GiB) wurde zu flavor_id 4.32; der Entwurf erklärt das als 4 vCPU und 32 GiB, den kleinsten Single-Node-Flavor von PostgreSQL Flex in eu01, der die Quelle abdeckt. Außerdem setzt der Entwurf ein tägliches Backup um 02:00 Uhr und 32 Tage Aufbewahrung; seine Kommentare nennen das einen Standardwert und das STACKIT-Minimum, weil die Quelle beides nicht angibt. Die Valkey-Zugriffsliste hat keinen Standardwert, und eine leere Liste lehnt der Entwurf ab: Sie müssen die Client-Bereiche nennen. Bestätigen Sie all das vor dem Plan.

Weitere Dienste in der kuratierten Zuordnung

Dienste, die dieser Lauf nicht enthielt. Sie stammen aus der Zuordnung, die StackToIT für Google Cloud pflegt, nicht aus diesem Lauf; lesen Sie die Klasse daher als die übliche, nicht als Ergebnis.

Memorystore ist in diesem Lauf RECONFIGURE; die kuratierte Zuordnung lässt je nach Konfiguration auch REPLATFORM zu.

Konfigurationsunterschiede, die in der Praxis wehtun

Die ersten sieben Zeilen stammen aus Befunden und Entwurfskommentaren dieses Laufs. Die beiden DNS-Zeilen stammen aus dem Cloud-DNS-Lauf hinter unserem DNS-Cutover-Runbook und aus der STACKIT-DNS-Dokumentation, denn diese Umgebung enthält nur eine unsignierte öffentliche Zone und keine private.

So lesen Sie die Zuordnung

• Die Klasse ist die Art der Arbeit

  RECONFIGURE heißt: Ein Gegenstück existiert, Einstellungen ändern sich. REPLATFORM heißt: ein anderes Plattformmodell. REDESIGN heißt: Die Architektur ändert sich. Keine Klasse ist für sich genommen eine Freigabe.

• Offene Einstellungen lesen, nicht nur die Klasse

  Auch bei einer DIRECT-Zone bleibt die Umstellung der Nameserver beim Registrar Ihre Aufgabe, und ein REPLATFORM-Topic lässt Namen und Zustelleinstellungen offen. Klasse und offene Entscheidungen sind zwei verschiedene Antworten.

• Mit den REDESIGN-Zeilen beginnen

  Sie haben kein Gegenstück und bestimmen damit Zeitplan und Budget. Die Wellen folgen nur den Abhängigkeiten: Bigtable und BigQuery stehen in Welle 1, weil in dieser Umgebung nichts von ihnen abhängt, nicht weil der Lauf sie vorzieht. Beginnen Sie die Designarbeit dafür vor den übrigen Einheiten, egal in welcher Welle sie stehen.

• Provider pinnen, bevor Sie der Konfidenz trauen

  Der Lauf hält fest, dass Einheiten eines Providers ohne Eintrag in der Lock-Datei höchstens die Konfidenz MEDIUM erhalten. Committen Sie die Lock-Datei, die den Google-Provider pinnt, und starten Sie den Lauf erneut; was danach noch MEDIUM ist, ist es aus eigenem Grund.

Fragen von Architekten

Quellen

• STACKIT-Dokumentation: RabbitMQ
• STACKIT-Dokumentation: DNS-Produktüberblick
• STACKIT-Dokumentation: MongoDB Flex
• Google-Cloud-Dokumentation: Pub/Sub-Subscriptions
• Google-Cloud-Dokumentation: Bigtable-Überblick
• Google-Cloud-Dokumentation: Cloud-DNS-Zonen