its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.

For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter.

You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev.

Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.

> 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?"

It's easier to find people who are confident that they understand a microservice, but the fact is that it interacts with the system as a whole and much of that interaction is dark matter. It's unknown unknowns that lead to Dunning-Kruger. People looking at a large system have more known unknowns and are less likely to be overconfident to the same degree.

Also we need to have about 5x as many people graduating with formal classes in distributed computing as are now or have been for the last several decades and it's just ridiculous how many people have to learn this stuff on their own. Distributed debugging is really had when you don't understand the fundamental problems.

But, uh, both Google and Yandex use monorepo-style of development; and microservices style of deployment, yes. Go figure.

The reality is, the organizational structure likely to change over time, then would anyone want to mirror it in the repo structure?

Not likely, no.

I prefer mid-scale services. For a given app, there shouldn’t be more than 20-30 of them (and preferably around 10). Each will still have clean ownership and single responsibility, but the chaotic quadratic network effect will hopefully not get out of control. Cleanly defined protocols become a necessity though.

Except it never does. Have you ever heard of a company with a thousand teams?

Or for that matter, how many default alive companies have more teams than customers?