Please go on. Can you provide details?

Not the OP but also having worked on multi-million user apps, off the top of my head: zero downtime deployments, small failure domains (if you make a bad update to a service, only related functionality suffers, the rest keeps working), frequent small deployments (like, several times a day), easy and quick integration testing (cause you only have to test the functionality of one service, not the whole system), easier debugging, cause if one functionality isn't working, it's easy to analyze only the logs of the service responsible for that functionality (and optionally move to others later, having identified some part of the cause). Also, every microservice is a new clean slate, you can quickly learn from your mistakes and try out new approaches. (Not diametrically different, but you have the ability to iterate more)

Edit: another one, is that if you keep the microservices actually small and well described by an API, you can easily, quickly and safely heavily refactor/rewrite old services.

This was one of the projects I was on: https://www.accenture.com/us-en/success-performance-manageme...

How big or small are your micro-services ? how many do you have ? How do you draw the boundaries ?

I can only refer you to Eric Evans book (https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...) and other domain driven design material.

Boundaries are by domain, and yes that's not a simple thing to define. Sometimes, domains have varying interfaces, which makes building micro-services more complex, especially when trying to adhere to REST/Swagger standards (something I'm not overly find of).

But keeping things as simple as possible is really the best approach.

All micro-services should be small. When I see someone say "big", then I'm guessing there are a lot of ad-hoc actions...those need to be broken down into their proper domain or relegated to a query service.

I wanted to add that building micro-services requires a bullet-proof security strategy, usually something like OAuth2.

Using authentication, users of an API can have "claims" that will help a micro-service delineate access and provide a way to design for varying interfaces.

This still leaves the Swagger standards in direct opposition to building a set of variant end points since it _requires_ that end points be singular (you can't have a GET api/foo/{id} and a GET api/bar/{id} on the same API without a lot of fudging. This is a distraction from building enterprise-level API's and leans far too much toward single-purpose API's.