4 ms·

> Microservices [..] actually solve for a human problem in scaling up an organization. So does modularity. "The benefits expected of modular programming are:

> Microservices [..] actually solve for a human problem in scaling up an organization. So does modularity. "The benefits expected of modular programming are: (1) managerial_development time should be shortened because separate groups would work on each module with little need for communication..." On the Criteria To Be Used in Decomposing Systems into Modules, D.L. Parnas 1972. http://sunnyday.mit.edu/16.355/parnas-criteria.html http://sunnyday.mit.edu/16.355/parnas-criteria.html

LAC-Tech 4y ago
Off topic, but 70s computing papers are just the best aren't they?
regularfry 4y ago
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.
dkarl 4y ago
For code modularity to serve the same purpose, I think there needs to be explicit language-level support, because on a medium-sized or larger project, when the modularity exists only in the minds of developers, it might as well not exist at all. You need virtually all of your developers to understand the design and respect the seriousness of violating it, and beyond a certain project size, that isn't possible. Developers do a much better job with microservices. I think it's easy for them to respect the seriousness of designing and changing the API of a microservice. In contrast, they often don't respect or even realize the seriousness of making a change that affects the modular design of code. Language-level support for defining and enforcing module interfaces might help developers invest the same level of care for module boundaries in a modular monolith as they do in a microservices architecture, but I've yet to work in a language that achieves this.
- JAlexoid 4y ago
  You would hope so... but it's not necessarily the case. Often people are too lazy to issue API version change on a "bugfix", and take down multiple applications. Funny thing, a modularized monolith may have identified some of those issues.

LAC-Tech 4y ago

Off topic, but 70s computing papers are just the best aren't they?

regularfry 4y ago

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.

dkarl 4y ago

For code modularity to serve the same purpose, I think there needs to be explicit language-level support, because on a medium-sized or larger project, when the modularity exists only in the minds of developers, it might as well not exist at all. You need virtually all of your developers to understand the design and respect the seriousness of violating it, and beyond a certain project size, that isn't possible. Developers do a much better job with microservices. I think it's easy for them to respect the seriousness of designing and changing the API of a microservice. In contrast, they often don't respect or even realize the seriousness of making a change that affects the modular design of code. Language-level support for defining and enforcing module interfaces might help developers invest the same level of care for module boundaries in a modular monolith as they do in a microservices architecture, but I've yet to work in a language that achieves this.

JAlexoid 4y ago
You would hope so... but it's not necessarily the case. Often people are too lazy to issue API version change on a "bugfix", and take down multiple applications. Funny thing, a modularized monolith may have identified some of those issues.