Boy look at that architecture diagram, I'm going in the opposite direction. A mono repo that compiles to one single binary that does everything. Sort of like how an fertilised egg divides and each cell finds its place in the organism. A self organising architecture, you hear'd it here first.
We are already there. One repo for the entire organization, one binary image per customer, and one management tool to bind it all. Everyone is working in the same box and adding value in the same direction.
It is the most magnificent thing I have been a part of so far. It almost feels like we've actually figured this shit out. Looking back at separate repositories from this perspective is like looking back at decrepit playground equipment you used to enjoy as a child.
A well organized and understood single binary always beats a bunch of decoupled systems nobody can untangle fully, this is not rocket science. It’s why we started coming up with tracing systems like Jaeger and OpenTracing to merely figure out what happens across different domains and code boundaries. The skill is in making changes that accommodates both current and future business needs as well as future developers. If your random CRUD app isn’t understandable without a PhD in a niche domain, you need to decide if that’s a feature (HFT perhaps?) or a fault (99%+ of commercial CRUD apps).
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.
