It seems like those who have success with microservice and advocate their use often have a much lower number of service than those critical of microservice architecture.

One customer I work with managed to create 10+ container based services, in order to do a database lookup, render a notification template and send the notification to one of three notification services. Because it’s Java based there’s now also a pretty large menory overhead, as each service needs it’s own memory allocation for the JVM. On the plus side they have became very aware the this is too many micro service and are refactoring and combining a few of the service.

Yeah, that's a recipe for disaster. We've had quite decent success by just splitting along boundaries when something becomes too large or has too many responsibilities.

Having too few large services seems much easier to work with an fix than having too many small ones.

Did you guys split along the equivalent of a bounded context? That would seem to make sense to me in terms of keeping things loosely coupled but still cohesive.

I'd say so. What we did is if you make a description of what a service does like "this service ingests data X and stores it in a database and makes it available as an API and aggregates it into business events and makes predictions based on it" we cut the services on the and's. This example now is 3 services: DB + API, event generator and predictor.

I'm still glad we let it evolve that way instead of starting out separately.