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

211–220 of 671 posts

Re: Modules, not microservices

#211

Post by pjmlp »

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.

If the modules are distributed in binary form, for the languages that support them, the junior will have no way around it unless they feel like learning about hacking binaries.

Re: Modules, not microservices

#212

Post by pjmlp »

regularfry wrote: post #201
treis wrote: post #170

Earlier quoted context omitted.

Can you explain why you can deploy microservices independently but not modules?

You can deploy modules independently, but the technical and organisational measures you need in place to do it safely are an extra step you need to take whereas with microservices they're built in. Modules live in the same execution context, so you need a good shared ownership model for that context itself. The point is that Parnas never conceived of doing it because he was writing about a world where the interfaces…

Same thing with microservices, unless you do a blue green deployment, have a planned shutdown, load balancer in between releases,...

Re: Modules, not microservices

#213

Post by pjc50 »

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…

> Instagram

Does anyone have a microservice "map" of Instagram? I feel that would be helpful here.

Re: Modules, not microservices

#214

Post by marcosdumay »

karamanolev wrote: post #24
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.

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 away. It is almost always good to organize your code when it reaches a size like this, and the exceptions are on contexts where you can't, never on contexts where it's worthless.

Re: Modules, not microservices

#215

Post by geodel »

mbork_pl wrote: post #13
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'…

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

It is a kind of cult really. Along with the rise of modern editors which somehow craps out at relatively large files. So small files are sold as well organized, modular, logically arranged codebase. You see these lot of adjectives to support short files. None of them seem to be obviously true to me.

Re: Modules, not microservices

#216

Post by selcuka »

donkeyd wrote: post #165
c-fe wrote: post #107

Earlier quoted context omitted.

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

This is one of the reasons I dislike working in teams that lack 'old people'. Young devs still have a lot of mistakes to make that old devs have already made or seen. The young ones seem to see them as slow and difficult, but they also create stability and control. In a start-up, having a team of young people will allow you to move fast, pivot and deliver. What you usually end up with though, is a tower built from sp…

Agreed. This is a corollary of the Second-system effect [1]. By the time developers design their third system they have become relatively "old".

[1]: https://en.wikipedia.org/wiki/Second-system_effect

Re: Modules, not microservices

#217

Post by mbork_pl »

pshirshov wrote: post #198
mbork_pl wrote: post #149

Earlier quoted context omitted.

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

Just two of many reasons: parallel linting, parallel parsing.

Ah. Silly me. Still, linting/parsing 5000 sloc is almost instantaneous even on my pretty old laptop.

Re: Modules, not microservices

#218

Post by dahfizz »

CraigJPerry wrote: post #94
jiggawatts wrote: post #60

Earlier quoted context omitted.

> your task is to just make it a little bit faster. Where do you begin With a trace from a profiler tool, which will tell you which line number is the hot spot. If run from any modern IDE, you can jump to the line with a mouse-click. In essence, the file boundaries ought not to make any difference to this process.

>> In essence, the file boundaries ought not to make any difference to this process. I find this the strongest counter argument. File boundaries shouldn’t matter - but in practice they do. The ide will give up doing some of its analysis because this is not an optimised use case, the IDE vendors don’t optimise for it. Some IDEs will even give up just simple syntax highlighting when faced with a large file, never mind…

Do you have a feel for how large a file has to be for an IDE to choke on it? My vim setup can open a 13GB file in about ten seconds, with all syntax highlighting, line numbers, etc working. Once the file is open, editing is seamless.

Bitbucket is the biggest offender for me. It starts to disable syntax highlighting and context once the file hits about 500KB, which should be trivial to deal with.

Re: Modules, not microservices

#219

Post by Guid_NewGuid »

Time to throw the cat amongst the proverbial pigeons and start the year 2023 off with discord and disharmony.

Microservices are a solution to a problem. TDD is a solution to a problem, the same problem. Both are solutions that themselves create more, and worse, problems. Thanks to the hype driven nature of software development the blast radius of these 'solutions' and their associated problems expands far beyond the people afflicted by the original problem.

That problem? Not using statically typed languages.

TDD attempts to reconstruct a compiler, poorly. And Microservices tries to reconstruct encapsulation and code structure, poorly. Maybe if you don't use a language which gets hard to reason about beyond a few hundred lines you won't need to keep teams and codebases below a certain size. Maybe if you can't do all kinds of dynamic nonsense with no guardrails you don't have to worry so much about all that code being in the same place. The emperor has no clothes, he never had.

Edit: to reduce the flame bait nature of the above a bit. Not in all cases, I'm sure there are a very few places and scales where microservices make sense. If you have one of those and you used this pattern correctly, that's great.

And splitting out components as services is not always bad and can make a lot of sense. It's the "micro" part of "microservices" that marks out this dreadful hype/trend pattern I object to. It's clearly a horrible hack to paper over the way dynamically typed codebases become much harder to reason about and maintain at scale. Adding a bunch of much harder problems (distributed transactions, networks, retries, distributed state, etc) in order to preserve teams sanity instead of just using tooling that can enforce some sense of order.

Re: Modules, not microservices

#220

Post by davidshepherd7 »

pjc50 wrote: post #213
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…

> Instagram Does anyone have a microservice "map" of Instagram? I feel that would be helpful here.

They actually use a python monolith unless it's changed recently. See e.g. https://instagram-engineering.com/static-analysis-at-scale-a...
Post reply on HN