5 ms·

> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a sys

> If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at. No modularization technique has a monopoly on this characteristic.

100011_100001 6y ago
It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.
- mumblemumble 6y ago
  I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
  - 100011_100001 6y ago
    Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
    - rowland66 6y ago
      I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
      - mumblemumble 6y ago
        Largely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized". That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it. Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.
rwoerz 6y ago
True. Microservice people would reply that microservice enforce modularization (as remote address spaces do not allow for dirty shortcuts). However that argument seems to me like drilling out a spark plug to help yourself with speed limits.
- coding123 6y ago
  People in the monolith space call that "different JARs"

100011_100001 6y ago

It's a lot easier to violate that when it's just an import and a call away. I will concede that if the system is well designed and developers follow the patterns set it doesn't matter if it's a microservice based architecture or not.

mumblemumble 6y ago
I suppose it depends on your language. For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
- 100011_100001 6y ago
  Perhaps the dev culture I am in is skewing my perspective. There have been developers that have changed private methods to public just so that they can access them. You make a good point, it's a code review problem and by extension Architecture teams not communicating effectively with Dev Leads.
  - rowland66 6y ago
    I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
    - mumblemumble 6y ago
      Largely because it's not that powerful. It's got several shortcomings, but the main one is that Java doesn't actually understand Java package organization conventions. To Java, "com.mycompany.stuff" and "com.mycompany.stuff.specialized" are two completely unrelated packages, and so stuff that's package-private to "com.mycompany.stuff" is inaccessible from "com.mycompany.stuff.specialized". That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it. Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.

rwoerz 6y ago

True. Microservice people would reply that microservice enforce modularization (as remote address spaces do not allow for dirty shortcuts). However that argument seems to me like drilling out a spark plug to help yourself with speed limits.

coding123 6y ago
People in the monolith space call that "different JARs"