Hacker News Reader

Comment by devoutsalsa | Hacker News Reader

A monolith doesn’t have to be one giant ball of mud. It can be discrete, well-factored services all by itself. I recently worked on decomposing a monolith into micro services, but it felt like we were just spreading one big problem over multiple services. All of the services ended up being tightly coupled, even the the goal was to avoid that. We created a macrolith.

View on HN

And it’s incredibly difficult to work with a distributed monolith. I find that the joy I get from development just fades completely when even trivial changes involve too much faff.

Exactly! All this debate seems to stem from people being forced to work with a big ball of mud and then concluding that no one process should ever be allowed to become that big, because big processes are balls of mud. And so, having missed the real lesson (which isn’t ‘don’t make it big’ but rather ‘don’t make it out of mud’!) they build a big ball of little balls of mud.

> they build a big ball of little balls of mud

Nah, they make a lot of sturdy, well structured rocky balls.

And let them move around a big mud soup that is outside of their sight. So they don't even see mud.

It's not about monoliths always being a ball of mud. Even the most well-composed monolith still has problems with teams wanting to do conflicting release cycles, needing clearer ownership over who has responsibility for what part of the codebase, and knowing who should be responsible for on-call for which services. And there is, of course, dependency hell, since everything in your monolith probably should depend on the same version of third-party libraries.

> everything in your monolith probably should depend on the same version of third-party libraries.

And definitely runs on the same underlying language/compiler/runtime version

Yep. Want to upgrade from Python 3.8 to 3.10? Good luck, cause you've gotta get every engineering team in the organization to buy in and schedule time to do upgrade testing, not to say anything about fixing any breaking changes.

Agreed, transforming a monolith into a 'distributed monolith' just creates a different set of even worse problems, the root issues are still unsolved.

Still, thanks to AWS it's vogue, expensive and probably keeps half of us employed when we have to untangle it all!

Reply on news.ycombinator.com