Cloud-Migration zu STACKIT: der vollständige Enterprise-Leitfaden

Die sieben Phasen

Das STACKIT Migration Framework beschreibt vier Phasen: Assess, Design and Mobilize, Migrate und Run. Die sieben Phasen unten teilen denselben Weg in Abschnitte, die ein Team besetzen kann, und verknüpfen jede mit dem, was ein StackToIT-Lauf schreibt.

1. 01

   1 · Die Umgebung lesen

   Eine Standardbewertung liest Terraform oder OpenTofu oder einen VMware-RVTools-Export auf Ihrem eigenen Rechner. Ergebnis: assessment.json mit jeder Einheit sowie Zahlen zu Ressourcen, Modulen und bedingten Einheiten. Wie Sie die Datei lesen, zeigt der Leitfaden zur Bestandsaufnahme.

2. 02

   2 · Jede Ressource einordnen

   Jede Einheit erhält eine Klasse, eine Konfidenz, ein STACKIT-Ziel und eine ausdrückliche Begründung. Die Klasse sagt, wie viel Arbeit es ist; die Begründung sagt, warum. Siehe die Klassen unten.

3. 03

   3 · Entscheiden, was Code nicht sagt

   Größen, Endpunkte, Identität, Datenklasse und Recovery Point stehen nicht in der Quelle. Sie werden zu Einträgen in decisions.json und zu Vorlagen in review/, die Sie ausfüllen und dem nächsten Lauf mitgeben.

4. 04

   4 · Die Landing Zone bauen

   Organisation, Projekt, Rollen und Netzwerk kommen vor jedem Workload. Der Lauf schreibt migration/landing-zone-requirements.md aus dem Entwurf, damit das Plattformteam vor dem ersten Apply weiß, was bereitzustellen ist.

5. 05

   5 · Ziel bauen und Daten übertragen

   Wenden Sie das entworfene STACKIT-Terraform in einem Testprojekt an und übertragen Sie dann die Daten mit einer Methode Ihrer Wahl. Die Engine überträgt nie Daten; sie listet jede zustandsbehaftete Einheit und hält die Wahl offen.

6. 06

   6 · In Wellen umstellen

   Die Einheiten werden nach Abhängigkeit in Wellen geordnet. Cutover-Schritte, Verifikation und Rollback-Bedingungen stehen in execution-plan.json und execution/.

7. 07

   7 · Stilllegen und betreiben

   Legen Sie die Quelle erst nach den Prüfungen still und betreiben Sie dann das Ziel. Der Plan führt die Stilllegung als eigene Schritte, damit sie nicht vergessen wird.

Was die Quellplattformen gemeinsam haben

Kuratierte Zuordnungen je Quell-Cloud; die Klasse ist die typische, und Ihr Lauf entscheidet je Einheit aus der Konfiguration. Identität und Firewalls werden im Einzelfall entschieden.

Was die Klassen für den Aufwand bedeuten

Die Klassifikationen stammen aus der öffentlichen Dokumentation. Die Zahlen sind aus dem veröffentlichten Lauf für AWS Retail Store: 44 Einheiten.

• RECONFIGURE · 34 Einheiten

  Eine entsprechende Funktion existiert und braucht Konfigurationsänderungen: Netzwerke, Security Groups, Secrets, Logs, Load Balancer. Meist Terraform plus Review.

• REPLATFORM · 9 Einheiten

  Der Workload wechselt in ein anderes Plattformmodell: die ECS-Dienste zu SKE, die RDS-Cluster zu PostgreSQL Flex und STACKIT MariaDB, OpenSearch zu STACKIT OpenSearch.

• REDESIGN · 1 Einheit

  Architekturänderung: im Retail-Lauf die DynamoDB-Tabelle, für die der Entwurf eine Alternative auf MongoDB Flex ist, kein Äquivalent.

• CONTAINERIZE und MANUAL_REVIEW

  Containerize bringt eine Funktion oder App in Container. Manual Review markiert eine Frage, die ein Architekt klären muss, bevor der Plan weitergehen kann.

• DIRECT und BLOCKED

  Direct heißt direkte Zuordnung. Blocked heißt, dass der bewertete Weg so nicht abschließbar ist; der Retail-Lauf hatte keine.

Wellen und Landing Zone

Aus dem veröffentlichten Lauf für AWS Retail Store. Links Welle 1 aus migration/technical-sequencing.md, die Einheiten ohne Abhängigkeit. Rechts die Anforderungen an Organisation und Projekt, die der Lauf vor dem ersten Apply auflistet.

## Wave 1 — 9 unit(s)

