I spend a lot of time lately talking about Microservices architecture and I have a really hard time buying all the benefits that are sold to me. For most arguments I hear I come to the conclusion that Clean Architecture can do just the same, especially when combined with strict implementation of architectural fitness functions.
My conclusion so far is that microservices is most suited for large companies having a number of teams so high that there's the need to physically (not logically!) separate the product along well-defined domain boundaries. Teams therefore become better experts of their respective teams with improved ownership and commnication structure (if well executed). In contrast, one team being responsible for 10 different microserives sounds counter-intuitive to me from this perspective. But that might be pretty common thing for a lot of (smaller) companies.
I hear that...
- it's pretty hard to migrate to microservices if you don't do it right from the beginning, so better start with many miniscule services than migrating later, or
- we have performance problems at the database end so we need to migrate the whole domain including data and logic to a dedicated service where we do it "the clean way"
- microservices make good architecture less of an issue, because inside it nobody cares if there is tight coupling, less abstraction, etc. because the domain is smaller and then overall easier to understand
...amongst several others. But in my opinion these issues are then more moved towards the coordination between the services. Interface definitions become more complicated, as there's always one for the consumer and one for the producer. Logging, debugging, deployment, load balancing, network traffic, serialization/deserialization add considerable operational overheads (bother personal, computational and memory-wise). That costs a lot of money.
So to conclude, the above assumptions to the benefit of microservices architecture are only true if you haven't applied Clean Architecture (and fitness functions) in the first place. Because if you have, there's it's not really a big deal to for example...
- swap the database or moving the code to a dedicated service
- have a less clean dependency graph inside a (rather smaller) domain, making coding more effective
amongst others (please help me complete this list).
The essential question for me is: What are the real important defining factors for having a microservices architecture in favor of a monolith* with Clean Architecture + fitness functions to enforce it?
* e.g. in a stateless monolith running in parallel for scalability reasons