Wait until they realized microservices can be deployed independently and have strict APIs without people using classes they shouldn't or creating spaghetti code because they have 800k LOC.
Honestly, if you can't trust your devs not to make a mess in a monolith, you can't trust them not to make a distributed mess with microservices.
Both architectural patterns have their uses. Neither will save you from bad developers.
I also could be wrong about this, but I like the microservice after projects reach a certain size.
I am a big fan of a well-designed SOA, but that's not properly bloggable here in 2016.
Now, OK, the JVM ecosystem lacks a good module system at the moment. But Java 9 will fix that. There is also OSGi though I don't know much about it.
It's not a panacea, it looks like you're just pushing the complexity into another place.
And no, not panacea, just a way of thinking that I think is useful.
With a single memory space it's easy to simply go around whatever architecture you "should" be following.
Microservices don't solve balls of mud, but they can make it harder to form and easier to spot forming.
Pushing complexity onto interprocess/machine communication will just result in higher levels of spaghetti. Do you really think that same people who would construct a monolith poorly would do a better job building a distributed system instead?
I don't mean to be too dogmatic; there are legit use cases for services. I am just highly skeptical of microservices as a solution for complexity.