Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#151

Post by guywhocodes » Tue, Jan 03, 2023, 2:13 PM UTC

BackBlast wrote: post #134

leidenfrost wrote: post #123

I think most criticisms around microservices are about good practices and skills beating microservices in theory. And the virtue of microservices is that they create hard boundaries no matter your skill and seniority level. Any unsupervised junior will probably dissolve the module boundaries. But they can't simply dissolve the hard boundary of having a service in another location.

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors from coupling your modules, perhaps it's worth it. But there are more efficient ways to build and run an engineering organization. The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices…

Are organizations ever capable of enforcing coding standards even remotely close to that of what microservices _should_ provide? Because I have not seen it.

However this is muddied by the fact that I almost never see microservices, I see a lot of distributed monoliths tho.

Re: Modules, not microservices

#152

Post by onehair » Tue, Jan 03, 2023, 2:13 PM UTC

> At the heart of microservices, we're told we'll find...

Well, in our +20 product teams with all serving different workflows for 3 different user types, the separate micro services are doing wonders for us for exactly the things you've listed.

My comment should just stop here to be honest.

Re: Modules, not microservices

#153

Post by mbork_pl » Tue, Jan 03, 2023, 2:13 PM UTC

hgsgm wrote: post #21

mbork_pl wrote: post #13

Earlier quoted context omitted.

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

grep can search multiple files. Tags can jump between files. LaTeX is an obvious case: why pay to recompile the whole huge project, for each tiny change?

Actually, LaTeX has to recompile everything even after a tiny change (there are rare exceptions like TikZ, which can cache pictures, but even then it can put them into some file on its own AFAIR, so that I can still have one big file).

Now that I think about it, LaTeX is a very bad analogy anyway, since LaTeX documents usually have a very linear structure.

Re: Modules, not microservices

#154

Post by strictfp » Tue, Jan 03, 2023, 2:14 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…

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 "backend, frontend, and database team" reincarnated.

My take: do Microservices all you want, but don't organize teams around the services!

Re: Modules, not microservices

#155

Post by louthy » Tue, Jan 03, 2023, 2:14 PM UTC

worldsayshi wrote: post #150

louthy wrote: post #145

Earlier quoted context omitted.

> I think we are conflating (at least) two different issues For sure, I have absolutely no idea how your comment relates to what I wrote.

Oops, it looks like I answered the wrong comment here. :/

It happens to the best of us! :)

Re: Modules, not microservices

#156

Post by mbork_pl » Tue, Jan 03, 2023, 2:15 PM UTC

speed_spread wrote: post #82

mbork_pl wrote: post #13

Earlier quoted context omitted.

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

Well, Git is pretty good at merging when the changes are in different places of the same file. Though your second point is a very good one.

FWIW, sometimes when I worked on a really large file, I put some ^L's ("new page" characters) between logical sections, so that I could utilize Emacs' page movement commands.

Re: Modules, not microservices

#157

Post by maxrev17 » Tue, Jan 03, 2023, 2:15 PM UTC

I've sadly never seen micros achieve the purported benefits. All I've seen is problems. Monolith, or a set of distinct systems which are owned by teams with little to no blur (just agreed contracts), anything else gets painfully messy and you'd have been better with code modules.

Re: Modules, not microservices

#158

Post by systems_glitch » Tue, Jan 03, 2023, 2:16 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…

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.

Re: Modules, not microservices

#159

Post by unwind » Tue, Jan 03, 2023, 2:17 PM UTC

regularfry wrote: post #128

mpweiher wrote: post #92

Earlier quoted context omitted.

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

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

Here I guess BDUF = big design up front.

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

Re: Modules, not microservices

#160

Post by mbork_pl » Tue, Jan 03, 2023, 2:18 PM UTC

beefield wrote: post #17

mbork_pl wrote: post #13

Earlier quoted context omitted.

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

Because one day someone else may need to read and understand your code?

But this is precisely my question: in what way does splitting the code into many small files help with that? Personally I find jumping between many files (especially when they are located in various directories on various levels in the fs) pretty annoying...

Of course, that probably depends on the nature of the project. Having all backend code of a web app in one file and all the frontend code in another would be very inconvenient. OTOH, I have no problems with having e.g. multiple React components in one file...