You're also making a lot of assumptions. I started working in 2004 and in 2006 I was already doing 'microservices', I was responsible for a few web services (.NET) (with a few endpoints each), other colleagues had others. These web services where part of a bigger system (out of the many that we had). Emphasis here is on few endpoints, the services where split on functionality, some services talked to other services, some directly to the database. One of the reasons for the split was also because we were using Visual Source Safe and multiple people working on the same code was hard. So yes, I think 'Microservices' is a buzzword, it's been driven by the use of containers, deployment automation, and the assumptions that people have done monotliths because they didn't know better is wrong. Every sane engineer who has put too much functionality in a service which at some point caused problems with scaling, agility, etc, would take measures to address it.