En monolitisk arkitektur pakker all funktionalitet ind i en enkelt deployable enhed; mikroservices opdeler funktionaliteten i mange uafhængigt deployable services. Kerneforskellem er deploymentenheden og grænserne mellem moduler.
En monolitisk arkitektur pakker all funktionalitet ind i en enkelt deployable enhed; mikroservices opdeler funktionaliteten i mange uafhængigt deployable services. Kerneforskellem er deploymentenheden og grænserne mellem moduler.
| Aspect | Monolith | Microservices |
|---|
| Deployment | One unit | Many independent units |
| Database | Usually one shared DB | One DB per service |
| Scaling | Scale the whole app | Scale services individually |
| Communication | In-process calls | Network (HTTP/gRPC/events) |
| Team coupling | High | Low (per-service ownership) |
| Failure blast radius | Whole app | Often isolated to one service |
| Operational complexity | Low | High |
MONOLITH best when:
✓ small team / early-stage product
✓ domain not yet well understood
✓ simplicity and fast iteration matter most
MICROSERVICES best when:
✓ large org with many teams
✓ parts have very different scaling needs
✓ you need independent deploy cadence
En dårligt modulariseret monolith bliver ikke magisk bedre, når den deles op — du får bare en distribueret rod. Ret grænserne først.
At vælge den forkerte stil er dyrt: for tidlig opdelingen tilføjer latens, driftomkostninger og fejlfindingsproblemer for et lille team.
De fleste vellykkede systemer starter som en velstruktureret monolith og udtrækker kun services, når teamstørrelse eller scalingspress klart retfærdiggør det.