3 ms·

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs c

> Big monolithic apps have large codebases that slow down development velocity. They’re slower to compile, harder to test, and full of dark corners where bugs can lurk and multiply. A bad change to one part of a codebase can cause headaches for an entire building’s worth of developers, tanking productivity for hours or days. This has NOTHING to do with monoliths. If you cannot architect a monolith, you’re going to have a hell of a time with micro services. This just comes down to being an awful software engineer.

gardenhedge 3y ago
A monolith has more engineers working on it though and chances are some of them won't be great.
- tracerbulletx 3y ago
  It has nothing to do with individuals not being great, organizations of perfectly talented well intentioned people still end up with a mess eventually.
- zelphirkalt 3y ago
  In the end the code needs to be written. What is better, parts of a monolith being shitty, or a subset of the microservices being shitty?
- slashdev 3y ago
  Those same engineers will still be there in the microservices world. You can argue that the damage they can do is reduced, but I don’t think that’s always true.
  - gardenhedge 3y ago
    That's my point though. Damage a monolith - big trouble. Damage a microservice - much more approachable to rewrite or replace.
throwaway894345 3y ago
I don’t think this is true. I’ve seen the same 30-odd engineering team build a horrible monolith and a pretty decent microservice architecture. The difference between the two was that it was very easy to cheat in the monolith world—it was expedient to patch in some feature by giving access to some thing which ought to be private in one component and that shortcut was often commanded by management (often with promises that We Will Definitely Prioritize Fixing Properly Next Sprint). Microservices make this sort of cheating more difficult than doing the proper thing, so management and their yes-men don’t have an incentive to cheat in that particular way. Another reason things were cleaner was because we could write components in the language that was best suited for it. In our monolith version, everything had to be Python because we essentially needed its data science ecosystem, but that meant every other component in the system was fighting against Python’s package management, performance, and reliability problems for no material gain. I think you can get similar rails in a monolith world via strict anti-shortcut culture, but technical controls are a lot easier than political controls IMHO. Similarly, you could probably build some Frankenstein FFI regime in a monolith to support multiple languages, but that seems strictly worse from a maintainability perspective. All that said, there are definitely costs to building with microservices—I’m not saying they’re a panacea or even better than monoliths in the general case, I just don’t buy the “if you can’t do it in monolith you won’t be able to do it with microservices” line.
grumblingdev 3y ago
Usually tooling related. I don't know what language you can pick today that is not a complete shit-show for dependency management.

gardenhedge 3y ago

A monolith has more engineers working on it though and chances are some of them won't be great.

tracerbulletx 3y ago
It has nothing to do with individuals not being great, organizations of perfectly talented well intentioned people still end up with a mess eventually.
zelphirkalt 3y ago
In the end the code needs to be written. What is better, parts of a monolith being shitty, or a subset of the microservices being shitty?
slashdev 3y ago
Those same engineers will still be there in the microservices world. You can argue that the damage they can do is reduced, but I don’t think that’s always true.
- gardenhedge 3y ago
  That's my point though. Damage a monolith - big trouble. Damage a microservice - much more approachable to rewrite or replace.

throwaway894345 3y ago

I don’t think this is true. I’ve seen the same 30-odd engineering team build a horrible monolith and a pretty decent microservice architecture. The difference between the two was that it was very easy to cheat in the monolith world—it was expedient to patch in some feature by giving access to some thing which ought to be private in one component and that shortcut was often commanded by management (often with promises that We Will Definitely Prioritize Fixing Properly Next Sprint). Microservices make this sort of cheating more difficult than doing the proper thing, so management and their yes-men don’t have an incentive to cheat in that particular way. Another reason things were cleaner was because we could write components in the language that was best suited for it. In our monolith version, everything had to be Python because we essentially needed its data science ecosystem, but that meant every other component in the system was fighting against Python’s package management, performance, and reliability problems for no material gain. I think you can get similar rails in a monolith world via strict anti-shortcut culture, but technical controls are a lot easier than political controls IMHO. Similarly, you could probably build some Frankenstein FFI regime in a monolith to support multiple languages, but that seems strictly worse from a maintainability perspective. All that said, there are definitely costs to building with microservices—I’m not saying they’re a panacea or even better than monoliths in the general case, I just don’t buy the “if you can’t do it in monolith you won’t be able to do it with microservices” line.

grumblingdev 3y ago

Usually tooling related. I don't know what language you can pick today that is not a complete shit-show for dependency management.