> retain some super senior rockstar level folks able to see the big picture

This is the critical piece that many organisations miss.

Microservices are the bricks; but the customer needs those assembled into a house.

You need those senior folks who can see the big picture, whether you use monoliths or microservices.

The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.

At the cost of network boundaries everywhere, and all that entails

If there are network problems everything fails anyway, so it's not really an issue in production.

In the end, it depends on your skillsets. Most developers can't deal with a lot of complexity, and a monolith is the simplest way to program. They also can't really deal with scale, and cost of learning how to build a real distributed system is high...and the chances you'll hit scale are low.

So instead people scale horizontally or vertically, with ridiculously complicated tools like k8. K8 basically exists outside of google because developers can't write scalable apps, whether monolithic or microservice-based.

It's so funny we always use technical solutions to solve social problems, while confusing which parts are what. :)

My interpretation of Conways Law is that social problems) in development organizations) are isomorphic to (gross) technical problems, and that leverage works both directions.

Btw, important factor: you can only see the big picture properly if you co-created the setup. Hiring senior rockstars as a reaction to problems will satisfy some short-term goals but not solve the problems overall

"I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?"