An they pose(d) some attraction. A boss after getting tired developing the baby that turned into a monolith and brought enough wealth to the table started to outline a new system with 12 or so microservices. Each one could be designed and planned and all written out in nice 2 to 6 page documents - one for each service.

Now guess the size of the code wrangler team. And as this was so super-extravagant, guess the number of developers who were "promoted" to work on those micro-services.

> But, boy, do they need 10x more engineers to maintain this all.

Well stupidity saves you here. Ignore the one team per microservice rule and swap it with the "one-size-fits-it-all" developer rule: just promote one of the single team to be responsible for all micro-services. One lunatic that pushes code fast enough that management does not realize what is going on. Once everything is up and running, it just runs. The rest is downtime eventually, but you know what, its a software problem, what could be done? As long as everyone involved looks busy - and it's easy with plenty of micro-services to play whack-a-mole, bring one up again, kill two others, it is just a fail in the design as they should have been designed with failover but that was missed!

Dropbox migrated to Go microservices

Fair enough. At that scale it's different. My point is that many major companies were a productive team working with a monolith until it simply was not feasible.

Yes, you always want to start with a monolith then break out micro services as the API, scaling and deployment strategies, and team sizes become clear from running in and scaling in production for a good while.