> In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state. > This is

> In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state. > This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. This is a moot point. Following up on you OO example, there is not reason you can have separate public and private implementations within a (modularized) monolith. The biggest downsides of (modularized) monoliths lie in 1) scaling - e.g., you can independently scale and load balancer each service, 2) releases - you can have independent releases (at the risk of maintaining version compatibility).