Rehost, Replatform, Refactor oder Redesign: je Workload für STACKIT wählen

Die vier Strategien und die Klassen von StackToIT

Rehost, Replatform und Refactor stammen aus den Migrations-Frameworks der Anbieter; AWS führt Refactor zusammen mit Re-architect, und Redesign steht hier für diesen Fall des Umbaus der Architektur. StackToIT vergibt diese Namen nicht: Es schreibt eine Klasse je Einheit, und die folgenden Klassen sind die nächstliegende Lesart.

AWS Prescriptive Guidance definiert Rehost als Umzug ohne Änderung der Anwendung, Replatform als Umzug mit einer gewissen Optimierung und Refactor als die aufwendigste und teuerste Strategie; bei großen Migrationen empfiehlt sie, erst nach dem Umzug zu modernisieren. Den Wechsel virtueller Maschinen in Container zählt AWS zu Replatform; die CONTAINERIZE-Einheit hier liegt näher an Refactor, weil eine Funktion zusätzlich ihr ereignisgesteuertes Ausführungsmodell verliert. Die Zuordnung dieser Namen zu Klassen stammt von uns und ist keine Ausgabe von StackToIT.

Rehost: Aus der virtuellen Maschine wird ein Server

Aus einem Lauf über eine AWS-Umgebung mit 13 Ressourcen, die für diese Seite geschrieben wurde. Links: die Instanz, wie die Quelle sie deklariert. Rechts: der Server-Block, den StackToIT entworfen hat; die Prüfkommentare über dem Block sind hier weggelassen.

resource "aws_instance" "legacy_erp" {
  ami                    = "ami-0abcdef1234567890"
  instance_type          = "m6i.xlarge"
  subnet_id              = aws_subnet.app.id
  vpc_security_group_ids = [aws_security_group.web.id]
}

resource "stackit_server" "legacy_erp" {
  project_id        = var.project_id
  name              = "legacy-erp"
  machine_type      = var.legacy_erp_machine_type
  availability_zone = var.availability_zone
  boot_volume = {
    source_type           = "image"
    source_id             = var.legacy_erp_image_id
    delete_on_termination = true
    size                  = var.legacy_erp_boot_volume_size_gb
  }
  network_interfaces = [stackit_network_interface.legacy_erp.network_interface_id]
  keypair_name       = var.operator_keypair_name
}

• Klasse: RECONFIGURE

  Die Instanz wird auf einen STACKIT-Server abgebildet. Die Einheit behält ihre Form, und Ihre Architekten ergänzen, was die Quelle nicht angeben kann.

• Größe und Image sind Variablen

  Maschinentyp und Image sind Variablen. Die Typ-Variable nennt die Quellgröße – m6i.xlarge mit etwa 4 vCPU und 16 GiB – und verweist auf die STACKIT-Maschinentypen; das AMI muss zu einem öffentlichen Image oder einem importierten raw- oder qcow2-Image werden.

• Die Anwendung bleibt unberührt

  Das ist die günstigste Art Einheit im Plan. Sie wartet dennoch auf die Entscheidung über das Boot-Image, bevor der Server angelegt werden kann.

Redesign: Für eine Key-Value-Tabelle gibt es kein Gegenstück

Aus demselben Lauf. Links: die DynamoDB-Tabelle. Rechts: die MongoDB-Flex-Instanz, die der Entwurf als Alternative anbietet; Kommentare über dem Block sind weggelassen.

