4 ms·

On a large/quickly growing team the risk is folks begin to not respect the modularity and you end up with just a regular monolith Perhaps formalized abstractio

by 2c2c2c 3y ago

On a large/quickly growing team the risk is folks begin to not respect the modularity and you end up with just a regular monolith Perhaps formalized abstractions around these barriers is a good idea? At the very least better than the 60 kubernetes services at my 100eng headcount team? :-)

wizofaus 3y ago
One major criticism I have of the way modules work in many stacks is that the dependencies between modules are hard to visualise and/or manage. Certainly in the C#/.NET world it's very easy to accidentally end up with one module depending on another that depends on the initial module via some chain of dependencies. And it's too easy to add extra dependencies to some low-level module that's supposed to be a "core" base layer module that's used across the board. That's less of a problem with microservices, esp. in a multi-repo environment, where you can enforce boundaries more easily. It's one of the few points in favour of microservices, from what I've observed so far - that you can safely make a change to a particular microservice and know a) it's definitely not going to break the CI/CD pipeline for the rest of the product b) if you have introduced a bug, there's typically very limited impact it can have.
- Quekid5 3y ago
  Exactly. On the JVM (at least, dunno if C#/.NET has a similar mechanism) you can technically get away with using OSGi which can load things into separate classloaders along with all implementation-dependencies such that you can truly separate the API of a dependency from its implementation. Alas, support for OSGi in the general ecosystem is abysmal, and the next best thing seems to be microservices. Honestly, I find it pretty shocking that so many mainstream languages don't support this sort of "local isolation" better. The diamond dependency problem well-known at this point. (To be clear, in our shop we generally only do this for very problematic dependencies that have a tendency to break backward bincompat on a whim. Those are almost always the most painful ones, especially if they are in turn dependended on by many of your project's other dependencies.)
  - javanonymous 3y ago
    Spring Modulith is trying to enforce strict module boundaries. I haven't yet tried it myself, but it looks promising: https://spring.io/blog/2022/10/21/introducing-spring-modulith https://spring.io/blog/2022/10/21/introducing-spring-modulit...

by 2c2c2c 3y ago

wizofaus 3y ago

One major criticism I have of the way modules work in many stacks is that the dependencies between modules are hard to visualise and/or manage. Certainly in the C#/.NET world it's very easy to accidentally end up with one module depending on another that depends on the initial module via some chain of dependencies. And it's too easy to add extra dependencies to some low-level module that's supposed to be a "core" base layer module that's used across the board. That's less of a problem with microservices, esp. in a multi-repo environment, where you can enforce boundaries more easily. It's one of the few points in favour of microservices, from what I've observed so far - that you can safely make a change to a particular microservice and know a) it's definitely not going to break the CI/CD pipeline for the rest of the product b) if you have introduced a bug, there's typically very limited impact it can have.

Quekid5 3y ago
Exactly. On the JVM (at least, dunno if C#/.NET has a similar mechanism) you can technically get away with using OSGi which can load things into separate classloaders along with all implementation-dependencies such that you can truly separate the API of a dependency from its implementation. Alas, support for OSGi in the general ecosystem is abysmal, and the next best thing seems to be microservices. Honestly, I find it pretty shocking that so many mainstream languages don't support this sort of "local isolation" better. The diamond dependency problem well-known at this point. (To be clear, in our shop we generally only do this for very problematic dependencies that have a tendency to break backward bincompat on a whim. Those are almost always the most painful ones, especially if they are in turn dependended on by many of your project's other dependencies.)
- javanonymous 3y ago
  Spring Modulith is trying to enforce strict module boundaries. I haven't yet tried it myself, but it looks promising: https://spring.io/blog/2022/10/21/introducing-spring-modulith https://spring.io/blog/2022/10/21/introducing-spring-modulit...