Hacker News Reader

Comment by kpmah | Hacker News Reader

IMO this is a confused take on modularity. I think isolation and security are related concepts, but not what modules are for. Those things have to follow module boundaries, but they're not the goal of modules. For me, modules are about understanding; in order to use this code you don't need to read all of it, you just need to understand the interface. Modularity is for humans, not computers.

They do often follow Conway's law, but that's not a desirable thing. Most modules are outside of that kind of context -- they're in libraries written by people you don't communicate with at all!

I'm interested in people's opinion here. I'm also planning an article on the relationship between services and modularity.

View on HN

> IMO this is a confused take on modularity.

You are restricting the scope of what we call a “module” to language runtime modules while the OP has expanded the scope to include things like network tiers and processes with an IPC interface.

I found the OP's perspective both new and useful.

Yeah, that and the author made it clear in the opening paragraph that that they are viewing "modularization" from a Systems Design point-of-view and not software engineering per se.

I think what I'm trying to say is that my definition of a module as a "unit of encapsulation or understanding" is the more inclusive and general one, as it includes network and process boundaries. The OP's use of the word is the restrictive one because it excludes language-level modules. I say this because security and isolation are not typically goals of language-level modules.

This is fine to talk about, of course. It's just confusing to reconcile the article with my definition of modules, which I thought to be the common one.

Naming things is hard. My purpose was to emphasize the need to juggle the two definitions when assessing the article. We need a better word for the deployable unit of code that the OP calls a “module".

“Component” might fit the bill.

In some languages, like Modula-2, modules and libraries are exactly the same unit of measure.

You just don't group multiple modules into a single library.

Well you kind of can with sub-modules, but at the end of the day the binary library is generated exactly the same way.

I think that's more or less the author's point as well. Modularity has some overlap w/ security (in the sense that we need stronger forms of modularity to get stronger forms of privilege isolation), but many of the other benefits of modularity that are usually the justification for adopting micro-services can be achieved through forms of modularity that assume trust (i.e. libraries, and other means of code splitting that may be bundled into a single unit of deployment).

Modules make it easier to understand software. Yet what is "security" but understandability? Modularity brings about understandability. And understandability brings security.

Software threats arise from the fact that coders don't in fact fully understand everything the software is doing, how it makes it impossible or possible for hackers to gain unauthorized access.

If we understood the software perfectly we could easily and quickly remove vulnerabilities from it. And if we understand its limitations we wouldn't let it run a commercial airline on auto-pilot.

> Yet what is "security" but understandability?

I prefer to think of security as the opposite of functionality: increasing functionality makes more things possible, increasing security makes fewer things possible.

I like this view because it forces us to acknowledge the tradeoff: the most functionality we can provide is a root shell with no passwords; the most security we can provide is an inert brick; we need to be specific about what functionality should be provided, what shouldn't, and design a system which sits between the two.

From this perspective, modularity can increase security by preventing one module from accessing/executing unexported parts of another module. Yet this implies that modularity also reduces functionality, for exactly the same reason. Again, we need to specify what should be exported, what shouldn't, and implement something between the two.

Is following Conway's law a bad thing, though? If the module is written/maintained by a single person, it seems to be more efficient and clear (of course subject to skill limitations of that particular human). What realistic alternative is there to Conway's law? Design by committee?

Conway's law might as well be, like democracy, the best of all the bad worlds.

Specifically in the context of modules, I think it is a bad thing. It's hard to describe because I do it quite intuitively, but (very broadly) the way I find module boundaries is by trying to find the minimal interface for the maximal amount of code. For me, this usually revolves around some kind of data structure.

Importantly, this is completely independent of team structure. The boundaries between teams are not necessarily the minimal interface.

Are the modules you're thinking of heavily shared/shaped by the needs of others? I think it's fair to say that there are more influences than just communication patterns on the design of software. For instance, there's can be a different set of concerns/pressures on developers of open source libraries than on time-sensitive and closely coordinated projects within a company.

> The boundaries between teams are not necessarily the minimal interface.

No, but they are the inevitable interface.

>Is following Conway's law a bad thing, though

Is following the second law of thermodynamics a bad thing? I say so jokingly because thermo is a little more rigid, but I still think it's futile to fight Conway. After all, if you change your org structure to try to beat it, you're actually proving it.

It's not something to beat as much as it's something to inform decisions. Code should be architected with knowledge of how the organization is broken up, and orgs should be structured with knowledge of how that affects the technical side.

I guess all this is to agree with you and say...if breaking up modules in a certain way for small teams is effective for your organization, then it makes sense to do it.

To add to that, I think the biggest thing to take away from Conway's law is that splitting teams of developers becomes a technical problem. If your goal is to efficiently build a product, technical expertise needs to go into that decision.

This is why I say Conway's law is a bad thing for modules (regardless of how inevitable it is): technical considerations are often not taken into account, and technical design is ossified by team structure.

Same, the whole tirade about sandbox escalation and other security aspect is of course a violation of isolation, but it's not particularly related to modularization.

Microservices and the like are not about isolating code, are about isolating responsabilities within code first.

The concerns expressed are valid, but the premise they move from are weird. Privilege escalation is a problem both in monoliths and micro services. People figuring out encryption keys from timing attacks is about the same threat both for micro services and monoliths.

also, for such a long article, I find it weird that not once the session management, authorization, and relation integrity topics are mentioned, while schema versioning gets touched but not interface versioning, as if the suggestion is to make modules talk to each other by touching each other data.

Some of the connective tissue in this article could have been better written, but I think the point of talking about isolation from a security perspective is this:

A. Privilege isolation is the hardest to refute benefit of microservices in theory, but you have to keep in mind that we need hardware virtualization to achieve a reasonably strong form of that (i.e. your k8s cluster isn't helping you out here, modulo Fargate perhaps)

B. This is rarely the primary concern when we look to microservices (or generally, modularity) to cure what ails us.

C. If we have less concern about trust boundaries, there are easier ways of modularizing code that probably solve the things we're really worried about (i.e. libraries or any other way of splitting code that is built into a single artifact).

Reply on news.ycombinator.com