3 ms·

I sympathize with both positions — however, spend any time working somewhere like a bank, or hardware/electronics company founded before 1980, and you’ll develo

I sympathize with both positions — however, spend any time working somewhere like a bank, or hardware/electronics company founded before 1980, and you’ll develop a distinct distaste for monoliths. I’ve seen monoliths create teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded projects fail to replace a monolith one after another. All crossroads lead to the monolith that was written in some language that died 30 years ago, performs like it did 30 years ago and is maintained by people hired 30 years ago — creating imminent crises with their looming retirements. I think a lot of people here read this article as writing monoliths vs microservices — not so. There are many very old, inherited monoliths that are actively creating maintenance crises at many businesses. These need to be modernized in chunks, because full rewrites take years to fail (and often do, eg. the mythical data warehouse). Microservices offer some incremental path out of the quagmire.

thfuran 4y ago
>teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded projects fail to replace a monolith one after another. All crossroads lead to the monolith that was written in some language that died 30 years ago, performs like it did 30 years ago and is maintained by people hired 30 years ago — creating imminent crises with their looming retirements. None of this seems like a monolith problem, it seems like a very-legacy codebase at a non-tech company problem.
- lolinder 4y ago
  I think their point is that trying to continue to work inside such a monolith is soul-crushing, but attempts to replace the monolith in one step fail because it's too big. I do think there's some confusion, though, because microservices are not the only solution to this problem. You can solve it with two services: the big legacy service hosts all the logic you haven't cleaned up yet, the small-but-growing modern service has the logic that you've cleaned up and made livable. This way you don't have to replace the old monolith in one step, but you also don't need to go to microservices—the target is still one well-factored monolith. (Edit: there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services...)
  - aliswe 4y ago
    > there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services I would call that risk a guarantee. And as long you havent turned the other off, the net result is negative. I say, make the journey as valuable as the goal, and make incremental improvements that offer value from day 1.

thfuran 4y ago

>teams of career software bureaucrats who exist to choke out companies to their last breath. Companies will go underserved for decades while underfunded projects fail to replace a monolith one after another. All crossroads lead to the monolith that was written in some language that died 30 years ago, performs like it did 30 years ago and is maintained by people hired 30 years ago — creating imminent crises with their looming retirements. None of this seems like a monolith problem, it seems like a very-legacy codebase at a non-tech company problem.

lolinder 4y ago
I think their point is that trying to continue to work inside such a monolith is soul-crushing, but attempts to replace the monolith in one step fail because it's too big. I do think there's some confusion, though, because microservices are not the only solution to this problem. You can solve it with two services: the big legacy service hosts all the logic you haven't cleaned up yet, the small-but-growing modern service has the logic that you've cleaned up and made livable. This way you don't have to replace the old monolith in one step, but you also don't need to go to microservices—the target is still one well-factored monolith. (Edit: there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services...)
- aliswe 4y ago
  > there's a risk here, of course, that your new code becomes another legacy ball of mud that everyone hates and the cycle repeats, but this time with two services I would call that risk a guarantee. And as long you havent turned the other off, the net result is negative. I say, make the journey as valuable as the goal, and make incremental improvements that offer value from day 1.