Cloudmigratie naar STACKIT: de complete gids voor enterprises

De zeven fasen

Het STACKIT Migration Framework beschrijft vier fasen: assess, design and mobilize, migrate en run. De zeven fasen hieronder verdelen hetzelfde traject in onderdelen waarvoor u een team kunt inplannen, en koppelen elke fase aan wat een StackToIT-run schrijft.

1. 01

   1 · De omgeving inlezen

   Een standaardassessment leest Terraform of OpenTofu, of een VMware RVTools-export, op uw eigen machine. Uitvoer: assessment.json met elke eenheid, plus aantallen resources, modules en voorwaardelijke eenheden. Hoe u dat leest, staat in de gids over de inventarisatie.

2. 02

   2 · Elke resource classificeren

   Elke eenheid krijgt een klasse, een zekerheidsniveau, een STACKIT-doel en een reden. De klasse zegt hoeveel werk het is; de reden zegt waarom. Zie de klassen hieronder.

3. 03

   3 · Beslissen wat code niet kan bepalen

   Afmetingen, endpoints, identiteit, dataklasse en herstelpunt staan niet in de bron. Ze worden records in decisions.json en templates in review/ die u invult en aan de volgende run meegeeft.

4. 04

   4 · De landing zone bouwen

   Organisatie, project, rollen en netwerk komen vóór elke workload. De run schrijft migration/landing-zone-requirements.md op basis van het concept, zodat het platformteam weet wat het moet leveren vóór de eerste apply.

5. 05

   5 · De doelomgeving bouwen en data verplaatsen

   Pas het opgestelde Terraform voor STACKIT toe in een testproject en verplaats daarna de data met een methode naar keuze. De engine verplaatst nooit data: hij somt elke stateful eenheid op en laat de keuze open.

6. 06

   6 · In golven overschakelen

   Eenheden worden op afhankelijkheid in golven geordend. De cutoverstappen, de verificatie en de rollbackvoorwaarden staan in execution-plan.json en execution/.

7. 07

   7 · Uitfaseren en beheren

   Faseer de bron pas uit na de controles en beheer daarna de doelomgeving. Het plan bevat de uitfasering als aparte stappen, zodat die niet wordt vergeten.

Wat de bronplatforms gemeen hebben

Zorgvuldig samengestelde koppelingen per bronplatform; de klasse is de gebruikelijke en uw run bepaalt de klasse per eenheid op basis van de configuratie. Identiteit en firewalls worden per geval bepaald.

Wat de klassen betekenen voor de inspanning

De classificaties komen uit de openbare documentatie. De cijfers komen uit de gepubliceerde AWS Retail Store-run: 44 eenheden.

• RECONFIGURE · 34 eenheden

  Er bestaat een vergelijkbare mogelijkheid waarvoor configuratiewijzigingen nodig zijn: netwerken, security groups, secrets, logs, load balancers. Vooral Terraform-werk plus beoordeling.

• REPLATFORM · 9 eenheden

  De workload verhuist naar een ander platformmodel: de ECS-services naar SKE, de RDS-clusters naar PostgreSQL Flex en STACKIT MariaDB, OpenSearch naar STACKIT OpenSearch.

• REDESIGN · 1 eenheid

  Architectuurwijziging. In de Retail-run is dit de DynamoDB-tabel: het concept stelt MongoDB Flex voor als alternatief, niet als gelijkwaardige vervanger.

• CONTAINERIZE en MANUAL_REVIEW

  Containerize brengt een functie of app onder in containers. Manual review markeert een vraag die een architect moet beantwoorden voordat het plan verder kan.

• DIRECT en BLOCKED

  Direct betekent een rechtstreekse koppeling. Blocked betekent dat het beoordeelde pad niet kan worden afgerond zoals voorgesteld; de Retail-run had er geen.

Golven en de landing zone

Uit de gepubliceerde AWS Retail Store-run. Links: golf 1 van migration/technical-sequencing.md, de eenheden die van niets anders afhangen. Rechts: de eisen voor organisatie en project die de run vermeldt vóór de eerste apply.

## 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

• Golven volgen uit afhankelijkheden

  Een eenheid gaat pas over nadat alle eenheden waarvan zij afhangt zijn overgegaan, en eenheden in dezelfde golf kunnen parallel overgaan. De Retail-run telt negen golven; het bestand noemt ze een vertrekpunt voor de architect, geen planning.

• De landing zone wordt afgeleid uit het concept

  De eisen worden afgeleid uit de opgestelde blokken en de plannen. Een regel met de markering unknown is een waarde die de run niet kent, geen gat in het document.

• Variabelen zonder waarde vormen de overdracht

  Het concept bevat 60 variabelen en 48 geautomatiseerde stappen wachten op een waarde zoals project_id. Die waarden aanleveren is de eerste echte taak van het platformteam.

Wat een run schrijft

index.html

De assessmentomgeving, geopend in een browser

assessment.json

Elke eenheid: klasse, zekerheidsniveau, doel, reden, review

decisions.json

Openstaande beslissingen met opties, rol van de eigenaar en fase

terraform/

Het STACKIT-Terraform-concept met reviewopmerkingen

migration/

Golven, eisen voor de landing zone, dataverplaatsing, het migratieplan

execution-plan.json, execution/

Geordende stappen voor Terraform, API's en handmatig werk, met controles

review/

Templates voor invoer en beslissingen die u invult

manifest.json

De bestanden van de run en hun checksums voor stacktoit verify

Wat bij uw team ligt

• Dataverplaatsing

  StackToIT verplaatst nooit data. Kies de methode op basis van omvang, wijzigingssnelheid en toegestane downtime.

• Goedkeuring

  Het pakket is een voorstel. De goedkeuring door de architect legt u zelf vast; de engine stelt nooit vast dat een concept veilig kan worden toegepast.

• Applicatiegedrag

  Afhankelijkheden tussen applicaties, het moment van cutover en de testcriteria komen van de eigenaren van de workloads.

• Onderdelen die een redesign vergen

  NoSQL, warehouses en sommige platformservices hebben geen gelijkwaardige tegenhanger. De run geeft aan welke en stelt waar mogelijk het dichtstbijzijnde alternatief op.

Vragen van enterpriseteams

Bronnen

• STACKIT Cloud Framework: Migration Framework
• STACKIT Kubernetes Engine (SKE)
• StackToIT-documentatie: migratieworkflow
• StackToIT-documentatie: classificaties van het assessment
• Het gepubliceerde AWS Retail Store-voorbeeld