[remmelt]

There are two sides to this.

Technically, one way of solving this is to make sure that the acceptance criteria for any single micro service are clear. For example, you have to expose these REST endpoints; given data set A, respond in this way to these requests, etc. To me, a micro services architecture implies that the development team is responsible for the entire life span of the service, from conception to replacement. This includes maintenance. Insert the devops buzz here as well. When the given solution can no longer be maintained because of failing knowledge (or even interest?) by other devs, it should be replaced. This should be no harder than refactoring a large method, except on the scale of an entire service.

Non-technical benefits include expanded responsibility and shiny architecture can possibly attract better developers/engineers. I know this has worked for us.

I think it would be reasonable to somewhat limit the available choices, especially at the start of a project.