Hacker News Reader

Comment by hinkley | Hacker News Reader

People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution".

You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation.

You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.

View on HN

It seems like a Big Ball of mud is much more difficult to deal with than a bunch of small balls of mud just in general?

It depends but in general I'd disagree. If the small balls of mud have all kinds of implicit dependencies, but you have to find them by searching across codebases (and languages) -- does that sound easier than finding them all in the same codebase and language? Overall, its comparing bad design to bad design. I think the main argument I'd make here is, micro-services doesn't actually solve the big ball of mud problem, it solves a completely different problem.

You can step-through your big ball of mud in a debugger, but you can't do the same with your small balls of mud. Not easily at least. That alone makes a huge difference.

They're both bad. It feels like a reverse Sophie's Choice to have to pick one.

The real friction in the system is always in the boundaries between systems. With microservices it's all boundaries. Instead of a Ball of Mud you have Trees and No Forest. Refactoring is a bloody nightmare. Perf Analysis is a game of finger pointing that you can't defuse.

A thousand small balls of mud that communicate with each other randomly is nearly impossible to grok because the IDE can't save you

Reply on news.ycombinator.com