Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

281–290 of 671 posts

Re: Modules, not microservices

#281

Post by zbobet2012 »

lifeisstillgood wrote: post #267
barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

I think it runs a bit deeper than that. Microservices are how the business views its self. Look, once upon a time managers designed the system that workers implemented. The factory assembly line, or the policy manual. But now the workers are CPUs and servers. The managers designing the system the workers follow are coders . I say coders are the new managers. Now this leaves two problems. The first is that there are a…

> there is no need to have the microservices built along Conways Law

This is a misunderstanding of Conway's Law. Your code _will_ reflect the structure of your organization. If you use microservices so will their architecture. If you use modules, so will the modules.

If you want a specific architecture, have your organization reflect the modules/microservices defined in that architecture.

Re: Modules, not microservices

#282

Post by hinkley »

je42 wrote: post #193
strictfp wrote: post #154

Earlier quoted context omitted.

This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components. What happens if you need to redesign the architecture to meet new needs? That's right; it's not going to happen, because people will fight it tooth and nail. You also cannot produce any meaningful end-user value without involving several teams. Microservices is just "back…

Conways law: Tech follows communication patterns (.i.e org setup) hence, if you want a certain architecture, you likely need to execute a "reverse conway law" org first. To get the org into the target config, the software will follow.

It’s okay for one team to have several logical units of code. In fact from a Conway First model, it’s helpful because it allows horse trading when it turns out the team competencies don’t match responsibilities very well. I’m not dismantling my team, I’m just transferring module ownership to another team.

What does not work is splitting ownership of many tings for a long time. It’s too many plates to spin. But some things can be shared by a few people without tipping over into anarchy.

Re: Modules, not microservices

#283

Post by swsieber »

nonethewiser wrote: post #79
sbergot wrote: post #37

Earlier quoted context omitted.

I disagree with this stance. Creating a file and naming it gives it a purpose. It creates a unit of change that tools like git can report on.

A line is a unit of change that git can report on. If it's a separate file that is scoped to some specific concern, sure. But its tgat grouping by concern that is key. Not separation into another file. Extracting ra dom bits of code into separate files would be _worse_.

> A line is a unit of change that git can report on.

Yes and no.

Git doesn't store lines, it stores files. Git diff knows how to spit out line changes by comparing files.

So to run git blame on a 10k line file you're reading multiple versions of that 10k file and comparing. It's slow. Worse still is that trying to split said file up while trying to preserve history won't make the git blame any faster.

Re: Modules, not microservices

#284

Post by wruza »

Pamar wrote: post #133
wruza wrote: post #122

Earlier quoted context omitted.

Would be interesting to learn how your (or any other) team defines borders of a microservice. Iow, how “micro” they are and in which aspect. I guess without these details it will be hard to reason about it. At my last job we created a whole fleet of microservices instead of a single modular project/repo. Some of them required non-trivial dependencies. Some executed pretty long-running tasks or jobs for which network…

Did you have a common, centralized data store or did each and every microservice manage their own instance? (Because this is at the same time one of the defining elements of this architecture... and the first one to be opted out when you actually start using it "for real").

Yes and no. The "central" part of data flowed naturally through services (i.e. passed in requests and webhooks, not in responses). Microservices maintained local state as well, though it was mostly small and disposable due to whole-intra crashonly design. For example, we didn't hesitate to shut something down or hot-fix it, except for bus-factor periods when there's only few of them. They could also go down by themselves or by upstream, and routers avoided them automatically.

Re: Modules, not microservices

#285

Post by dkarl »

regularfry wrote: post #201
treis wrote: post #170

Earlier quoted context omitted.

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…

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

Re: Modules, not microservices

#287

Post by hbrn »

osigurdson wrote: post #118
surprisetalk wrote: post #31

Earlier quoted context omitted.

Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files? And why do you think the overhead of maintaining the extra code for module boundaries is worth it? EDIT: And what editor do you use? I'm wondering if a lot of these differences come down to IDEs haha

The right answer is 20 files with 500 lines in each - i.e. few pages of clean/ readable/logical/well-factored code. Obviously it depends on the code itself - it's is fine to have longer files if highly correlated. Stateful classes should be kept short however as the cognitive load is very high. I also find that updating code to take advantage of new/better language features / coding styles, etc. is impossible to do o…

The right answer is that there is no right answer. You shouldn't divide your code based on arbitrary metric like size, you should divide it based on concepts/domains.

If a particular domain gets big enough it probably means it contains sub-domains and can benefit from being divided too. But you cannot make that decision based on size alone.

Re: Modules, not microservices

#288

Post by dilyevsky »

pjmlp wrote: post #241
barrkel wrote: post #225

Earlier quoted context omitted.

Services generally have a stateless request/response architecture, inherited from the success of HTTP, and contra the experiences of CORBA and COM, the latter being much better suited to Office Object Linking and Embedding and VB visual controls - local, assumed reliable, not across a network boundary. Creating an object-oriented API for a shared library which encapsulates a module to the degree a service boundary wo…

So much for the theory, most services I see in the wild are stateful. As for scalability, most orgs aren't Facebook nor Google scale, regardless of how much they want it to be true. All of those issues can be tackled, when proper architecture design is done, instead of coding on the go and then will see attitude.

People keep regurgitating this “you aint going to be google” mantra but I worked there and in reality generic microservice stack is in a totally different league of complexity and sophistication of what google and co have. This argument is basically reductio ad absurdum

Re: Modules, not microservices

#289

Post by vsareto »

kubb wrote: post #40
surprisetalk wrote: post #2

I suspect that most people would be better off favoring inlined code over modules and microservices. It's okay to not organize your code. It's okay to have files with 10,000 lines. It's okay not to put "business logic" in a special place. It's okay to make merge conflicts. The overhead devs spend worrying about code organization may vastly exceed the amount of time floundering with messy programs. Microservices aren'…

Respectfully, rants by niche celebrities are not something we should base our opinions on. If you're a single dev making a game, by all means, do what you want. If you work with me in a team, I expect a certain level of quality in the code you write that will get shipped as a part of the project I'm responsible for. It should be structured, tested, malleable, navigable and understandable.

>It should be structured, tested, malleable, navigable and understandable.

People have different thresholds for when their code reaches these states though, especially "understandable".

You can meaningfully define these (and test for them) on a small scale, in a team, but talking about all developers everywhere, these are all very loosely defined.

Re: Modules, not microservices

#290

Post by zrail »

systems_glitch wrote: post #158
c-fe wrote: post #73

I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attem…

I agree that monoliths are the way to start many times, especially if you're not actually sure you'll ever need to scale. One reason we do sometimes plan on microservices from the start with projects is separation of security concerns. Easier to lock a public-facing microservice down tight and have what's ostensibly a non public-facing monolith call out to it. Lots of ways to solve a problem, though.

Yeah, I think this is one of the very few places where splitting out something as a microservice makes sense. For example, you (mostly) never want to open/process/examine/glance at user-provided PDFs on a box with any sort of unfiltered network access. Ideally you do what you need to do within a sandbox that has _no_ network access, but that's really hard to do performantly.

The primary reason for this is that PDFs can contain executable code and the common tools used to process them are full of unpatched CVEs.

Post reply on HN