6 ms·

Parnas was writing under an assumption of BDUF, big-bang releases, and expensive hardware instances. As soon as you want to decouple module deployments and acco

Parnas was writing under an assumption of BDUF, big-bang releases, and expensive hardware instances. As soon as you want to decouple module deployments and accommodate changing requirements over time you need something else. That "something else" might be "making sure your modular monolith has a good enough test suite that any team can deploy it with only their changes" or it might be "microservices for all", but Parnas' assumption that independently verified modules will need to be built once by independent teams then function correctly when assembled has been comprehensively squashed in the last 50 years. He's right as far as Conway's Law goes, though.

unwind 4y ago
Here I guess BDUF = big design up front. Edit: failed to spell "I" correctly. Ouch.
treis 4y ago
Can you explain why you can deploy microservices independently but not modules?
- regularfry 4y ago
  You can deploy modules independently, but the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in. Modules live in the same execution context, so you need a good shared ownership model for that context itself. The point is that Parnas never conceived of doing it because he was writing about a world where the interfaces between modules were known ahead of time and were static.
  - pjmlp 4y ago
    Same thing with microservices, unless you do a blue green deployment, have a planned shutdown, load balancer in between releases,...
    - regularfry 4y ago
      The key word is "independently".
      - pjmlp 4y ago
        There is no independently in distributed systems.
        regularfry 4y ago
        You can't solve the halting problem either, and yet somehow useful work gets done.
        jacobr1 4y ago
        But there are rules of blame. With microservices, as long as you maintain the contract with caller services, you can deploy whenever you want. If you have some kind of issue, your team is solely responsible. If the caller services do weird things, they are responsible for fixing them. If you are pushing changes to a module as part of a more monolithic, or wrapper service - if you do a deploy and break the whole big service, you are now responsible for the entirety of any issue, which is now more likely due to integration risk and unrelated changes from others, especially because now there need to be coordination across many teams integrating - hopefully via tests and observability. But this requires a high-degree of maturity for automated quality assurance and site reliability. If you don't have that, the operational risks are very high. So that alternative is having some ops-like function, or other integration team responsible. Or doing more top-down waterfall coordination. Given the service maturity needed is rare, microservices distributes that operational ownership in a way where there is more accountability.
        Pet_Ant 4y ago
        Every organisation I've worked at that had microservices has had all of them released every other Thursday at the same time by the same pipeline because they are tied to the organisation scrum schedule. Also, most changes are part of epics that span multiple microservices. If you are gonna argue that properly done microservices don't have that problem you are free to practice your perfect microservices alongside perfect scrum, oop, and communism.
  - treis 4y ago
    You need to do additional steps in both cases: With modules you need some sort of wrapper application to bring it all together. With microservices you need some sort of network layer so that the microservices can talk to each other.
    - regularfry 4y ago
      And also with modules you need the business processes to coordinate deployments across teams, because they all live in the same wrapper application. That's what stops them being independent. You don't restart the network every time you deploy a microservice.
      - treis 4y ago
        >And also with modules you need the business processes to coordinate deployments across teams, because they all live in the same wrapper application. That's what stops them being independent. If we're being technical some languages support hot swapping modules so no restart would be needed. Setting that aside, restarting an application isn't anything that needs coordination today. You wouldn't even restart the application. You'd deploy a new version, swap over, and shut down the old version. >You don't restart the network every time you deploy a microservice. No, but something changes in the network configuration so that the other microservices are aware of the deployment.
  - dkarl 4y ago
    > the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in They aren't built in, it's just that the need for them is impossible to ignore. Developers (and management) can't help but recognize and respect modularity in microservices because the separation of services and the APIs between them make the modularity obvious. When the separation between modules only exists in code, and even then only when seen through the eyes of someone who understands the modular architecture of the codebase, it is easily ignored, inevitably forgotten, and might as well not exist at all.
    - esailija 4y ago
      Module is not just code in a separate file. Litmus test: if you cannot have two modules be written in separate languages - you don't have modules. M If all modules have to be deployed using the same build even though different build of the modules would have been API compatible - you don't have modules.
      - int_19h 4y ago
        That sounds way too strict to me. A C++ app might use the C++ ABI to communicate with its modules, which would preclude writing them in any other language without jumping through too many hoops. But that's an ABI constraint and says nothing about the actual modularity of the application. IMO a module is defined as something that has a self-contained API, and versioning rules for that API if the module is evolving.

