Services
From a monolith to microservices
A monolith turns sour when every change shares one deploy. We split it where the boundary is already obvious, and we leave the rest in one piece.
Well-structured services are few. We do not draw a box per table. We cut along a part of the product that has its own reason to change and its own data.
When it fits
- Every change, however small, ships with everything else.
- One part of the product has its own release pain or its own data.
- A full rewrite is not an option.
How the work goes
- We name the first cut from the code and from the team: billing, search, identity, or whatever already has its own release pain.
- Shared tables and hidden calls are listed before the split.
- The new service gets its own deploy, its own data, and a contract the monolith calls on purpose.
- The second split waits until the first one is operated without heroics.
Example: take one module out
One boundary
Drag an item onto a row, or select it and use the Move buttons.
Drag billing out of the monolith. One module, not the whole rewrite.
Monolith
Own service
Move
What you receive
- One service boundary written as a contract
- Data that moved with the service, not a shared writable table
- A deploy of that service that does not redeploy the whole product
How to start
Send a short description of the application and the part that is hardest to release. Email it to info@developerlab.nl, or see the contact page for other ways to reach Puya Sarmidani.
Send an email