If I had to mark some points that I absolutely agree are 3, 5 and 11. I’d note that most teams I worked with acknowledge the importance of automated testing (and how essential they are in a microservice environment) but most succumb to pressure from management to deliver features first and engineer later. This is probably the greatest guaranteed disaster when teams don’t have the power or will to push back.

That said … IMHO:

Reason 1: should have no bearing whatsoever. What’s management have to do with using microservices? It’s an engineering (architecture) decision, at most it’s about ensuring that management understands it in the context of project costs (we’ll need stuff like hardware / cloud access / time to develop tests / monitoring / logging /etc) and say yes or no after discussing benefits. The issue rests ONLY with engineers and supporting their case based on experience AND metrics / tests. If this is seen as an issue, I’d argue the team has some serious approach issues that have little to do with microservices.

Reason 2: that affects any architecture.

Reason 4: again, that affect any architecture. It’s related to the number of codebases that comprise the ecosystem, microservices or not. Sure, it’s a greater chance of it happening in a microservice architecture, the more microservices you have but that’s about it.

Reason 7: here I disagree completely with your reasoning. With microservices you can and should build a polyglot environment. But yeah, any language has strengths and weaknesses and what grinds me about your reasoning is that apparently neither you nor the team started off from the issue: we have services in a language that ends up using too many resources. If we were to rewrite that in node, do the shortcomings of node bear such an impact on the real uses cases of this service that make the benefits not worth it? Neither choice is perfect, but the benefit of microservices in this case is the reduced scope of that service: whatever tradeoffs you make now, their impact on the product as a whole will be limited, controllable and revertable (this should be a word). It’s easy to conceive a test playing the strength or the weakness of language to support your preordained conclusion but if you have anything like a relevant performance test that already outlines the problem of the application, just use that (or a subset of it) to see how a different take would behave.

Reason 8: people dependency again affects all types of projects, and I’d say it’s more pregnant in monolithic style projects, which are designed once but things get off the rails quick. It’s human nature I guess and you can see it in everything: once the great designer (aka architect) goes away, it will go off the rails, period.

Reason 9: that affects microservice architectures very little. lack of proper naming is more of an issue because given a properly named set of services with an organized hierarchy of repositories and they are indeed ‘micro’, then understanding them shouldn’t be an issue. Yes, C4 is great for an overview but try steps 4 or even 3 in a C4 set of diagrams where you have ~100 microservices and see where that takes you. At best you’d have 3a….z and for each a subset of 4’s. At worst, you’d try to follow it to the letter and end up with a diagram 4 that will puzzle the generations to come.