unwind 4y ago

Here I guess BDUF = big design up front. Edit: failed to spell "I" correctly. Ouch.

treis 4y ago

Can you explain why you can deploy microservices independently but not modules?

regularfry 4y ago
You can deploy modules independently, but the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in. Modules live in the same execution context, so you need a good shared ownership model for that context itself. The point is that Parnas never conceived of doing it because he was writing about a world where the interfaces between modules were known ahead of time and were static.
- pjmlp 4y ago
  Same thing with microservices, unless you do a blue green deployment, have a planned shutdown, load balancer in between releases,...
  - regularfry 4y ago
    The key word is "independently".
    - pjmlp 4y ago
      There is no independently in distributed systems.
      - regularfry 4y ago
        You can't solve the halting problem either, and yet somehow useful work gets done.
      - jacobr1 4y ago
        But there are rules of blame. With microservices, as long as you maintain the contract with caller services, you can deploy whenever you want. If you have some kind of issue, your team is solely responsible. If the caller services do weird things, they are responsible for fixing them. If you are pushing changes to a module as part of a more monolithic, or wrapper service - if you do a deploy and break the whole big service, you are now responsible for the entirety of any issue, which is now more likely due to integration risk and unrelated changes from others, especially because now there need to be coordination across many teams integrating - hopefully via tests and observability. But this requires a high-degree of maturity for automated quality assurance and site reliability. If you don't have that, the operational risks are very high. So that alternative is having some ops-like function, or other integration team responsible. Or doing more top-down waterfall coordination. Given the service maturity needed is rare, microservices distributes that operational ownership in a way where there is more accountability.
        Pet_Ant 4y ago
        Every organisation I've worked at that had microservices has had all of them released every other Thursday at the same time by the same pipeline because they are tied to the organisation scrum schedule. Also, most changes are part of epics that span multiple microservices. If you are gonna argue that properly done microservices don't have that problem you are free to practice your perfect microservices alongside perfect scrum, oop, and communism.
- treis 4y ago
  You need to do additional steps in both cases: With modules you need some sort of wrapper application to bring it all together. With microservices you need some sort of network layer so that the microservices can talk to each other.
  - regularfry 4y ago
    And also with modules you need the business processes to coordinate deployments across teams, because they all live in the same wrapper application. That's what stops them being independent. You don't restart the network every time you deploy a microservice.
    - treis 4y ago
      >And also with modules you need the business processes to coordinate deployments across teams, because they all live in the same wrapper application. That's what stops them being independent. If we're being technical some languages support hot swapping modules so no restart would be needed. Setting that aside, restarting an application isn't anything that needs coordination today. You wouldn't even restart the application. You'd deploy a new version, swap over, and shut down the old version. >You don't restart the network every time you deploy a microservice. No, but something changes in the network configuration so that the other microservices are aware of the deployment.
- dkarl 4y ago
  > the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in They aren't built in, it's just that the need for them is impossible to ignore. Developers (and management) can't help but recognize and respect modularity in microservices because the separation of services and the APIs between them make the modularity obvious. When the separation between modules only exists in code, and even then only when seen through the eyes of someone who understands the modular architecture of the codebase, it is easily ignored, inevitably forgotten, and might as well not exist at all.
  - esailija 4y ago
    Module is not just code in a separate file. Litmus test: if you cannot have two modules be written in separate languages - you don't have modules. M If all modules have to be deployed using the same build even though different build of the modules would have been API compatible - you don't have modules.
    - int_19h 4y ago
      That sounds way too strict to me. A C++ app might use the C++ ABI to communicate with its modules, which would preclude writing them in any other language without jumping through too many hoops. But that's an ABI constraint and says nothing about the actual modularity of the application. IMO a module is defined as something that has a self-contained API, and versioning rules for that API if the module is evolving.