3 ms·

>they force alignment on one language or at least runtime A sane thing to do. >they force alignment of dependencies and their versions A sane thing to do. Be

>they force alignment on one language or at least runtime A sane thing to do. >they force alignment of dependencies and their versions A sane thing to do. Better yet to do it in a global fashion, along with integration tests. >they can require lots of RAM if you have many modules with many classes You can't make the same set of features build in a distributed manner comsume _less_ RAM than the monolith counterpart. Given you're now running dozens of copies of the same java vm + common dependencies. >they can be slow to start Correct. >they may be limiting in terms of technology choice Correct. >they don't provide resource isolation between components Correct. >they take long to rebuild an redeploy, unless you apply a large degree of discipline and engineering excellence to only rebuild changed modules while making sure no API contracts are broken I think the keyword is the WebLogic Server mentioned before. People don't realise that monolith architecture does't mean legacy technology. Monolith web services can and should be build in Spring Boot, for example. Also, most of the time, comparisons are unfair. In all projects i've worked im yet to see a MS instalation paired feature-wise with his old monolith cousin. Legacy projects tends to be massive, as they're made to solve real world problems while evolving during time. MS projects are run for a year or two and people start to compare around apples to oranges. >they can be hard to test If other team's component break integration, the whole building stops. I think Fail-Fast is a good thing. Any necessary setup must be documented in whatever architectural style. It can be worse in a MS scenario, where you are tasked to fix a dusty, forgotten service with an empty README. If anything, monolithic architecture brings lots of awareness. It's easier to get how things are wired and how they interact together.

Zvez 4y ago
> a sane thing to do imaging your application contains of two pieces - somewhat simple crud, that requires to respond _fast_ and huge batch processing infrastructure, that needs to work as efficient as possible, but doesn't care about single element processing time. And suddenly 'the sane thing to do' is not the best thing anymore. You need different technologies, different runtime settings and sometimes different runtimes. But most importantly they don't need constraints imposed by unrelated (other) part of the system.
- highspeedbus 4y ago
  You're absolutely right. My comment is towards the view that using a single language for a certain Project Backend is a bad thing per se. The online vs batch processing is the golden example of domains that should be separated in different binaries, call it microsservices or services or just Different Projects with Nothing in Common. Going further than that is where the problems arise.
ignite 4y ago
>>they force alignment of dependencies and their versions >A sane thing to do. Better yet to do it in a global fashion, along with integration tests. But brutally difficult at scale. If you have hundreds of dependencies, a normal case, what do you do when one part of the monolith needs to update a dependency, but that requires you update it for all consumers of the dependency's API, and another consumer is not compatible with the new version? On a large project, dependency updates happen daily. Trying to do every dependency update is a non-starter. No one has that bandwidth. The larger your module is, the more dependencies you have to update, and the more different ways they are used, so you are more likely to get update conflicts. This doesn't say you need microservices, but the larger your module is, the further into dependency hell you will likely end up.
jdc0589 4y ago
> A sane thing to do. This is incredibly subjective, and contingent on the size and type of engineering org you work in. For a small or firmly mid-sized shop? yea I can 100% see that being a sane thing to do. Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though As soon as you have highly specialized teams/orgs to solve specific problems, this is no longer sane.
- JAlexoid 4y ago
  > Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though And yet, that is exactly what gets done

Zvez 4y ago

> a sane thing to do imaging your application contains of two pieces - somewhat simple crud, that requires to respond _fast_ and huge batch processing infrastructure, that needs to work as efficient as possible, but doesn't care about single element processing time. And suddenly 'the sane thing to do' is not the best thing anymore. You need different technologies, different runtime settings and sometimes different runtimes. But most importantly they don't need constraints imposed by unrelated (other) part of the system.

highspeedbus 4y ago
You're absolutely right. My comment is towards the view that using a single language for a certain Project Backend is a bad thing per se. The online vs batch processing is the golden example of domains that should be separated in different binaries, call it microsservices or services or just Different Projects with Nothing in Common. Going further than that is where the problems arise.

ignite 4y ago

>>they force alignment of dependencies and their versions >A sane thing to do. Better yet to do it in a global fashion, along with integration tests. But brutally difficult at scale. If you have hundreds of dependencies, a normal case, what do you do when one part of the monolith needs to update a dependency, but that requires you update it for all consumers of the dependency's API, and another consumer is not compatible with the new version? On a large project, dependency updates happen daily. Trying to do every dependency update is a non-starter. No one has that bandwidth. The larger your module is, the more dependencies you have to update, and the more different ways they are used, so you are more likely to get update conflicts. This doesn't say you need microservices, but the larger your module is, the further into dependency hell you will likely end up.

jdc0589 4y ago

> A sane thing to do. This is incredibly subjective, and contingent on the size and type of engineering org you work in. For a small or firmly mid-sized shop? yea I can 100% see that being a sane thing to do. Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though As soon as you have highly specialized teams/orgs to solve specific problems, this is no longer sane.

JAlexoid 4y ago
> Honestly a small shop probably shouldn't be doing microservices as a standard pattern outside of specific cases anyway though And yet, that is exactly what gets done