Monoliths are not a bad architecture style. In fact, a monolith can be a great one.
Some people treat monolithic systems as relics: poor, outdated, non-modern solutions. But before microservices existed, we simply called these systems layered or n-tier applications, often built with MVC or MVVM design patterns inside.
How we got here
Microservices went mainstream with the help of companies like Netflix and Amazon, and now everyone wants to solve their problems with them. In reality, a well-defined modular monolith may be the better choice in terms of:
- Performance – no network hops between components.
- Speed of development – one codebase, one build, one place to debug.
- Simple deployments – one artifact to ship.
- No distributed-system pain – no eventual consistency, distributed tracing or partial failures to deal with.
Chances are you are not facing the same problems that led Netflix to move to microservices.
Think before you default
What I am trying to say is that it's important to think about the trade-offs before defaulting to microservices. Lately I have been reading a lot about software architecture and the trade-offs of different styles. I am a big fan of Mark Richards' work at Developer to Architect, and one lesson I learned directly from him is that architecture is not something you Google; it depends on the system you are building.
What's your take? Have you seen a modular monolith outperform a microservices design in your projects?
Originally shared on LinkedIn.
Comments