Is Microservices a means of implementing Clean Architecture through technological constraints, just way more expensive?

Question

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...

1. 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
2. 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"
3. 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

Answer 1

I'd say microservices are a technical solution that enables you to employ more people working on the same system.

The microservices provide boundaries between teams to they don't step on each other toes quite so much. So if you are unsatisfied with the speed of one Team of 8 people, you can use microservice architecture to employ 3 teams with 8 people each and get a little more stuff done. (Of course not 3 times the stuff, maybe 50%?)

If you have a single repository folder and 10-20 people implementing features, they will likely encounter many merge conflicts.

You can have clean architecture in a monolith as well as in many microservices. Or bad architecture in either.

Answer 2

In no way does Clean Architecture require that you develop a monolith. It requires that you push unstable things like GUI's and DBs away from stable things like your business rules. It works as well as those assumptions hold. Use it when those are your assumptions. Base your assumptions on the experiences of your shop. Not on some book written by a guy who has never looked at your codebase.

Nothing about that precludes a Microservice. You absolutely can do a Microservice with Clean Architecture. A micro service asks you to keep the scope small. Clean Architecture says nothing against that.

The only conflict is that some of the same issues are solved by either method. Which can make doing both seem like overkill. But either method can be overkill all on it's own. So you get no silver bullet either way. Sorry, but as always, it's a judgement call.

By the way, same argument applies to Domain Driven Development, Test Driven Development, Object Orientation, Functional Programming, and whatever hot tool of the week someone's been talking to the boss about. Focus less on how this stuff is sold, or even typically used, and more on what it could really do for you. No one knows what you're doing better than you.

Answer 3

Is Microservices a means of implementing Clean Architecture through technological constraints, just way more expensive?

No.

Admittedly, there are some similarities between them, but they are not the same thing. Following those similarities, I could argue that car manufacturers using parts that can be swapped out (as opposed to welding the entire car together) is "the same thing" as clean architecture and microservices; since in all 3 cases there is an intention of making sure that one component can be changed/fixed without breaking the overall product.

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

Let's say we added a new feature to our software and released it. However, there's an exception happening during configuration time, e.g. because of a missing config value.

In a monolith, this is likely going to render the entire software suite unusable due to the startup exception. In a microservice architecture, one microservice is now unusable, but all other services are still operational.

The key difference between microservices and monoliths is that monoliths have a shared runtime, and therefore anything that impacts said runtime is going to impact the entire monolith. Since microservices each have their own individual runtime, an issue in one service does not impact other services.

• have a less clean dependency graph inside a (rather smaller) domain, making coding more effective

Regardless of the discussion on microservice/monolith architecture, a less clean dependency graph makes coding more ineffective.

I hear arguments like yours often; and in pretty much every case it is a matter of the developer feeling like the added steps of abstraction are an unjustified obstacle. This is a matter of being short-sighted. The upfront cost of cleaner coding pays back dividends in the future; at least for any application that is expected to endure a long lifetime and sustained maintenance phase (by which I am excluding things like throwaway scripts that you write to use once or twice).

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.

In a company, everything is a cost-benefit analysis. There wouldn't be a single company that would engage in microservices if at the end of the day it did not create a net benefit.

The added cost of deployment infrastructure is real, but you also need to consider how microservices can save you money as well.

• Less need for constant coordination between all devs due to separate service lifecycles, saves on hours (and therefore wages) spent on meetings and cross-communication
• More compartmentalized services lead to better separations of concerns, less spaghettification or tight coupling; all of which lessens the time needed to troubleshoot and fix bugs, thus reducing the manhours put into maintenance of the codebase.
• The previous bullet point also reduces the added cost of integrating future changes/features when the codebase(s) have been left in a more maintainable state, thus reducing the manhours put into future development.
• Scalability is much easier to achieve in a microservice architecture, by which I mean you avoid the additional effort that it generally takes to ensure that a monolith can run in multiple instances. Manhours saved = wages saved.
• New hires can onboard onto smaller individual services instead of needing to learn the entire software ecosystem before they can start contributing. Less time spent onboarding = less hours that they've not been adding value to the company.
• Smaller teams generally run smoother in terms of communication. The % of a team's total manhours spent on communication rises as the team increases in size. Communication is essential, but it can also become a time sink which prevents developers from actually coding and adding value.
• ...

When you sum this all up, and the infrastructure cost of microservices is lower than the money it ends up saving you, then moving to microservices makes sense. If it doesn't, well then it doesn't make sense. This is precisely why it is contextual which architecture you should go with, because every company has their own individual situation and goals.