Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#111

Post by [deleted] » Tue, Jan 03, 2023, 1:45 PM UTC

ReflectedImage wrote: post #101

Pamar wrote: post #44

The article above, and most if not all the comments I read right before posting this, seem to be very quiet about what I thought was one of the main "distinctive elements" of Microservices. I.e. the idea that each microservice has direct access to its own, dedicated, maybe duplicated storage schema/instance (or if it needs to know, for example, the country name for ISO code "UK" it is supposed to ... invoke another m…

The distinct elements are they compile separately and have versioning on their API calls. No, you don't use separate microservices for writing out that text message. The idea is pretty simple instead of writing one big program, you write many smaller programs. It's useful around the 3 to 4 separate developers mark. It avoids you having to recompile for any minor change, allows you run the tests for just the part you…

[deleted]

Re: Modules, not microservices

#112

Post by [deleted] » Tue, Jan 03, 2023, 1:45 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…

[deleted]

Re: Modules, not microservices

#113

Post by Ensorceled » Tue, Jan 03, 2023, 1:46 PM UTC

goodoldneon wrote: post #93

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

I'm assuming that those services don't actually NEED to be in a separate data centre ...

Re: Modules, not microservices

#114

Post by zeroxfe » Tue, Jan 03, 2023, 1:47 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…

Both Modularization and Microservices solve scaling problems.

Modularization allows development to scale.

Microservices allow operations to scale.

Re: Modules, not microservices

#115

Post by regularfry » Tue, Jan 03, 2023, 1:47 PM UTC

Pamar wrote: post #44

The article above, and most if not all the comments I read right before posting this, seem to be very quiet about what I thought was one of the main "distinctive elements" of Microservices. I.e. the idea that each microservice has direct access to its own, dedicated, maybe duplicated storage schema/instance (or if it needs to know, for example, the country name for ISO code "UK" it is supposed to ... invoke another m…

They solve specific problems. If they don't solve a problem you have, then using them is probably a mistake.

The thing is that the framing of "the problems we use computers for" misses the entire domain of problems that microservices solve. They solve organisational problems, not computational ones.

Re: Modules, not microservices

#116

Post by em500 » Tue, Jan 03, 2023, 1:48 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 is it generally easier to read and understand, say 10 files of 1000 lines or 100 files of 100 lines or 1000 files of 10 lines, compared to one 10,000 lines file? (I don't know the answer, and don't have any strong opinion on this.)

Re: Modules, not microservices

#117

Post by orose_ » Tue, Jan 03, 2023, 1:49 PM UTC

Conway's law

Re: Modules, not microservices

#118

Post by osigurdson » Tue, Jan 03, 2023, 1:50 PM UTC

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

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 on a large code base at once. However, sprinkling these kind of things randomly leads to too much inconsistency. A reasonable sweet spot is to make each file self-consistent in this regard.

My experience stems from larger 500+ person-year projects with millions of lines of code.

Re: Modules, not microservices

#119

Post by lucasfcosta » Tue, Jan 03, 2023, 1:50 PM UTC

Couldn’t agree more.

The way I usually describe my preferred heuristic to decide between modules and microservices is:

If you need to deploy the different parts of your software individually, and there’s a cost of opportunity in simply adopting a release train approach, go for microservices.

Otherwise, isolated modules are enough in the vast majority of cases.

Re: Modules, not microservices

#120

Post by Pamar » Tue, Jan 03, 2023, 1:50 PM UTC

ReflectedImage wrote: post #101

Pamar wrote: post #44

The article above, and most if not all the comments I read right before posting this, seem to be very quiet about what I thought was one of the main "distinctive elements" of Microservices. I.e. the idea that each microservice has direct access to its own, dedicated, maybe duplicated storage schema/instance (or if it needs to know, for example, the country name for ISO code "UK" it is supposed to ... invoke another m…

The distinct elements are they compile separately and have versioning on their API calls. No, you don't use separate microservices for writing out that text message. The idea is pretty simple instead of writing one big program, you write many smaller programs. It's useful around the 3 to 4 separate developers mark. It avoids you having to recompile for any minor change, allows you run the tests for just the part you…

No, you don't use separate microservices for writing out that text message.

But in order to find out that Genua is the name of the port from where the cruise is departing, the appropriate time (converted to the timezone of the port, or the timezone of the client who will see this message, depending on what business rule you want to apply) and that Genua is in IT=Italy... how many microservices do I have to query, considering that port data, timezones, ISO country codes and dep.date/time of the cruise are presumably managed on at least four different "data stores"?