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

101–110 of 671 posts

Re: Modules, not microservices

#101

Post by ReflectedImage »

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 changed and allows you to test the microservices in isolation.

If you a production issue, the exception will be in a log file that corresponds to a single microservice or part of your codebase.

Microservices are a hard form of encapsulation and gives a lot of benefits when the underlying language lacks that encapsulation. e.g. Python.

Re: Modules, not microservices

#102

Post by ivanhoe »

AnIdiotOnTheNet wrote: post #18
hgsgm wrote: post #6

Earlier quoted context omitted.

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.

You say that like real-time multiplayer gaming doesn't exist or something. Both of them have worked on those.... I think Carmack invented a lot of the techniques we use for those. Yeah sure, the scale is smaller, but you can't get away with making the user wait 10 seconds to render text and images to a screen either. I think the software world might be a lot better place if more developers thought like game developer…

Let's not turn it into penis measuring contents, please. Code organization and requirements differ significantly between different programming niches, and the today's accepted practices are not some randomly invented caprices, but the result of the slow (and painful) evolution we've been fighting through past decades. Each niche has optimized over time for its own needs and requirements. My web apis have hundreds of controllers and keeping them in separate files makes it way easier to manage. I know that because we used to keep it all in a single file and it sucked, so over time I learned not to do it anymore. Does it mean that embedded systems devs should organize their code in the same way? I have no idea, that's up to them to decide, based on their specific environment, code and experience.

Re: Modules, not microservices

#103

Post by davej »

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…

Twitter has a similar issue according to Musk https://twitter.com/elonmusk/status/1592176202873085952

Re: Modules, not microservices

#104

Post by nonethewiser »

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

Not sure I totally agree, but one strong point against factoring in-line code out into a function:

You have to understand everything that calls that function before you change it.

This is not always obvious. It takes time to figure out where it's called. IDEs make this easier but not bullet proof. Getting it wrong can cause major, unexpected problems.

Re: Modules, not microservices

#105

Post by c-fe »

padjo wrote: post #86
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!

You are right, looking back I also ask why it was not considered more indepth before. I was not involved in the decision making process as I recently joined, and to be honest I would have maybe not thought about it either (but will certainly in the future). I think the main reason this became such a big problem is because we underestimated the number of calls that would be made between the services. Service A was initally supposed to call Service B only as a last resort, so the 10 ms or so were fine, but in the end, the answers that Service B gave turned out to be very useful in our process so more and more calls were made and now they are strongly connected, but still separated services, which is ... not ideal.

Re: Modules, not microservices

#106

Post by londons_explore »

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…

In which case, the next step for your org is a mandate that all microservices be available in all datacenters.

Let each microservice owner figure out how to achieve their latency+reliability SLA's in every location - whether replicating datastores, caching, being stateless, or proxying requests to a master location.

Re: Modules, not microservices

#107

Post by c-fe »

arkh wrote: post #99
padjo wrote: post #86

Earlier quoted context omitted.

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!

Someone must have read a blog post about microservice and decided it would look good on their resume.

Unfortunately this is also partly correct - The team was young and people were eager to play around and learn how to work with microservices.

Re: Modules, not microservices

#108

Post by SomeoneOnTheWeb »

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

10+K lines spread across 1k file is equally as bad as 10+K line files IMO.

I tend to ensure each file serves exactly one purpose (e.g. in C# one file = one class, with a only few exceptions).

I use VS Code, but in every IDE with a file opening palette it's actually really fast: you want to look for the code to, let's say, generate an invoice, just search for "invoice" in the list of files and you'll find it immediatly.

(Also modules have their own problem, I was mainly talking in a general way since that's what the parent comment was talking about.)

Re: Modules, not microservices

#109

Post by throwawaaarrgh »

Software architecture can be tailored to a specific use case to best fit an application. Rather than strictly align to some thereoreical design principle, one can consider the use case and end goals and make the architecture match it.

But in general,just write some damn code. Presumably you have to write code, because building a software engineering department is one of the most difficult things you can do in order to solve a business problem. Even with the smartest engineers in the world (which you don't have), whatever you ship is inevitably going to end up an overly complex, expensive, bug-riddled maintenance nightmare, no matter what you do. Once you've made the decision to write code, just write the damn code, and plan to replace it every 3-5 years, because it probably will be anyway.

Re: Modules, not microservices

#110

Post by SomeoneOnTheWeb »

pshirshov wrote: post #22
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.

And of course it's lot easier to read 200k+ LoC shattered around twenty repos.

No, to me that's equally as bad. But 100k lines split across 500 well-named files is a lot easier to work with than 10+K line files or multi-repo code.
Post reply on HN