So it's "bad micro-service architecture imposes a heavy penalty on team co-ordination", then.

...which is a fairly obvious observation. "Bad <x> imposes a heavy penalty on team co-ordination" is generalizable.

There is no bad vs good micro-service architecture. It is just that micro-service architecture imposes a different kind of penalty on co-ordination and debugging. Instead of intra-component dependency, it moves it to inter-service dependency. Each service might look simple, but the complexity is moved to service communications. It is not that obvious, imho.

Also, what is good and bad can change over time with the business. Few judgement calls in software will last forever.

There absolutely are bad microservice architectures, that's a weird claim to make. Good microservice architectures minimize or entirely eliminate the friction around the coordination and debugging. I'm working on splitting out a monorepo as we speak and I'm determining tradeoffs we'll need to make. If I do this wrong, there will be a lot of pain around navigating between the services, but there are choices I can make now that minimize (or eliminate in some cases) that pain.

I recommend you find a way to spend time with someone who knows how to design a quality microservices architecture. It will completely change your opinion about how microservices interact and the supposed "pain" therein.

If it were so obvious, I am wondering why you need to worry about doing it wrong. You talk about trade-offs as if they are fixed in time. That is not the case at all in anything but toy systems. Maybe you need to find someone who can design a quality micro-service?

You have no idea what I do and what my competencies are, yet, you are assuming you know a lot more about system design than I do and I am missing something simple.

Here is another take from Bryan Cantrill [https://www.youtube.com/watch?v=30jNsCVLpAE&t=1413s]. Very likely, he does not know anything about services either, I guess.

Can you show me where I said "building microservices is obvious"? Or if you don't believe I said that, can you describe what you think it is I'm suggesting here? Because my intent was to say, "It is obvious that microservices can be designed well and designed poorly." In fact, if you'll observe, I removed the word "microservices" from my final statement, to demonstrate that such a statement is trivially true for any given thing.

Nowhere did I say, "It is obvious how to design a good microservice." but it seems like you're arguing against that statement, not the one I made.

And for what it's worth, I don't give a hoot who you are, who Bryan Cantrill is, or what your supposed competencies are; make your argument, don't rely on your pedigree to speak for you. That should be obvious.

I think the answer is kind of obvious, but disappointing: the way to scale is to both divide responsibility while simultaneously sharing it. The way to do this well is to work on the basics: communication, training, quality, study, operations, continuous improvement.

There is no magical model for this, no buzzword, no single practice, because different businesses and use cases need to be adapted to it. But there's 70+ years of study into methods to do this, and I believe they're taught by all the business schools. It's just nobody wants to do the work.

....On the other hand, nobody teaches MBAs how drastically different tech is than other industries, and thus how you run your "factory floor" has to be different. But the basic principles above should still be applied; they just have to be adapted to the industry and work. What one should not do is just accept things however that industry does it, because they probably aren't doing the above principles either.