I used to think the same way, give frontend & backend their own repos and we will talk in a meeting about some rest api, works fine for most, but if you want to grow ur proto anus into an intestinal track that safely processes nutrients and uses the same pipe as the airways then it matters what everybody else is doing.
Yes. Given schedule pressure a dev, in a monolith, can avoid good practices and create a web of dependencies. Eg. To get this feature shipped in time I’m not going to refactor the billing interface to expose new attributes that I need. Instead I’ll just query the DB directly from the user profile controller. Repeat this over a few years and a monolith can be a nightmare.
Whereas shipping as independent services it is harder to cheat because the user profile team doesn’t have access to the billing tables and must go through the billing API.
Of course it is possible for monolith teams to enforce the separation but no team has because it would slow things down in the short term. Then in the long term it’s too complex to unwrap and teams refactor using serverless because that’s what is in style. Of course however nobody is writing about the new problems this approach creates.
> Instead I’ll just query the DB directly from the user profile controller. Repeat this over a few years and a monolith can be a nightmare.
I've seen this, a rat's nest of module dependencies, poorly thought-out module/library use, and a lack of ownership and direction around shared bits.
Monorepos also make dangerous things like breaking api changes look easy, or maybe hide them altogether.
Hard problems around ownership, dependency management, and api versions are hard in polyrepos, and I think I'm OK with this. It makes you be more thoughtful.
This is kinda true of serverless, too, it can degenerate into tight coupling. EventBridge now solves that (somewhat). I've also seen huge StepFunctions, which are also awful to test (except for uploading them). Every project needs some discipline.
As the team size scales the additional complexity of this architecture let’s teams work More independently.
At least that’s my take on why you’d want to replace a monolith with micro service & serverless.