As is often stated, microservices is a solution for scaling an engineering org to 100s of developers, not for scaling a product to millions of users.
While microservices force physical separation, they don't stop "Spaghetti Architecture." Instead of messy code, you end up with "Distributed Spaghetti," where the dependencies are hidden in network calls and shared databases.
Microservices require more discipline in areas like:
Observability: Tracking a single request across 10 services. Consistency: Dealing with distributed transactions and eventual consistency. DevOps: Managing N deployment pipelines instead of one.
For most teams Modular monolith is often the better "first step." It enforces strict boundaries within a single deployment unit using language-level visibility (like private packages or modules). It gives you the "Separation of Concerns" without the "Distributed Spaghetti" network tax.
According to my understanding this is one of the reasons why microservices were invented, to prevent shared databases?
I'm not sure if this is a discipline issue in the way that domain driven design, say, is a discipline issue. If you instrument requests with a global ID and point at tool at it then you're basically done from the individual team perspective.
Sure you can say e.g "this property wasnt set in this request while being processed by this service managed by this team", but why it wasn't set will inevitably need multiple teams, each doing in-depth analysis how such as state could've been caused because they always inevitably become distributed monoliths - the former is being provided by the instrumentation, but the latter isn't (and even the former is not perfect, as not all frameworks/languages have equal support)
I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.
So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying.
When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead.
The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.
This is a behavior I would say is very hard to manage out of people and should be screened for aggressively in interviews.
The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead.
If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.
I don't know if you can in general - by happy coincidence the engineer who had made that plan found his way to the door shortly thereafter
He started complaining to management that 50 CI/CD setups was his limit he could support.
He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.