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

141–150 of 671 posts

Re: Modules, not microservices

#141

Post by sarchertech »

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…

The 2 generals problem illustrates the problems with this. You can’t just call a function over an unreliable communication channel and expect it to work the same way.

Solving this in the general case for every function call is difficult. Pure functions are idempotent, so you can retry everything until nothing fails.

But once you add side effects and distributed state, we don’t know how to solve this in a completely generalized and performant way.

Re: Modules, not microservices

#142

Post by chasd00 »

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…

yeah i've always thought that microservices shine when the org chart defines them. I've been on teams where we were responsible for multiple microservices and it was so annoying to have to bounce back and forth between code bases and deployments and then it was super easy to intertwine different microservices when you were in the them so often. I feel like if you don't have a team dedicated full time per microservice then you probably shouldn't be using that architecture.

Re: Modules, not microservices

#143

Post by Pamar »

anthonypasq wrote: post #132
Pamar wrote: post #120

Earlier quoted context omitted.

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

ive never seen that in practice. you dont have a database for each individual lambda. thats insanity. you can have multiple microservices point to a shared datasource, its not illegal.

I agree, and yet most microservice zealots seem to have a different opinion on this.

e.g.: https://www.baeldung.com/cs/microservices-db-design

"2.1. Fundamentals By definition, microservices should be loosely coupled, scalable, and independent in terms of development and deployment. Therefore, the database per service is a preferred approach as it perfectly meets those requirements. Let’s see how it looks:"

Please understand that I have worked only on monoliths and will probably retire while still working on monoliths. This kind of absurd positions only come up when someone comes to my office with some grand plan to convert the application I work on to something "more microservice oriented".

Re: Modules, not microservices

#144

Post by kayodelycaon »

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…

Country codes, and other lookup tables, could easily be handled by a repository of config files. Or, if your company uses a single programming language, a library.

One strategy I've used is to designate one system as a source of truth (usually an ERP system) and periodically query its database directly to reload a cache. Every system works off their own periodically refreshed cache. Ideally, having all the apps query a read replica would prevent mistakes from taking down the source of truth.

I haven't done this, but I think using Postgres with a combination of read-only foreign tables and materialized views could neatly solve this problem without writing any extra code.

I don't know how far this would scale. I do know that coordination and procedures for using/changing the source of truth will fall apart long before technical limitations.

Re: Modules, not microservices

#145

Post by louthy »

worldsayshi wrote: post #69
louthy wrote: post #29

Earlier quoted context omitted.

... then before you know it your code-base is 10 million lines long and you have no idea where anything is, what the side-effects of calling X are, what's been deprecated, onboarding is a nightmare, retention of staff is difficult, etc. You may be right for the smallest of applications, or whilst you're building an MVP, but if your application does anything substantial and has to live forever (a web app, for example)…

I think we are conflating (at least) two different issues here because we don't have a good way to deal with them separately. Closure on one hand and implicit logic on the other. Most of the time when I split out a method what I want is a closure that is clearly separated from the rest of the code. If I can have such closures, where input and output is clearly scoped, without defining a new method, that might be pref…

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

Re: Modules, not microservices

#146

Post by mbork_pl »

nicoburns wrote: post #55
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…

I often want to have multiple parts of the code open at once. Sometimes 5-10 different parts of the code (usually not so many as that, but it depends what I'm doing) so I can flip between them and compare code or copy and paste. Most editors I've used don't have good support for that within a single file (and having 5 tabs with the same name isn't going to make it very easy to tell which is which).

Very good point, though this is really a deficiency of "most editors". ATM I have 300+ files open in my Emacs (which is no wonder given that I work on several projects, and my current Emacs uptime is over 6 days, which is even fairly short). Using tabs is bad enough with 5+ files, tabs with 300+ would be a nightmare.

That said, Emacs can show different parts of the same file in several buffers, a feature which I use quite a bit (not every day, but still). And of course I can rename them to something mnemonic (buffer name ≠ file name). So I personally don't find this convincing at all.

Re: Modules, not microservices

#148

Post by mbork_pl »

osigurdson wrote: post #50
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…

If the file only contains static methods, it doesn't matter too much. However a class with mutable state should be kept pretty small imo.

This only applies to OOP, no?

Re: Modules, not microservices

#149

Post by mbork_pl »

pshirshov wrote: post #25
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…

Just one of many reasons: parallel compilation.

Another excellent point, but only applicable to compiled languages (so still not my case).

Re: Modules, not microservices

#150

Post by worldsayshi »

louthy wrote: post #145
worldsayshi wrote: post #69

Earlier quoted context omitted.

I think we are conflating (at least) two different issues here because we don't have a good way to deal with them separately. Closure on one hand and implicit logic on the other. Most of the time when I split out a method what I want is a closure that is clearly separated from the rest of the code. If I can have such closures, where input and output is clearly scoped, without defining a new method, that might be pref…

> 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. :/
Post reply on HN