> The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase [...] Sally can't see the

> The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase [...] Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance... > Specifically, like a microservice allows encapsulation of functionality, it also allows encapsulation of blame I think, the example of Joe's and Sally in parent [1] and your comment, makes the point in micro-services. During various Web Services integrations developers not only may blame specific part of system as faulty but also helps follow rule 'do not test your own code'. I remember few situation in pre-microservices era when during developing new API wrapper developers discovered a flaw in the remote web service (e.g. parameter doesn't change state) non-documented error code or raw Java exception as response. In these cases, owners of the API are are usually notified about issue so we may expect that will be fixed. I agree with you that is hard way to advocate either way is better. It is worth noting that creating a micro services leads to problem which may end with _duplicating_ (creating monolithic) code to provide possibility to communicate between the hosts (imagine mesh network). [1]: https://news.ycombinator.com/item?id=12134648 https://news.ycombinator.com/item?id=12134648