Hvordan migrerer du en monolith til mikroservices ved hjælp af strangler-fig-mønsteret?

Question

Accepted Answer

**Strangler-fig-mønsteret** migrerer trinvist: du omslutter monolitten med et routinglag, udtrækker ét egenskab ad gangen til en tjeneste og omdirigerer trafik til den — indtil monolitten er "kvalt". Der er **ingen big-bang omskrivning**.

## Sådan fungerer det

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## Valg af hvad der skal udtrækkes først

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## Håndtering af delte data

Det svære ved er databasen. Udtrække tjenestens tabeller, og afbryd derefter det delte database-koppling ved hjælp af events eller et anti-corruption-lag, ofte via **branch-by-abstraction**-teknikken mens begge kører.

## Afvejninger

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## Hvorfor det betyder noget

Big-bang omskrivninger fejler berømt — de fastfryser funktionsarbejde i måneder og udsender en risikabel alt-på-en-gang-overgang.

Strangler-fig-mønsteret holder systemet aktivt og frigivet hele tiden, lader dig stoppe eller reprioritere på ethvert punkt og tvinger dig til at opdage rigtige servicelatencygrænser fra det kørende system i stedet for at gætte dem på forhånd.