IMO, microservices are successful when the issue is scaling people (you can split into loosely coupled teams, one per service), or scaling data (different read / write patterns allow different data stores). I don't consider reuse as a criteria, unless as a project you mean a new feature within the existing app. It's not like Spotify, for example, is starting many new projects but they will benefit from the above.
Yes. A friend is at a company that went from a monolith to a microservices approach. (The service-to-engineer ratio is something like 1:2.) He says it's radically better because somebody after a new feature can mainly just compose existing services. But they had hundreds of employees before they made the switch.
Personally, I would start sooner than that. I think new technologies make service creation easier. But the right moment for me depends a lot on product, team, and tech.
Do serious shops have phases for these things anymore? In my view a modern shop should be developing and releasing frequently, and that engineers should experience operational consequences of development choices.
So I guess I would say that any place not working like that might not be ready for a microservices approach.
Another good use is operational conditions. Like certain parts of the app have different consmption/scalability needs, or certain services doesn't ever change, if at all. We currently have parts of our monolith that change ALL THE TIME, other parts haven't been updated in years. I'd personally like to partition out the stable code.
I think Containers are somewhat pushing Microservices a bit too early for some organizations because of Docker's focus on single entry point (sans supervisor, etc). They are useful for other reasons, but containers solve people problems, containers solve technical deployment problems.
You don't want N kinds of things if you can have 2 kinds of things (say, web tier, job workers for long running stuff, db layer), until you start having problems working out of the same codebases/repos/etc.
Microservices make things harder to debug and most likely there is still coordination that needs to happen, and it's likely going to be less efficient versus developing libraries -- so if you're a small company, you can probably ignore these for a while.