resource "aws_dynamodb_table" "sessions" {
  name         = "sessions"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

resource "stackit_mongodbflex_instance" "dynamodb_tables" {
  project_id = var.project_id
  name       = "dynamodb-tables"
  acl        = var.dynamodb_tables_allowed_cidrs
  version    = var.dynamodb_tables_version
  flavor = {
    cpu = var.dynamodb_tables_cpu
    ram = var.dynamodb_tables_ram
  }
  replicas = 3
  storage = {
    class = var.mongodbflex_storage_class
    size  = var.dynamodb_tables_storage_gb
  }
  backup_schedule = "0 2 * * *"
  options = {
    type                       = "Replica"
    point_in_time_window_hours = var.dynamodb_tables_pitr_hours
  }
}

• Klasse: REDESIGN

  Der Lauf hält fest, dass es auf STACKIT keinen DynamoDB-kompatiblen Dienst gibt. Der Entwurf ist eine Alternative, kein Äquivalent: eine Dokumentenspeicher-Instanz für die Tabellen der Umgebung, mit PostgreSQL Flex und JSONB als zweiter Möglichkeit.

• Kapazität lässt sich nicht übersetzen

  CPU und Arbeitsspeicher sind Variablen, die Sie aus der beobachteten Last bemessen, weil DynamoDB-Kapazitätseinheiten kein Gegenstück haben. Schlüsselentwurf, bedingte Schreibzugriffe und Kapazitätsmodi gehen nicht mit.

• Die Arbeit liegt im Code

  Die Prüfpunkte verlangen, die Datenzugriffsschicht gegen die neue API neu zu schreiben. Das ist Anwendungsarbeit, die mit dem Anwendungsteam terminiert wird.

Containerize: Aus der Funktion wird eine dauerhaft laufende App

Aus demselben Lauf. Links: die Lambda-Funktion. Rechts: das Cloud-Foundry-Manifest, das der Entwurf dafür schrieb, so wie die Datei es nach ihrem Kommentarkopf enthält.

resource "aws_lambda_function" "order_worker" {
  function_name = "order-worker"
  role          = aws_iam_role.worker.arn
  runtime       = "python3.12"
  handler       = "app.handler"
  filename      = "worker.zip"
}

---
applications:
- name: "order-worker"
  memory: 128M # the Lambda default memory_size
  instances: 1 # one always-on instance; size from peak concurrency (App AutoScaler for elasticity)
  stack: cflinuxfs4
  buildpacks:
  - python_buildpack_offline
  no-route: true
  health-check-type: process

• Klasse: CONTAINERIZE

  Eine Funktion zieht nicht als Funktion um. Ihr Handler läuft in einem ständig laufenden Prozess; Abrechnung je Aufruf und Skalierung auf null entfallen.

• Was das Manifest nicht trägt

  Die Datei benennt, was sie auslässt: den Handler-Einstiegspunkt, das Zeitlimit je Aufruf, die Ausführungsrolle und das Deployment-Paket. Eine Person ergänzt einen HTTP-Server oder eine Worker-Schleife und entscheidet, wie die Funktion an ihre Zugangsdaten kommt.

• Auslöser werden neu gebaut

  Der Entwurf übernimmt keinen Auslöser. Was die Funktion aufrief, muss die neue App auf anderem Weg versorgen oder aufrufen.

Die zwölf Einheiten des Laufs nach Klasse

Aus 13 Ressourcen wurden 12 Einheiten; die Datenbank-Subnetzgruppe geht in der Datenbank auf. Nach Klasse: 1 DIRECT, 7 RECONFIGURE, 2 REPLATFORM, 1 CONTAINERIZE, 1 REDESIGN, jeweils mit Konfidenz MEDIUM. Für 11 Einheiten entstand ein Entwurf, 1 braucht keine eigene STACKIT-Ressource.

So wählen Sie, Schritt für Schritt

1. 01

   Erst bewerten, dann wählen

   Lassen Sie die Bewertung über die gesamte Umgebung laufen und lesen Sie die Klasse jeder Einheit, bevor Sie einer Anwendung eine Strategie zuweisen. Die Klasse ist ein Befund aus der Quellkonfiguration, keine Vorliebe.

2. 02

   Die günstigste tragfähige Klasse als Standard

   Lassen Sie DIRECT- und RECONFIGURE-Einheiten so umziehen, wie sie sind. Das Cloud Adoption Framework von Microsoft rät, mit einfacheren, risikoärmeren Workloads zu beginnen, um Sicherheit zu gewinnen und den Ablauf zu schärfen.

3. 03

   REDESIGN-Einheiten trennen

   Behandeln Sie jede REDESIGN-Einheit als kleines Softwareprojekt mit eigenem Verantwortlichen und Termin. Lassen Sie sie die Infrastruktur-Wellen nicht aufhalten; eine unfertige Datenschicht hält genau diese Einheit vom Cutover ab.

4. 04

   Replatform dort, wo Daten wandern

   REPLATFORM-Einheiten bringen einen Datenumzug mit sich. Der Lauf schreibt je Datenbank ein Runbook für den Datenumzug und lässt die Methode offen, weil Datenmenge und tolerierte Ausfallzeit nicht in der Quelle stehen.

5. 05

   Antworten, neu laufen lassen, vergleichen

   Tragen Sie Konfigurationsantworten in eine Inputs-Datei und die Prüfergebnisse Ihrer Architekten in eine Decisions-Datei ein, beide kopiert aus den Vorlagen, die der Lauf schreibt, und starten Sie den Lauf erneut. Inputs können den Entwurf ändern; ein erfasstes Prüfergebnis allein nicht. Lesen Sie daher nach jedem erneuten Lauf den neuen Entwurf und den Ausführungsplan.

Entscheidungen Ihrer Architekten

• Welcher Ersatz für einen fehlenden Dienst

  MongoDB Flex oder PostgreSQL Flex mit JSONB für die Tabelle. Der Lauf bietet eines an und nennt das andere; die Wahl folgt den Zugriffsmustern der Anwendung.

• Laufzeit der Funktion

  Eine Cloud-Foundry-App oder ein Container auf SKE oder Container Applications. Der Entwurf schreibt nur die Cloud-Foundry-Variante; für einen Container bauen Sie das Image selbst.

• Methode des Datenbankumzugs

  Ein Dump, der im Schreibstopp eingespielt wird, oder logische Replikation. Der Lauf definiert beide und wählt keine.

• Wann modernisiert wird

  Ob eine RECONFIGURE- oder REPLATFORM-Einheit beim Umzug oder danach modernisiert wird. Bei großen Umzügen empfiehlt AWS Prescriptive Guidance, danach zu modernisieren.

Fragen von Architekten

Quellen

• AWS Prescriptive Guidance: Über die Migrationsstrategien
• Microsoft Cloud Adoption Framework: Migration planen