4 ms·

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

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.
        jacobr1 4y ago
        I was arguing the opposite, coordinated deployments already presumes more maturity than I was considering. I've only been at one company with same-day deployments. All the other places have been free-for-alls where each group determines their own release schedule, with their own pipelines. Managing deployments between dependent services thus requires significant coordination overhead (or none, because you are stuck with what you get until the other teams deliver your needs on their own timeline). In chaotic environments like that, microservices help with defining clear ownership of operational responsibility, though at the cost of clear responsibility for the overall distributed system. This comes at the cost of making it hard to develop, let alone ship, changes that impact multiple microservices (outside the scope of a single team, or closely related sibling teams). The main point I was making was that, with a more monolithic system, managing that kind to organization disfunction, necessitates top-down, waterfall like control. So moving to microservices enables non-coordinated agility removing one layer of coordination problem (a the cost of other problems).
      - pjmlp 4y ago
        Unless there is infrastructure in place good luck replicating those dropped requests as services are replaced. Infrastructure that someone has to take care of.
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.

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.
      - jacobr1 4y ago
        I was arguing the opposite, coordinated deployments already presumes more maturity than I was considering. I've only been at one company with same-day deployments. All the other places have been free-for-alls where each group determines their own release schedule, with their own pipelines. Managing deployments between dependent services thus requires significant coordination overhead (or none, because you are stuck with what you get until the other teams deliver your needs on their own timeline). In chaotic environments like that, microservices help with defining clear ownership of operational responsibility, though at the cost of clear responsibility for the overall distributed system. This comes at the cost of making it hard to develop, let alone ship, changes that impact multiple microservices (outside the scope of a single team, or closely related sibling teams). The main point I was making was that, with a more monolithic system, managing that kind to organization disfunction, necessitates top-down, waterfall like control. So moving to microservices enables non-coordinated agility removing one layer of coordination problem (a the cost of other problems).
    - pjmlp 4y ago
      Unless there is infrastructure in place good luck replicating those dropped requests as services are replaced. Infrastructure that someone has to take care of.

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.