Milloin sinun EI pitäisi käyttää microservices-arkkitehtuuria?

Question

Accepted Answer

Microservices ovat usein **väärä** aloitusvalinta. Yleinen sääntö on **"monolitti ensin"**: aloita hyvin strukturoidulla monolitilla ja erota palvelut vain, kun sinulla on konkreettinen syy.

## Vältä microservices-arkkitehtuuria, kun

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## Ennenaikaisen jakamisen hinta

In-process-metodikutsujen siirtäminen verkkokutsuiksi lisää viivettä, vikaantumistiloja, sarjallistamista ja käyttöönottoyksikköä. Jos rajat ovat väärät, maksat kaiken sen **ja** joudut silti tekemään refaktorointia palveluiden välillä.

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## Parempi polku

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## Miksi se on tärkeää

Suurin osa tiimeistä, jotka ottavat microservices-arkkitehtuuria käyttöön liian aikaisin, päätyy hitaammaksi, ei nopeammaksi, koska he ottavat jaettujen järjestelmien ylikuormituksen ennen kuin sitä tarvitsevat.

Rajojen säilyttäminen monolitin sisällä ensin antaa sinulle mahdollisuuden oppia alaa halvalla ja jakaa oikean saumojen varrella myöhemmin.