The Monolith

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.

Language Roots