Comparison
Distributed monolithvsMonolith
Distributed monolith
you split it into six services and still have to deploy all six together, in the right order.
A set of services with all of the operational costs of being distributed and none of the independence that was supposed to justify them. It is what you get when services are split by technical layer or by shared database rather than by ownership and change. It is the most common outcome of a microservices migration and the reason to insist on the deployment question early, because the diagnosis is easy after a year and expensive.
Full entry →Monolith
everything ships together, so one bad line in someone else's feature blocks your release.
One deployable unit containing the whole application. It is the correct default for most systems and most teams: one place to look, one transaction, no network between your own functions. Its costs are organisational rather than technical and they arrive with headcount — coupled releases, a build everyone waits for, and a codebase where nobody can tell what they are allowed to change.
Full entry →