The False Dichotomy of Monoliths and Microservices

When learning about microservices, you're nearly always introduced to the concept of a monolith. If you're not doing microservices, you're building a monolith. If you're not building a monolith, you must go with microservices. If you're building a monolith, perhaps you're doing it well and it's a majestic monolith.

From my early encounters with microservices, this dichotomy bothered me. The discussion of a monolith was nearly always focused on its purported problems. Difficult to develop. Difficult to deploy. Difficult to scale.

Which I always found odd, I've built applications that weren't microservices that had none of these properties, so what was different?

Redefining Microservices and Monoliths

The problem is that this is presented as a dichotomy. But it is a false dichotomy. It isn't an either/or choice. And we can get away from this false dichotomy by refining our definition of microservice (which, as even Wikipedia shows, doesn't have consensus about what the term means).

From my microservices FAQ:

A microservice is a service with a design focus towards the smallest autonomous boundary.

And a monolith:

A monolith is software whose design, information model, and interface combine multiple competing and interfering domains into one single application and data model. There is no longer consensus from users and designers of the software on terms, modeling, information design, or interface. The coupling between competing models makes future changes to the system difficult or impossible.

We can still build services that don't strive for the smallest autonomous boundary. And we can build monoliths out of distributed components. And our microservices can also be individual monoliths, if they can't meet the defined operational, business, and delivery objectives.

It's also why I see the question of "do I start with microservices or monoliths" to only have one answer: Mu. No one strives for a monolith, but they may not have a good enough understanding of the business to understand where the service boundaries should be. You're asking the wrong question, you need to unask the question and start over.