Rehost, replatform, refactor of redesign: per workload kiezen voor STACKIT

De vier strategieën naast de klassen die StackToIT schrijft

Rehost, replatform en refactor komen uit de migratieframeworks van de leveranciers; AWS rekent refactor samen met re-architect, en redesign wordt hier gebruikt voor dat geval van herontwerp van de architectuur. StackToIT geeft eenheden niet deze namen: het schrijft per eenheid een klasse, en de klassen hieronder komen er het dichtst bij.

AWS Prescriptive Guidance definieert rehost als een verhuizing zonder wijzigingen aan de applicatie, replatform als een verhuizing met enige optimalisatie en refactor als de meest complexe en kostbare strategie; bij grote migraties adviseert het om pas na de verhuizing te moderniseren. AWS rekent het onderbrengen van virtuele machines in containers tot replatform; de CONTAINERIZE-eenheid hier staat dichter bij refactor, omdat een functie ook het gebeurtenisgestuurde uitvoeringsmodel verliest. De koppeling van die namen aan klassen is van ons en geen uitvoer van StackToIT.

Rehost: een virtuele machine wordt een server

Uit een run van een AWS-omgeving van 13 resources, geschreven voor deze pagina. Links: de instance zoals de bron die declareert. Rechts: het serverblok dat StackToIT opstelde; de reviewopmerkingen erboven in het bestand zijn hier weggelaten.

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

  De instance wordt gekoppeld aan een STACKIT-server. De eenheid blijft in vorm gelijk en de architect vult in wat de bron niet kan vermelden.

• Afmeting en image zijn variabelen

  Het machinetype en het image zijn variabelen. De typevariabele noemt de bronafmeting, m6i.xlarge met circa 4 vCPU en 16 GiB, en verwijst naar de STACKIT-machinetypen; de AMI moet een publiek image of een geïmporteerd raw- of qcow2-image worden.

• In de applicatie verandert niets

  Dit is de goedkoopste soort eenheid in het plan. Hij wacht nog wel op een beslissing over het bootimage voordat de server kan worden aangemaakt.

Redesign: een key-value-tabel heeft geen tegenhanger

Uit dezelfde run. Links: de DynamoDB-tabel. Rechts: de MongoDB Flex-instance die het concept als alternatief biedt; opmerkingen boven het blok zijn weggelaten.

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

  De run meldt dat er op STACKIT geen DynamoDB-compatibele dienst bestaat. Het concept is een alternatief, geen gelijkwaardige vervanger: één documentstore-instance voor de tabellen van de omgeving, waarbij PostgreSQL Flex met JSONB als andere optie wordt genoemd.

• Capaciteit laat zich niet vertalen

  CPU en geheugen zijn variabelen die u afstemt op de waargenomen belasting, omdat DynamoDB-capaciteitseenheden geen tegenhanger hebben. Sleutelontwerp, voorwaardelijke schrijfacties en capaciteitsmodi worden niet overgenomen.

• Het werk zit in de code

  De reviewpunten vereisen dat de datatoegangslaag wordt herschreven voor de nieuwe API. Dat is applicatiewerk, dat u met het applicatieteam inplant.

Containerize: een functie wordt een permanent draaiende app

Uit dezelfde run. Links: de Lambda-functie. Rechts: het Cloud Foundry-manifest dat het concept ervoor schreef, zoals het bestand het bevat na de commentaarkop.

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

  Een functie gaat niet als functie over. De handler draait in een proces dat blijft draaien, dus facturering per aanroep en schalen naar nul vervallen.

• Wat het manifest niet bevat

  Het bestand noemt zelf wat het weglaat: het entrypoint van de handler, de time-out per aanroep, de uitvoeringsrol en het deploymentpakket. Iemand van uw team voegt een HTTP-server of workerlus toe en bepaalt hoe de functie aan inloggegevens komt.

• Triggers worden opnieuw opgebouwd

  Het concept bevat geen trigger. Wat de functie aanriep, moet de nieuwe app op een andere manier voeden of aanroepen.

De twaalf eenheden van de run, per klasse

13 resources werden 12 eenheden; de databasesubnetgroep is in de database opgenomen. Per klasse: 1 DIRECT, 7 RECONFIGURE, 2 REPLATFORM, 1 CONTAINERIZE, 1 REDESIGN, alle met zekerheidsniveau MEDIUM. 11 eenheden kregen een concept en 1 heeft geen eigen STACKIT-resource nodig.

Zo kiest u, stap voor stap

1. 01

   Eerst beoordelen, dan kiezen

   Voer het assessment uit op de hele omgeving en lees de klasse van elke eenheid voordat u een applicatie een strategie toewijst. De klasse is bewijs uit de bronconfiguratie, geen voorkeur.

2. 02

   Kies standaard de goedkoopste klasse die volstaat

   Laat DIRECT- en RECONFIGURE-eenheden ongewijzigd overgaan. Het Microsoft Cloud Adoption Framework adviseert te beginnen met eenvoudigere workloads met een lager risico, om vertrouwen op te bouwen en het proces te verfijnen.

3. 03

   Scheid de REDESIGN-eenheden af

   Behandel elke REDESIGN-eenheid als een klein softwareproject met een eigen eigenaar en datum. Laat die de infrastructuurgolven niet ophouden; een onafgemaakte datalaag is wat de cutover van die eenheid tegenhoudt.

4. 04

   Replatform waar data wordt verplaatst

   REPLATFORM-eenheden brengen dataverplaatsing mee. De run schrijft per database een runbook voor de dataverplaatsing en laat de methode open, omdat de omvang van de data en de toegestane downtime niet in de bron staan.

5. 05

   Beantwoorden, opnieuw draaien, vergelijken

   Zet configuratieantwoorden in een invoerbestand en reviews van de architect in een beslissingsbestand, beide gekopieerd uit de templates die de run schrijft, en draai opnieuw. Invoer kan het concept wijzigen; een vastgelegde review alleen niet, dus lees na elke nieuwe run het nieuwe concept en het nieuwe uitvoeringsplan.

Beslissingen die de architect neemt

• Welke vervanger voor een ontbrekende dienst

  MongoDB Flex of PostgreSQL Flex met JSONB voor de tabel. De run biedt er één aan en noemt de ander; de keuze volgt de toegangspatronen van de applicatie.

• Runtime voor de functie

  Een Cloud Foundry-app, of een container op SKE of Container Applications. Het concept schrijft alleen de Cloud Foundry-optie; voor een container is het bouwen van het image uw werk.

• Methode voor de databaseverplaatsing

  Een dump die binnen een schrijfstop wordt teruggezet, of logische replicatie. De run definieert beide en kiest geen van beide.

• Wanneer moderniseren

  Of een RECONFIGURE- of REPLATFORM-eenheid tijdens de verhuizing wordt gemoderniseerd of erna. Bij grote verhuizingen adviseert AWS Prescriptive Guidance erna.

Vragen van architecten

Bronnen

• Over de migratiestrategieën, AWS Prescriptive Guidance
• Plan your migration, Microsoft Cloud Adoption Framework