Agreed with all of this. Composition over inheritance. The other consequence of turning one of these not-actually-modular monoliths into microservices is they b

Agreed with all of this. Composition over inheritance. The other consequence of turning one of these not-actually-modular monoliths into microservices is they bring the same bad behavior with them tightly coupled services where any failure in the chain cascades throughout. It takes a LOT of work and effort to build microservices that aren't a fragile mess. How many companies going full steam ahead on microservices don't have another team dedicated to trying to bring the system down just to ensure the resiliency (http://principlesofchaos.org/ http://principlesofchaos.org/)? And you have to ask what you're actually doing this work for. Because everyone here knows you can scale the shit out of a monolith just by throwing some more hardware at it and hardware is cheap. I think this is because the real problem microservices are trying to solve is how to do software development with thousands of developers contributing to related code bases without productivity grinding to a halt. Sure at the very high end of scalability being able to isolate computationally intensive portions of the code might make sense to spin off into its own service justifying decomposing the monolith a bit. But very rarely do scalability and performance requirement necessitate full blown microservice adoption. Craigslist is an example of a company with so few developers and such a restricted feature set that they likely would never have to move to microservices because the handful of developers they have can all grok the system as a whole. Regardless of how many users they had to scale up to support.