Modules, not microservices • Hacker News Board

Re: Modules, not microservices

#341

Post by philippejara » Tue, Jan 03, 2023, 5:15 PM UTC

lightbendover wrote: post #250

gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

> they force alignment on one language or at least runtime How is this possibly a down-side from an org perspective? You don't want to fracture knowledge and make hiring/training more difficult even if there are some technical optimizations possible otherwise.

>You don't want to fracture knowledge and make hiring/training more difficult

these are not maxims of development, there can be reasons that make these consequences worth it. Furthermore you can still use just a single language with microservices*, nothing is stopping you from doing that if those consequences are far too steep to risk.

*:you can also use several languages with modules by using FFI and ABIs, probably.

Re: Modules, not microservices

#342

Post by therealdrag0 » Tue, Jan 03, 2023, 5:15 PM UTC

gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

I used to be monolith-curious, but what sold me on micro-services is the distribution of risk. When you work for a company where uptime matters having a regression that takes down everything is not acceptable. Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

Re: Modules, not microservices

#343

Post by karamanolev » Tue, Jan 03, 2023, 5:18 PM UTC

marcosdumay wrote: post #214

karamanolev wrote: post #24

Earlier quoted context omitted.

I'm inbetween. 10K line files are usually extremely messy, but they can be written not to - a large number of well-organized, well-capsulated Same for business logic - very clear separation can be cumbersome sometimes, but otherwise it becomes messy if you're not careful. And careful people just tend to separate it.

It varies a bit with language and tooling, but 10k lines is around the place where the size of your file by itself becomes a major impediment on finding anything and understanding what is important. A 10k lines file is not something that will completely destroy your productivity, but it will have an impact and you'd better look out for it growing further, because completely destroying your productivity is not too far…

I generally agree. My argument is that 10K lines written one way can certainly be more readable than 10 files x 1K lines written in a different way, so the real differentiator is the encapsulation and code style, not KLOC/file per se.

Re: Modules, not microservices

#344

Post by discussDev » Tue, Jan 03, 2023, 5:18 PM UTC

There is a time and place but as soon as you have a few teams that build thigns differently or someone wants to upgrade how things are done on a very big project you will wish you used services instead of modules.

Re: Modules, not microservices

#345

Post by college_physics » Tue, Jan 03, 2023, 5:18 PM UTC

After scanning 300+ comments my conclusion is that not only there is no conclusion in this debate, there is no discernible framework that would help generate a conclusion

Most likely the question is not well defined in the first place.

Re: Modules, not microservices

#346

Post by stephenhuey » Tue, Jan 03, 2023, 5:23 PM UTC

beastcoast wrote: post #298

lightbendover wrote: post #234

Earlier quoted context omitted.

Amazon is a good example of a huge organization absolutely crippled by micro-service fiefdoms driven by sr.mgr whims and not strong technical guidance from such PEs.

Depends entirely on the org. My org actually broke SOA (thousands of services and some intense technical debt) and is now in a years long process of moving toward a centralized service orchestration model. This couldn’t have happened without PE, Sr PE and DE involvement.

Now that sounds interesting. I assume you're not counting each API endpoint as a service, so can you shed any more light on this? The scale sounds mind-boggling. Thousands of separate services being pulled (more) together. Can you give an idea of the size or scope of these services?

Re: Modules, not microservices

#347

Post by bfeynman » Tue, Jan 03, 2023, 5:23 PM UTC

arsenico wrote: post #262

hbrn wrote: post #238

Earlier quoted context omitted.

> What happens if you need to redesign the architecture to meet new needs? How often does major reorganization happen? For most companies the answer is never. The "what if" argument is what leads to all sorts of premature optimizations.

> How often does major reorganization happen? For most companies the answer is never. For most companies – regularly.

reorgs usually happen higher up the tree in larger companies, been through a bunch and its never affected any part of our work.

Re: Modules, not microservices

#348

Post by treis » Tue, Jan 03, 2023, 5:24 PM UTC

MuffinFlavored wrote: post #322

zeroonetwothree wrote: post #317

Earlier quoted context omitted.

The way it usually works, if 1 of your 100 modules needs to be scaled, it probably means the overall monolith only needs a small amount of extra resources, since that module is only using 1% of the total. So it's not like you need to double the instances of the whole thing. The benefit though is you get a bit of 'free' scaling. Most of the modules don't even have to consider scaling at all, as long as they are growin…

> The way it usually works, if 1 of your 100 modules needs to be scaled, it probably means the overall monolith only needs a small amount of extra resources, since that module is only using 1% of the total. So it's not like you need to double the instances of the whole thing. I could be wrong but doesn't monolith usually refer to one really heavy app? As soon as you go from needing 1 instance to 2 (because 1 of the 1…

You do lose some memory to holding unnecessary code and whatever data caching that a module does. But it's not generally very much and large data caching can be pushed to Redis. If you're not buying your servers by the rack or data center it's ultimately negligible compared to development cost.

Re: Modules, not microservices

#349

Post by esailija » Tue, Jan 03, 2023, 5:25 PM UTC

TimPC wrote: post #239

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…

Modules aren't an alternative to microservices in a reasonable way though. And for all modules solve the modularization problem at the code level, they don't really solve modularization at the service level. The main alternative to microservices is monoliths and for many applications I far prefer microservices to monoliths. I want modularization in how I scale my app, I don't want to spin up a whole bunch of servers…

Just because the monolith image contains all code doesnt mean each deployment needs to run all that code. Or even same version of the code. A deployment can run only a small portion of the code determined by deployment args. It can even run an older version than other deployments

Re: Modules, not microservices

#350

Post by habibur » Tue, Jan 03, 2023, 5:26 PM UTC

therealdrag0 wrote: post #342

gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

I used to be monolith-curious, but what sold me on micro-services is the distribution of risk. When you work for a company where uptime matters having a regression that takes down everything is not acceptable. Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

> Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

or maybe run redundant monolith fail over servers. should work the same as micro services.