Every day appearing new articles promoting microservices and mentioning monolith applications as old fashioned, non-fancy, bad overall, etc.
All these articles silently ignoring one extremely simple, obvious but extremely inconvenient (for those who promotes microservices) fact: monolith is not an architecture.
Monolith is just application packaging option.
Architecture of packaged application can be any, from rusty "Spring Boot+JPA" to reactive clustered nanoservices. Even microservices can be packaged this way easily. Obviously, differences in architecture will result to differences in performance and scalability characteristic of the application. Comparing architecture to packaging option is like comparing sandwiches to lunch boxes.
Top comments (7)
That's a fresh take on the popular architecture comparison problem!
Could you propose a correct way of categorizing backend architectures?
As I come from a whole different world (iOS), that would certainly give me the insights first 20 google search results won't, as monolith vs microservices battle has already dominated the internet :)
Such a categorization requires a lot of thinking. And most likely will require a series of articles. No promises, but I'll try.
I love this, thank you for sharing!
Your post reminds me that a method call within a package, a method call between packages, and a rest call between services are functionally the same thing - it's just increasing the distance between them, and decreasing the reliability
I don't share your opinion. What is your definition of architecture - and what even is architecture for you?
Maybe there is a missunderstanding because there are different ways to view this concept.
Software Architecture
In other words, architecture is more about how information is processed and stored in the system, not how parts of system are packaged. On high level architectural diagrams packaging often even not mentioned as part of the architecture.
Of course, packaging has influence on the architecture, for example, cross-service transactions are big no-no for the microservices. Those limitations and specifics should be taken into account during design. But in general microservices usually is a traditional service-oriented architecture with added headache and limitations.
Just one example from real life: about 6 months ago I worked on the application which consisted of 2 microservices. After some small refactoring it was possible to package application as either monolith or as 2 independent microservices. The architecture of the whole system remained unchanged and internal differences between packaging localized in 2 (two) classes.
Ahh I think I understand you a bit more.
I also think there are different aspects and levels of an architecture.
A whole software has an architecture.
A single service has an architecture.
Packaging is part of an architecture but not the whole architecture itself.
When speaking of a monolith I think the whole software (not a single service) is meant. How the packaging is handled is somehow unrelated to this meaning (but is still part of the architecture). This is my opinion and I don't think that there is one right answer for this.
I still disagree. Packaging relationship to architecture is similar to relationship of technology stack - language/framework/platform/DB/cloud/etc. It has influence on architecture (for example, it might be necessary to add Circuit Breakers at some points), but architecture in general remains unchanged.