There in lies the rub, the majority of engineers don't work at companies that need the kind of scale that Facebook has.
The majority of us work at smaller shops that can get by fine without all the overhead that microservices introduce. The problem that I see is that there are to many folks not weighing the pros and cons of the architectural decisions they are making, and are just joining the cargo cult.
The same people are now saying creating microservices is a sign of incompetence and the smart thing to do is create monoliths.
But not to sound ridiculous, they bring a spin to it: they now say they create modules within the monolith.
Software engineering is like fashion. It goes full circle every X years.
If that were true, then moving to a microservice architecture they'd need 5 million instances of the microservice that replaces the part of the monolith that required 5 million instances in the first place, plus a couple of millies for all the other services.
On a small-medium vertical team at a large company? Probably-maybe not.
Many, many engineers (and managers maybe even more so) immediately jump to micro-services (often resume-driven development) where most companies have poor tooling and poor security knowledge that turn them into a living productivity-crippling nightmare to work with.
a lot of people are giving Martin flack that the idea sucks when the reality is they're implementing it poorly or inappropriately.
I generally hate the term “micro services”. They are just “services” and nothing new.