> Microservices are primarily good at scaling the human organization (#1). I agree but this is what worries me about them; micro-services encourage team scale

> Microservices are primarily good at scaling the human organization (#1). I agree but this is what worries me about them; micro-services encourage team scale up and that is really difficult to do well. In theory you'd have separate services with well defined APIs. You'd know upfront what behaviour belongs where and could get the right people to deliver changes on schedule. The reality is often a form of disguised waterfall development and it rarely works out well unless you are very careful. Instead you've gained the problem of refactoring multiple services, in multiple languages, owned by multiple competing teams, each with their own management and agenda. Productivity takes a nosedive and more bodies get added in an attempt to make up for it. The result is the opposite[1]. You're much better off striving to keep a small team as productive as possible with adding team members a last resort. Project management at scale is such a difficult task that if you can delay doing it, you should. Startups have no choice but to use small teams. As a consequence they have good productivity and low barriers to communication without really thinking about it. The problem in larger enterprises is that the highest status project manager is often the one with the biggest team and not the highest productivity. Personally, I'd rather have a few guys with massive servers than a massive team with lots of small services. - 1. This nothing new, it's what Fred Brooks was talking about in the Mythical Man Month back in the 1970s. https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month