Member-only story
On Complexity and Monoliths
Putting microservices (and other architectures) in a realistic light without resurrecting what should stay dead.
Horror writer H.P. Lovecraft, in his short story The Nameless City, famously attributed this quote to a mad (fictional) poet:
That is not dead which can eternal lie / And with strange aeons even death may die.
And—yes indeed—here and now I will let the above refer to monoliths (and other phenomena) and not fictive gods sleeping in the ocean, waiting to consume humanity.
This article is reflective and highly opinionated in nature. If you want a more technical, objective approach to concrete solutions and discussions on this matter, then see for example these great books:
- Fundamentals of Software Architecture: An Engineering Approach
- Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures
- Building Microservices: Designing Fine-Grained Systems
Definition: Oh, and microservices don’t have to equate Kubernetes. For me, at least, that’s an entirely different point. I’ll instead think of function-as-a-service (FaaS) as a purer realization of microservices, even though the term “microservices” should be kept as generalized as possible in this article.
Final trigger warning: I won’t argue about monoliths for cases where they are rationally relevant, such as very limited/small scopes, prototypes, possible security reasons, and such. While monoliths can definitely be a valid architecture style, the proper analysis of the problem the software should solve, quality attributes, and understanding of the domain in which the software interacts cannot be skipped.
Reality check:
There is nothing inevitable about progress.
A lot of bad ideas have a tendency to come back after they’ve been hidden away long enough.
One of these ideas is the monolith. As with all ideas, even they make sense through a certain lens. And do hear me out! There are completely rational, valid, good reasons to use…
