Hvordan migrerer du en monolitt til microservices ved hjelp av strangler-fig-mønsteret?

Question

Accepted Answer

The **strangler-fig pattern** migrerer inkrementelt: du omslutter monolitten med et routing-lag, trekker ut en evne om gangen til en tjeneste, og omdirigerer trafikk til den — inntil monolitten er "kvalt". Det er **ingen big-bang rewrite**.

## Hvordan det fungerer

```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 av hva som skal ekstraheres 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 av delte data

Den vanskelige delen er databasen. Trekk ut tjenestens tabeller, bryt deretter den delte databasekoblingen ved hjelp av hendelser eller et anti-corruption layer, ofte via **branch-by-abstraction** teknikken mens begge kjører.

## Avveininger

```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 er viktig

Big-bang rewrites feiler kjent — de fryser feature work i måneder og leverer en risikabel all-at-once cutover.

The strangler-fig holder systemet live og releasable hele tiden, lar deg stoppe eller ompriorisere på hvilket som helst punkt, og tvinger deg til å oppdage reelle servicegrenser fra det kjørende systemet i stedet for å gjette dem på forhånd.