Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#91

Post by dist1ll » Tue, Jan 03, 2023, 1:37 PM UTC

This article is all over the place. The author acknowledges that microservices are about organizational clarity, then writes "In theory, anyway" without elaboration, and then goes on to talk about the latency impact of network-level IPC.

Why do we care about network latency, when we JUST established that microservices are about scaling large development teams? I have no problem with hackers ranting about slow, bloated and messy software architecture...but this is not the focus of discussion as presented in the article.

And then this conclusion:

> The key is to establish that common architectural backplane with well-understood integration and communication conventions, whatever you want or need it to be.

...so, like gRPC over HTTP? Last time I checked, gRPC is pretty well understood from an integration perspective. Much better than Enterprise Java Beans from the last century. Isn't this ironic? And where are the performance considerations for this backplane? Didn't we criticize microservices before because they have substandard performance?

Re: Modules, not microservices

#92

Post by mpweiher » Tue, Jan 03, 2023, 1:37 PM UTC

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…

> 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

Re: Modules, not microservices

#93

Post by goodoldneon » Tue, Jan 03, 2023, 1:38 PM UTC

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…

If the services need to be in separate data centers then how would a monolith be a solution? Monoliths can't span data centers

Re: Modules, not microservices

#94

Post by CraigJPerry » Tue, Jan 03, 2023, 1:38 PM UTC

jiggawatts wrote: post #60

CraigJPerry wrote: post #33

Earlier quoted context omitted.

Counter point - https://github.com/microsoft/TypeScript/blob/main/src/compil... - your task is to just make it a little bit faster. Where do you begin with a 2.65mb source file? It’s easy to miss the point of what the OP is saying here and get distracted by the fact this file is ridiculously huge. This file used to be a paltry 1k file, a 10k file, a 20k SLOC file… but it is where it is today because of the OP suggest…

> your task is to just make it a little bit faster. Where do you begin With a trace from a profiler tool, which will tell you which line number is the hot spot. If run from any modern IDE, you can jump to the line with a mouse-click. In essence, the file boundaries ought not to make any difference to this process.

>> In essence, the file boundaries ought not to make any difference to this process.

I find this the strongest counter argument. File boundaries shouldn’t matter - but in practice they do.

The ide will give up doing some of its analysis because this is not an optimised use case, the IDE vendors don’t optimise for it. Some IDEs will even give up just simple syntax highlighting when faced with a large file, never mind the fancy line by line annotations.

Re: Modules, not microservices

#95

Post by robertlagrant » Tue, Jan 03, 2023, 1:38 PM UTC

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…

Some of the services not being in the same datacentre seems orthoganal. If that solves a problem you have, wouldn't it still be an issue in a non-microservices design?

Re: Modules, not microservices

#96

Post by ash » Tue, Jan 03, 2023, 1:39 PM UTC

CraigJPerry wrote: post #33

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'…

Counter point - https://github.com/microsoft/TypeScript/blob/main/src/compil... - your task is to just make it a little bit faster. Where do you begin with a 2.65mb source file? It’s easy to miss the point of what the OP is saying here and get distracted by the fact this file is ridiculously huge. This file used to be a paltry 1k file, a 10k file, a 20k SLOC file… but it is where it is today because of the OP suggest…

Where do you begin if the code was in hundreds of separate modules? It's not clear if it's easier. It would take time to load the code into your brain regardless of the structure.

By the way, JavaScript parser in esbuild is a 16 thousand lines of code module too:

https://github.com/evanw/esbuild/blob/0db0b46399de81fb29f6fc...

Re: Modules, not microservices

#97

Post by daitangio » Tue, Jan 03, 2023, 1:39 PM UTC

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…

Totally agree. Also microservices shines IF you need different release schedule for two services. If they are managed in the same project/team, the effort you pay is high, the advantage could not pay your bill, so be careful in such scenario.

Re: Modules, not microservices

#98

Post by LeonM » Tue, Jan 03, 2023, 1:39 PM UTC

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…

> one of the unexpected consequences is that we are now doing a lot of network calls between these microservices

Not trying to be harsh here, but not expecting an increase of network call in a system where each component is tied together with... network calls sounds a bit naive.

> We are now attempting to solve this with caches and doing batch requests

So you have built a complex and bottle-necked application for the sake of scalability, then having to add caching and batching just to make it perform? That sounds like working backwards.

Obviously, I have no clue on the scale of the project you are working on, but it sure sounds like you could have built it as a monolith in half of the time with orders of magnitude more performance.

Scalability is a feature, you can always add it in the future.

Re: Modules, not microservices

#99

Post by arkh » Tue, Jan 03, 2023, 1:39 PM UTC

padjo wrote: post #86

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 don’t mean to be snarky but how is that an “unexpected consequence”? Were the pros and cons just never considered when deciding to use micro services? Additional networks calls are one of the most obvious things to go on the cons list!

Someone must have read a blog post about microservice and decided it would look good on their resume.

Re: Modules, not microservices

#100

Post by danabrams » Tue, Jan 03, 2023, 1:39 PM UTC

This article nails it, but I still like microservices because I’ve yet to see a team doing a modular architecture in memory keep from creating a spaghetti mess of interdependence.

Yes, the same often happens in microservices, but the extra complexity of a distributed system provides a slightly stronger nudge to decouple that means some teams at the margin do achieve something modular.

I’m something of a skeptic on modular monoliths until we as an industry adopt practices that encourage decoupling more than we currently do.

Yes, in theory they’re the same as microservices, without the distributed complexity, but in practice, microservices provide slightly better friction/incentives to decouple.