Exactly, tool vs hammer. Sometimes you made the wrong choice in tool, and then you switch tools.. Nothing wrong with that. A craftman just knows its tools better. There is no magic bullet here.

> Exactly, tool vs hammer. Sometimes you made the wrong choice in tool, and then you switch tools.. Nothing wrong with that. A craftsman just knows its tools better. There is no magic bullet here.

Rational take, but I see the debate similar to Roman vs Arabic numerals.

Keeping a tally? Roman. Need to use operators? Arabic. Sometimes you can keep a tally in Arabic (not ideal), and sometimes you can do basic operations on Roman numerals (not ideal).

However, when you want to start using variables, only one tool enables this easily.

I can't architect the types of redundant and properly separated interoperable systems with a monolith that microservices otherwise enable.

So the desire to move forward isn't the need to find a magic bullet, but the next evolution of an existing ability that unlocks new capabilities...

(I don't think calculus would have been discovered using Roman numerals)

No, but you can start a business with a singlesystem, keep things well decoupled (hard / software engineer is hard).. Then you gradually run some parts of the systems in different docker containers, then at some point you completely decoupled systems and have different teams handle different service boundaries. You could still have the core system be a big bigger, and sometimes referred to as monolith. But monolith vs microservices is a polarises the discussion, its a gradual scale. Its the engineering, and keeping things separated that matters.

I think there are an increasing number of people that believe that microservice is not in the same risk category as a normal application design. A design we really need to stop calling "monolith" as to PMs, management, etc. it sounds ancient.

So the claim that "both strategies have tradeoffs" is not true for a lot of people. Microservies have bigger tradeoffs and consequences than a normal application design.

Of course there is nothing technical to be said. There is plenty of personal anecdote and associated feelings to be shared however, which is what homo sapiens primarily enjoy :)

You get double the thrill if you think you are engaging in a technical conversation all the while arguing anecdotal experiences, beliefs and biases.

What an excellent observation! I will quote this often. Thank you! I’d even generalize it a bit further.

“You get double the thrill if you think you are engaging in logical reasoning, all the while arguing anecdotal experiences, beliefs and biases.”

You're not alone. What doesn't get said enough about this topic is "it doesn't matter". The architecture and design, for the most part, doesn't matter. Because no matter what is chosen, there will be pitfalls. Failing to account for those pitfalls will lead to problems, and changing the design or architecture to avoid the pitfalls will just introduce new pitfalls.

IMHO, the right path is to first become educated about each design and its pitfalls, so that when the time comes, you can quickly pick a design, and move swiftly onto dealing with the pitfalls, because that's where the actual problems lie.

  Among the maxims on Lord Naoshige's wall there was this one: 
       "Matters of great concern should be treated lightly."
  
  Master Ittei commented,
       "Matters of small concern should be treated seriously."