4 ms·

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 int

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.

stepbeek 3y ago
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.
intelVISA 3y ago
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!
taneq 3y ago
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.
- marcosdumay 3y ago
  > 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.
mjr00 3y ago
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.
- jameshart 3y ago
  > 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
  - mjr00 3y ago
    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.

stepbeek 3y ago

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.

intelVISA 3y ago

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!

taneq 3y ago

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.

marcosdumay 3y ago
> 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.

mjr00 3y ago

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.

jameshart 3y ago
> 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
- mjr00 3y ago
  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.