> If it's not that it's upgrading 100 services worth of dependencies constantly, debugging contract violations and weirdness or performance issues.
Of all the reasons microservices are bad this isn't it. Your first point can be handled mostly automatically with half decent SRE tooling. Lock files on any modern language (including Python via poetry) fix dependency weirdness. Contract violations are a problem with your developers not the style of programming. As for performance I've been on both sides and being able to independently scale microservices via kubernetes is a god send. With proper tooling microservices work great.
The real problem with microservices is what you mentioned before that IMO. Complexity for complexity's sake. Some things are better as monoliths and some things are better as microservices. It's the same problem you see with normalization vs denormalization. Microservices are unambiguously faster in almost all cases. "Do one thing" means that one thing can be optimized to death, in isolation, without fear of interrupting other services. It also means team structures are easier to manage. Microservices don't mean pull in the entire universe of RESTful libraries and use exactly one feature for 1 or 2 endpoints.
But this introduces another problem:
A second managerial problem is that microservices are often used in scrappy startups with < 200 engineers. On any complicated platform this means one engineer might need to know how 10 services work. That's not feasible. You need to split it so a team owns a couple services and "does one thing right" (those services) and nothing else. It's the overapplication of microservices to every problem that is the source of most woes.
Startups will religiously apply microservices. The thought, of course, being that they can hire/fire faster and an outsourced engineer can probably pick up the necessary work quicker. Of course, this never happens, because instead of 10 microservices you have 300 and no one even knows where half of them are. 99% of the time it's not the pattern that is the problem. It's cargo culting. Just like everything else in the industry (looking at you electron, leetcode, functional programming, agile, etc).
It's over applied in almost every professional context. I've watched entire codebases go from reasonably tolerable OOP to FP and the subsequent fallout. Usually, it's because some unhinged programmer starts adding stuff they like to a language it doesn't fit with. Then, you bring new developers on and no one wants to wade through the several layers of map/flatten/reduce/etc. Worse, the bolted-on FP is not optimized well by the compiler leading to worse than usual benchmarks. It's almost always a lose-lose except when it's done with a functional-first language.
It has it's purpose. It's almost universally over-applied owing to the cargo cult and holier-than-thou attitude of a lot of functional programmers. I see it happen in Python where comprehensions are often replaced with maps. While it is nice, the comprehension is more idiomatic and far more widely understood.
Of all the reasons microservices are bad this isn't it. Your first point can be handled mostly automatically with half decent SRE tooling. Lock files on any modern language (including Python via poetry) fix dependency weirdness. Contract violations are a problem with your developers not the style of programming. As for performance I've been on both sides and being able to independently scale microservices via kubernetes is a god send. With proper tooling microservices work great.
The real problem with microservices is what you mentioned before that IMO. Complexity for complexity's sake. Some things are better as monoliths and some things are better as microservices. It's the same problem you see with normalization vs denormalization. Microservices are unambiguously faster in almost all cases. "Do one thing" means that one thing can be optimized to death, in isolation, without fear of interrupting other services. It also means team structures are easier to manage. Microservices don't mean pull in the entire universe of RESTful libraries and use exactly one feature for 1 or 2 endpoints.
But this introduces another problem:
A second managerial problem is that microservices are often used in scrappy startups with < 200 engineers. On any complicated platform this means one engineer might need to know how 10 services work. That's not feasible. You need to split it so a team owns a couple services and "does one thing right" (those services) and nothing else. It's the overapplication of microservices to every problem that is the source of most woes.
Startups will religiously apply microservices. The thought, of course, being that they can hire/fire faster and an outsourced engineer can probably pick up the necessary work quicker. Of course, this never happens, because instead of 10 microservices you have 300 and no one even knows where half of them are. 99% of the time it's not the pattern that is the problem. It's cargo culting. Just like everything else in the industry (looking at you electron, leetcode, functional programming, agile, etc).