Comparison
MicroservicevsModular monolith
Microservice
the service you own deploys on its own schedule and you have never waited for another team's release.
A service small enough to be owned, deployed and reasoned about by one team independently of the others. The unit of value is independent deployment, not size — a service that cannot be released without coordinating is not buying you anything. The price is real and permanent: every in-process call you replaced is now a network call that can be slow, partial or absent, and every debugging session now spans machines.
Full entry →Modular monolith
you kept the single deployable and made a module boundary something the build fails on when crossed.
A monolith with internal boundaries that are actually enforced — by module systems, build rules or tests — rather than merely intended. It gets you the ownership and reasoning benefits of separate services without the network, the deployment matrix or the distributed debugging. It is the usual right answer when someone proposes microservices for a fifteen-person company, because it makes the same boundary argument at a fraction of the operational cost.
Full entry →