4 ms·

I think it's touched in #2 and #4. The author argues that it becomes more complicated because each service needs to be understood thoroughly and mentions the "n

I think it's touched in #2 and #4. The author argues that it becomes more complicated because each service needs to be understood thoroughly and mentions the "not-my-problem syndrome". While these issues are definitely there, the problem of understanding a subsystem also exists on large monolithic applications. The not-my-problem syndrome seems like an indicator of bad devs and/or company culture (I've seen this happen once) and might be mitigated by making people work on multiple microservices instead of completely separating them. In my opinion, separating a big project into multiple services emerges from the fact that most languages don't have built-in features for modularization on a large scale. In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos.

lmm 10y ago
> In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos. At that point you step up to using multiple maven modules. Which can give much the same development experience as microservices, but without the extra network boundary.
- blauditore 10y ago
  Yeah, that's one way to go, and also supports separate versioning and release cycles of different subsystems. However, since all code is compiled into one large application there are other problems arising. One I've seen often is sloppy dependency management: A explicitly depends on B, B on C. Now, a dev working in A starts using classes from C without declaring the dependency. Everything works because C is still included through B, but as soon as B gets removed, things start to break. There is mvn dependency:analyze to discover such issues, but it's not 100% exact, and people need to actively use it. I think such a system built into and enforced by a language would be another quantum leap.
  - lmm 10y ago
    It's very normal for methods in B to return types from C in that scenario though. And if you do remove the dependency on B, you get the error at compile time. So I don't see this as a major problem (it's maybe a problem if something's implicitly activated by reflection, but I see the reflection as the bigger problem there)
    - blauditore 10y ago
      When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question. But yeah, at least it fails on compile time already.
      - lmm 10y ago
        > When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Just go to search.maven.org and do a full class name search, no?
        blauditore 10y ago
        The problem is that this doesn't work for modules not published there, i.e. if you have a large in-house code base split into many maven modules.
        lmm 10y ago
        IDEs can open classes by name, wherever they are on the classpath. I'd normally have all projects open in any case even on quite large codebases - it's very practical with modern hardware.
        10y ago

lmm 10y ago

> In Java, for instance, there are methods < classes < packages. Once there are dozens of packages and thousands of classes, a project becomes hard to navigate and understand, especially when code isn't well-written with hacks disregarding modularizations. Using microservices reduces scope and prohibits some of these no-gos. At that point you step up to using multiple maven modules. Which can give much the same development experience as microservices, but without the extra network boundary.

blauditore 10y ago
Yeah, that's one way to go, and also supports separate versioning and release cycles of different subsystems. However, since all code is compiled into one large application there are other problems arising. One I've seen often is sloppy dependency management: A explicitly depends on B, B on C. Now, a dev working in A starts using classes from C without declaring the dependency. Everything works because C is still included through B, but as soon as B gets removed, things start to break. There is mvn dependency:analyze to discover such issues, but it's not 100% exact, and people need to actively use it. I think such a system built into and enforced by a language would be another quantum leap.
- lmm 10y ago
  It's very normal for methods in B to return types from C in that scenario though. And if you do remove the dependency on B, you get the error at compile time. So I don't see this as a major problem (it's maybe a problem if something's implicitly activated by reflection, but I see the reflection as the bigger problem there)
  - blauditore 10y ago
    When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Then, the right version needs to be determined by following removed intermediate modules. It would just be cleaner and more reliable if the original dev had done this when writing the code in question. But yeah, at least it fails on compile time already.
    - lmm 10y ago
      > When running into these runtime errors, it's sometimes not clear what module a missing class came from for complex setups, especially in a part of code you didn't recently work in. Just go to search.maven.org and do a full class name search, no?
      - blauditore 10y ago
        The problem is that this doesn't work for modules not published there, i.e. if you have a large in-house code base split into many maven modules.
        lmm 10y ago
        IDEs can open classes by name, wherever they are on the classpath. I'd normally have all projects open in any case even on quite large codebases - it's very practical with modern hardware.
        10y ago