On the occasion of a series of lectures, which we are now holding for the third year at the University of Applied Sciences Offenburg, we have explained the problems of monolithic architectures in context with the ATAM method using a real example. I would like to post an article about ATAM - a method for the qualitative analysis of software - again later.
Here are two quotes in advance that I don't want to comment on any further.
«Don't start with a monolith when your goal is a microservices architecture» - Stefan Tilkov
«If you can't build a monolith, what makes you think microservices are the answer?» - Simon Brown
In any case, the analysis of a software system has found a problem that significantly hinders the maintainability of the software. This is also called a «historically grown monolith» . And mind you, these monoliths are still more widespread in the wilderness than clean micro services architectures.
The decomposition or modularization can be done in layers (structure a software horizontally technical) and in modules (structure a software vertically mostly business oriented).
It is important to ensure that the newly created components are not code monoliths, test monoliths, or deployment monoliths. The latter, i.e. independent deployment of components, is the highest level of modularization. The architectural styles Micro Services or Modular Monoliths / Moduliths have this property.
Now I am often asked by customers what the «optimal granularity» of a software should be. This is where the standard answer of the software architect comes in: «It depends!?»
I would like to refer here to the «Monolith first Approach» by Martin Fowler. Only when you experience what the software should be able to do, you will be able to modularize it optimally. A monolith is actually a good starting point. Admittedly, this only works for relatively static requirements. This is not the rule in many areas today.
A complete refactoring of existing monoliths is usually not possible either. Mostly the sponsor or the resources are missing. The size and thus the complexity of the software is certainly a criterion how deep the decomposition should go.
For smaller systems, a monolith or very few modules may be better than Micro Services. Even a breakdown of large systems into hundreds of micro services is not recommended. You replace the complexity of the monolith by the complexity of the integrating services.
As is so often the case, the right measure is in the middle. Architecture decisions are specific and also not encraved in stone.
Offenburg University Informatics
Martin Fowler: The Monolith first approach
