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

81–90 of 671 posts

Re: Modules, not microservices

#81

Post by Olreich »

hgsgm wrote: post #6
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'…

Blow and Carmack are game programmers. They are brilliant, but their local programs and data are tiny compared to distributed systems over social graphs, where N^2 user-user edges interact.

Their programs interact with different APIs and constraints on many different sets of hardware. 5 different major hardware targets, 8 operating systems, and hundreds of versions of driver software. It’s hard to do all that well and keep things validated to continue running with minimal ability to update and support it. Web programs barely work on two browsers. Server targets are generally reduced to a single target (Docker or a specific distribution of Linux).

Their tiny data is rendering millions of polygons with real-time lighting, asset loading in the background, low latency input handling, etc. at 60fps+. If my API responds to the user in 100ms, they’re ecstatic. If their game responds to the user in 100ms (5-10 dropped frames) even a few times, they’re likely to ask for a refund or write a bad review, hurting sales.

The constraints are different, but game programmers do the same kinds of optimization social networks do, just for different problems. They avoid doing the N^2 version of lighting, path finding, physics simulations, etc. Social networks avoid it when searching through their graphs.

I think the web and other big tech companies should try thinking about problems the way game programmers do.

Re: Modules, not microservices

#82

Post by speed_spread »

mbork_pl wrote: post #13
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'…

> It's okay to have files with 10,000 lines. Ever since my time as a mathematician (I worked at a university) and using LaTeX extensively, I never understood the "divide your documents/code into many small files" mantra. With tools like grep (and its editor equivalents), jumping to definition, ripgrep et al., I have little problem working with files spanning thousands of lines. And yet I keep hearing that I should di…

One big reason is source control. Having many smaller files with well defined purpose reduces the number of edit collisions (merges) when working in teams.

Also, filenames and directories tree act as metadata to help create a mental map of the application. The filesystem is generally well represented in exploratory tools like file browser and IDE. While the same information can be encoded within the structure of a single file, one needs an editor that can parse and index the format, which may not be installed on every system.

Re: Modules, not microservices

#83

Post by regularfry »

CraigJPerry wrote: post #43

You want to get away from sweeping generalisations because once the build/test/package/deployment tax of a modules approach bites, you do want to go monorepo microservices - it’s free clawback of time wasted building and deploying all the parts of a huge system that you didn’t change in your PR.

The fundamental generalisation that does hold is that you never want another team on your route to production.

Re: Modules, not microservices

#84

Post by jraph »

dmitriid wrote: post #64
jraph wrote: post #19

Earlier quoted context omitted.

I actually use ripgrep. But modules can be in different repositories I haven't cloned yet.

Just use a proper IDE. It doesn't care about how your code is structured and can easily show you what you look for in context . (And other tools like symbol search https://www.jetbrains.com/help/idea/searching-everywhere.htm... )

and it also does not magically guess what is in modules you haven't fetched yet. (I use LSP when I can)

Re: Modules, not microservices

#85

Post by beagle3 »

mcculley wrote: post #34

You don’t have to necessarily decide one way or the other. I have systems where the decision to put the module in the same process or to call it via RPC is done at runtime. Java’s dynamic proxies help with this, but it can be done in any language. The only downside is that one has to think about the size of messages crossing the API and that they need to be immutable values, not references to something in the process…

There is another downside, much more problematic in my experience - the failure modes of a distributed system (even over multiple processes in the same machine) are very different. The other process might be killed by OOM manager, user initiated kill signal, or a bug. All of a sudden, asking an object for its string identifier xyz.Name() becomes a possibly failing operation even though it succeeded a microsecond ago.

Re: Modules, not microservices

#86

Post by padjo »

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!

Re: Modules, not microservices

#87

Post by mattbrewsbytes »

I think a lot of microservices are defined as separate apps and code repositories. This sounds good for initial build and deployment but the long term maintenance is the issue. Developers like the idea of independence of other teams writing parts of the overall solution but that trade-off can mean a lot of overhead in maintaining different code repositories of the same stack.

When a critical vulnerability comes out for whatever language you are using, you now have to patch, test and deploy X apps/repos vs much fewer if they are consolidated repositories written modularly. Same can be said for library/framework upgrades, breaking changes in versions, deprecated features, taking advantage of new features, etc.

Keeping the definition of runtimes as modular as the code can be instrumental in keeping a bunch of related modules/features in one application/repository. One way is with k8s deployments and init params where the app starts specific modules which then lends itself to be scaled differently. I'm sure there are home-grown ways to do this too without k8s.

Re: Modules, not microservices

#88

Post by nonethewiser »

surprisetalk wrote: post #31
SomeoneOnTheWeb wrote: post #14

Earlier quoted context omitted.

I strongly disagree on this one. 10+K lines files are absolutely unreadable most of the time. Separating business logic than other parts of the application helps maintaining it and making everything evolve in parallel, without mixing things up. It also helps to clearly see where business logic happens.

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

> Honest question: do you think the same exact 10+K lines of code are easier to read spread across 1,000 files?

This is a fair point but assumes 1 particular use case. It is easier if you are just concerned with a bit of it. If you need to deal with all of it, yeah, good fucking luck. 10k LOC file or 1k 100 LOC files.

Re: Modules, not microservices

#89

Post by regularfry »

wodenokoto wrote: post #23

I’m surprised none of the big 3 cloud providers have come out with a cloud native language where modules or even classes gets deployed as micro services that scales horizontally. Then you can have a mono repo that deploys to multiple micro services / cloud functions / lambdas as needed depending on code changes and programmers don’t have to worry about RPC or json when communicating between modules and can just call…

I've said this from the start: cloud functions should be a compilation target, not directly developer-facing. Cut out the monorepo middleman.

Re: Modules, not microservices

#90

Post by ElectricalUnion »

struggle2 wrote: post #75
anankaie wrote: post #58

Ideally, What I want is the ability to decide later whether a particular call should be local, or RPC, and I should not have to care about any of it until I need to start scaling. I should also not need to specify locally what is going on - my reference infrastructure should handle turning the call into a jump-call or a net-call. Ideally, the fiber system that simulates multithreading for me should have an extensibil…

Ideally yes. But there are two major differences between a local and a remote call: 1) A remote call – inherently – fail. However, some local calls never fail. Either because they are designed to never fail or because you have done the required checks before executing the call. A remote call can fail because the network is unreliable and there is no way around that (?). 2) A remote call – inherently – can be very slo…

The cool part about "some local call never fails" is that because of scale out, out-of-order multi-threaded execution, is that even "local calls" (for some definitions of local) can fail as your preconditions get invalidated in other threads, unless you're employing mutexes/barriers.

Those modern computers are a network mesh of small D/G/CPUs, and it's coming back to bite us sometimes.

Post reply on HN