> The most pragmatic approach to microservices is to start with a monolith and shave off the intensive parts to separate services as you need to. I've seen tha

> The most pragmatic approach to microservices is to start with a monolith and shave off the intensive parts to separate services as you need to. I've seen that attempted several times but I've never seen it succeed even after several years of shaving things off here and there. The problem with this approach is the same problem that causes all technical debt -- cleaning up technical debt takes time away from developing new features, which is the company's highest priority. Adding more engineers to the team to help tackle debt won't help because management will see that as an opportunity to get more new features. Now that the dust has settled, it's become clear that the real advantage of microservices is to decouple teams. Shared codebases become harder to work with as the number of engineers increases, and that hurts developer productivity. Don't build a monolithic service for the whole company -- have every team manage their own services, on their own development and release schedule, and their own production scale. Their dependencies on other teams should be based on APIs, not code sharing. Whether an individual team chooses a monolith or microservices doesn't really matter.