I disagree, microservices at their core were not a good idea, they were missing the forest from the trees.
Micro services are an attempted solution for having highly bespoke infrastructure that required difficult, long, manual, fragile deployments that were high risk, and thus didn’t happen often and delayed business value. The problem was that they saw that issue and thought it was monolithic applications, not just having bad infrastructure. 99% of the benefits of devops with almost none of the drawbacks are done by having all of the standard dev ops stuff like Cicd, containers, software defined infra, etc and just doing it on the normal monolith.
Eventually you do need to break things up, but the micro services single functionality, single team per service type of micro services goes way to far and harms more than it helps.
Most of my nightmares with microservices comes from where there has been > 1 per team. That came from people who read his "microservices are great!" blog post and just thought that they should build as many as possible. I used to hate him because of that - because it was a logical response to his blog post and people would use it to justify their technical decisions - with argument-from-authority.
In another company I worked at each team maintained ONE microservice and it worked really well.
Because it was a corporate environment with all the usual power politics, control freakery and lack of effective inter-team communication, even though it was more work overall and definitely a technically inferior solution, it did a neat end run around those systemic corporate issues by giving teams relative freedom of development, freedom of deployment and a deliberately simple, loosely coupled, standardized JSON interface to microservices run by other teams whom they didn't talk to much.
So, I get it, but I lost a lot of respect for him over his inability to parameterize his suggestions and the fact that he didn't seem to initially really understand why microservices worked so well for him.