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.
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.