>Microservices allow and require low coupling in the organization. If you want to reduce coupling in your org, you'll be well served by microservices. If you want tight collaboration in your org, you'll be well served by a monolith. As orgs grow into multiple independently executing units, a monolith starts to limit the ability to independently execute.

Most individual computers combine seamlessly interoperating software that was, ultimately, written by tens if not hundreds of thousands of people, most of whom do not know one another - all the way from the kernel to the highest level scripting languages.

I think you're right microservices are primarily about Conway's law. I just don't think it's about operational effectiveness (it actually makes operational effectiveness harder, IMO).

I think it's primarily successful in large orgs because it minimizes finger pointing by establishing tighter loci of responsibility.

My rule of thumb is "could this service be spun off as a separate business?". E.g. postcode->address service, sure, microservice that. Image manipulation service->maybe yes, maybe no, "user" service-> no, price calculation service->no