| Unit | Module | Class | Target |
|---|---|---|---|
| `module.dependencies.module.dynamodb_carts.aws_dynamodb_table.this` | `module.dependencies.module.dynamodb_carts` | REDESIGN / MEDIUM | STACKIT MongoDB Flex (alternative — data-model redesign; PostgreSQL Flex JSONB is the other option) |
| `module.retail_app_ecs.aws_cloudwatch_log_group.ecs_tasks` | `module.retail_app_ecs` | RECONFIGURE / MEDIUM | STACKIT Logs |
| `module.retail_app_ecs.aws_ecs_cluster.cluster` | `module.retail_app_ecs` | REPLATFORM / MEDIUM | STACKIT Kubernetes Engine (SKE) |
| `module.retail_app_ecs.aws_kms_key.cmk` | `module.retail_app_ecs` | RECONFIGURE / MEDIUM | STACKIT KMS |
| `module.retail_app_ecs.module.carts_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.carts_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.retail_app_ecs.module.checkout_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.checkout_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.retail_app_ecs.module.ui_service.aws_iam_role.task_execution_role` | `module.retail_app_ecs.module.ui_service` | RECONFIGURE / MEDIUM | STACKIT service account for the workload |
| `module.vpc.module.vpc.aws_eip.nat` | `module.vpc.module.vpc` | RECONFIGURE / MEDIUM | implicit (belongs to the NAT gateway) |
| `module.vpc.module.vpc.aws_vpc.this` | `module.vpc.module.vpc` | RECONFIGURE / MEDIUM | STACKIT project networking / Network Area (SNA) |

## 1. Organization

- A STACKIT organization that the people who carry out the migration belong to, with a project in it that holds everything the draft creates. The plans state no organization name or id; none is assumed.
- The draft takes the project from the variable `project_id`: STACKIT project ID the migrated resources are created in. It has no default: a person supplies it.

## 2. Project

- The project exists

• Wellen kommen aus Abhängigkeiten

  Eine Einheit zieht nach jeder Einheit um, von der sie abhängt, und Einheiten einer Welle können parallel umziehen. Der Retail-Lauf hat neun Wellen; die Datei nennt sie einen Ausgangspunkt für den Architekten, keinen Terminplan.

• Die Landing Zone wird aus dem Entwurf gelesen

  Die Anforderungen stammen aus den entworfenen Blöcken und den Plänen. Eine mit unknown markierte Zeile ist ein Wert, den der Lauf nicht kennt, keine Lücke im Dokument.

• Variablen ohne Wert sind die Übergabe

  Der Entwurf hat 60 Variablen, und 48 automatisierte Schritte warten auf einen Wert wie project_id. Diese Werte zu liefern, ist die erste echte Aufgabe des Plattformteams.

Was ein Lauf schreibt

index.html

Der Bewertungs-Arbeitsbereich, im Browser geöffnet

assessment.json

Jede Einheit: Klasse, Konfidenz, Ziel, Begründung, Review

decisions.json

Offene Entscheidungen mit Optionen, verantwortlicher Rolle und Phase

terraform/

Der STACKIT-Terraform-Entwurf mit Review-Kommentaren

migration/

Wellen, Landing-Zone-Anforderungen, Datenumzug, der Migrationsplan

execution-plan.json, execution/

Geordnete Schritte für Terraform, APIs und manuelle Arbeit, mit Prüfungen

review/

Vorlagen für Eingaben und Entscheidungen, die Sie füllen

manifest.json

Die Dateien des Laufs und ihre Prüfsummen für stacktoit verify

Was bei Ihrem Team bleibt

• Datenumzug

  StackToIT überträgt nie Daten. Wählen Sie die Methode nach Größe, Änderungsrate und tolerierter Ausfallzeit.

• Freigabe

  Das Paket ist ein Vorschlag. Die Freigabe durch einen Architekten erfassen Sie selbst, und die Engine behauptet nie, ein Entwurf sei sicher anzuwenden.

• Anwendungsverhalten

  Abhängigkeiten zwischen Anwendungen, Cutover-Zeitpunkte und Testkriterien kommen von den Verantwortlichen der Workloads.

• Teile, die ein Redesign brauchen

  NoSQL, Warehouses und manche Plattformdienste haben kein Äquivalent. Der Lauf sagt, welche, und entwirft die nächstliegende Alternative, wo es eine gibt.

Fragen von Enterprise-Teams

Quellen

• STACKIT Cloud Framework: Migration Framework
• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• StackToIT-Dokumentation: Migrations-Workflow
• StackToIT-Dokumentation: Klassifikationen der Bewertung
• Das veröffentlichte Beispiel AWS Retail Store