Hacker News Reader

Comment by regularfry | Hacker News Reader

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.

View on HN

Here I guess BDUF = big design up front.

Edit: failed to spell "I" correctly. Ouch.

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

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.

Same thing with microservices, unless you do a blue green deployment, have a planned shutdown, load balancer in between releases,...

The key word is "independently".

There is no independently in distributed systems.

You can't solve the halting problem either, and yet somehow useful work gets done.

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.

Unless there is infrastructure in place good luck replicating those dropped requests as services are replaced.

Infrastructure that someone has to take care of.

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.

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).

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.

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.

>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.

> 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.

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.

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.

Reply on news.ycombinator.com