The Monolith is probably one of the most common ways people structure systems these days. While this is probably a valid way to build a large majority of small systems, for others, it causes quite a bit of pain. I would imagine a large number of people don’t realize that it’s not the only way to build systems.
Your typical n-tier or client/server system is a monolith.
Let’s look at a few characteristics of the Monolith:
- Is hard to integrate. The Monolith prefers to be an island of data. When the technical problems of integration are solved, you still have data ownership issues.
- Is a poor base for a product line. Putting pebbles on top does not result in a system with a Cohesive View.
- Is hard to scale. This usually isn’t an issue until it’s already too late.
- Is easy to grasp mentally. This is a positive aspect of the monolith. Developers are inherently familiar with it.
- Is cheaper and faster to build initially than its non-monolith counterparts
- Large changes must be made at design time by a developer
- Reusing internal assets is tedious and requires much effort
- Will succeed or fail as a single unit
- Can not be used to mitigate against a risky language or runtime platform
- Platform or language migrations must happen all at once. Rewrites are all or nothing.
- Must be versioned and deployed as a whole
- If selling or deploying for multiple user bases, it represents a one-size fits all solution
- May exhibit design-time modularity, but not runtime modularity
- Is either fully available (up) or completely unavailable (down)
In terms of business concerns, we can characterize the monolith as:
- Quicker to market (than it’s non-monolith counterparts)
- Targeting related markets is slow and/or hard as it requires building new monoliths
- Acquiring new monoliths often results in a non-cohesive mess
- Will likely require a full rewrite at a point in its future (even in an Agile team). This means a shorter lifetime. A shorter lifetime means the costs must be recouped over a shorter period of time.
- Tied to a particular customer size. If the monolith targets the large customer base, it will likely be unwieldy and/or too costly for small customers. If targeted at small customers, the reverse is true. One size fits all.
If I had to guess, I would say that monoliths are often built even when they do not provide a good fit for the System, Product, or Business Needs. Building a non-monolith system requires a shift in thinking–a shift that’s not always quite so obvious at first.