> Microservices gets owned by different teams, teams get cemented, politics get in the way of refactoring. Game over.

I don't understand how microservices make this worse in any way. Modules get owned by different teams all the time.

> You may have experiences that that microservices are as easy to refactor as monoliths; in my experience it is orders of magnitude harder...

Yes, I have said before that I believe merging is fundamentally simpler than splitting. If we're just talking about merging a module vs a service, I don't believe either is harder than the other - I mean... nothing about microservices prevents you from using modules, and indeed I would highly recommend it.

> I think there is a bit of a "No true scotsman" fallacy at play here. You see something you do not like then it is "not microservices done properly".

For sure, and that's a failing of microservices. People think microservices means "SOA", or "write a lot of services". If you want to criticize SOA or whatever, sure, the argument of "don't do that" goes away.

> How about state all the things you don't like about monoliths , then I say "that is not monoliths done properly", "don't do that" for each one?

I probably could state a bunch of things that are pretty fundamental, but I don't think it's important - I don't know that I've actually said anywhere that microservices are better than monoliths, what I've instead said are the benefits of microservices that I see, which others have taken to mean that I somehow think monoliths or modules are bad.

> You may say the architecture is then "better"

I honestly don't think I've said that anywhere, or even made a judgment anywhere.

I think I can summarize, again, what I've said.

1. Network boundaries provide a physical layer that enforces isolation of state and the use of message passing

2. Isolation of state makes scaling a system easier

3. Isolation of capabilities makes securing a system easier

4. SOA inherently leverages the network boundary

5. Microservice Architecture is similar to SOA but with a bunch of patterns, guidance, and concepts that you leverage in your design

What I've received in response is a hodgepodge of:

1. "Modules can isolate state" - only true in some languages, and even then there's no physical barrier enforcing it, you're relying on developers to maintain that isolation.

2. "But what if you do anti-patterns that microservices tell you not to" - ok, that's why microservice architecture has books and documentation about what not to do. If you do those things, I'm not going to blame you, it's a failing of all methodologies when users have a hard time understanding them.

But so far the anti-patterns mentioned aren't really compelling or specific to microservices. You wrote code to satisfy a domain, the domain changed, now you need to change that code so that it satisfies the new domain. That happens all the time, merging services isn't any harder than merging modules.

3. General misunderstandings about state, security, etc.

> What I was getting at is that when you go distributed,

I'm not really convinced that "distributed" is the right word here. People talk about distributed systems being complex, and I think they're confused - what's complex is consensus, but splitting one service from another service shouldn't impact consensus, and the fact that they're now located on two different assets does not necessarily make things more complex.

Those services may be more complex, if your application was quite trivial - a totally stateless system with no external connections, for example. I see no reason to rewrite 'grep' as a microservice, and I would never recommend that.

Those services may now be more error-prone because you have things like dns, tcp, etc involved. If you don't want to make that tradeoff, that's OK, you could be right in that case. Again, no need to make all software be microservices.

(Going to respond to your other message here)

> PS I think microservices excel in making people FEEL productive (doing work that is not directly benefiting the company).

Maybe, I don't really know. It isn't my experience, but that's just me. Most developers seem to be pretty bad at their jobs so I imagine that all sorts of issues can be experienced. Certainly the idea of rewriting a monolith as a microservice seems like a red flag unless there were very specific needs.