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

301–310 of 671 posts

Re: Modules, not microservices

#301

Post by jeltz »

marcosdumay wrote: post #171
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.

> But they can't simply dissolve the hard boundary of having a service in another location. I've seen people doing that a few times already. They start changing due to some uninformed kind of "convenience", and then you look at the services API and it makes no sense at all.

Yeah, I feel that happens all the time.

Re: Modules, not microservices

#302

Post by esailija »

jacobr1 wrote: post #268
esailija wrote: post #194

Earlier quoted context omitted.

Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices. Look up a thing called "distributed monolith".

That is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.

Then why cannot you have separate repos and review processes for modules? This has nothing to do with microservices vs modules.

Re: Modules, not microservices

#303

Post by hinkley »

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.

In an organization that will be bankrupt in three years it doesn’t matter. But if you can pour that much energy into a doomed project you’re a steely eyed missile man. Or dumb as a post. Or maybe both at once.

This is the Pendulum Swing all over again. If one language and runtime is limiting, forty is not liberating. If forty languages are anarchy, switching to one is not the answer. This is in my opinion a Rule of Three scenario. At any moment there should be one language or framework that is encouraged for all new work. Existing systems should be migrating onto it. And because someone will always drag their feet, and you can’t limit progress to the slowest team, there is also a point in the migration where one or two teams are experimenting with ideas for the next migration. But once that starts to crystallize any teams that are still legacy are in mortal danger of losing their mandate to another team.

Re: Modules, not microservices

#305

Post by mypalmike »

dmitriid wrote: post #68
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 greatly underestimate the complexity of games, and greatly overestimate the complexity of working with distributed systems over social graphs

I've worked extensively in both. Both are complex. Games typically have a complexity that requires more careful thinking at the microscopic level (we must do all this game state stuff within 16ms). Web service complexity requires careful thinking about overall systems architecture (we must be able to bring up 10x normal capacity during user surges while avoiding cost overruns). The solutions to these problems overlap in some ways, but are mostly rather different.

Re: Modules, not microservices

#306

Post by pjmlp »

jacobr1 wrote: post #279
pjmlp wrote: post #235

Earlier quoted context omitted.

There is no independently in distributed systems.

But there are rules of blame. With microservices, as long as you maintain the contract with caller services, you can deploy whenever you want. If you have some kind of issue, your team is solely responsible. If the caller services do weird things, they are responsible for fixing them. If you are pushing changes to a module as part of a more monolithic, or wrapper service - if you do a deploy and break the whole big s…

Unless there is infrastructure in place good luck replicating those dropped requests as services are replaced.

Infrastructure that someone has to take care of.

Re: Modules, not microservices

#307

Post by hbrn »

speed_spread wrote: post #82
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…

One big reason is source control. Having many smaller files with well defined purpose reduces the number of edit collisions (merges) when working in teams. Also, filenames and directories tree act as metadata to help create a mental map of the application. The filesystem is generally well represented in exploratory tools like file browser and IDE. While the same information can be encoded within the structure of a si…

> Also, filenames and directories tree act as metadata to help create a mental map of the application

Correct. But this is an argument against splitting: once your folder structure reflects your mental model, you should no longer split, no matter how big individual files get. Splitting further will cause you to deviate from your mental model.

Also, it seems like we're arguing against a strawman: saying "big files are okay" is not the same as "you should only have big files". When people mean is that having a big file does not provide enough justification to split it. But it is still a signal.

Re: Modules, not microservices

#308

Post by pron »

hbrn wrote: post #300
pron wrote: post #16

Earlier quoted context omitted.

It's a valid hypothesis, but without empirical data the question is not easy to settle (and neither Carmack nor Blow are notable authorities on systems that have to be maintained by changing teams of hundreds of people that come and go, maintaining a large codebase over a couple of decades; if anything, most of their experience is on a very different kind of shorter-lived codebases, as game engines are often largely…

> neither Carmack nor Blow are notable authorities on systems that have to be maintained by changing teams of hundreds of people that come and go Most systems don't have to be maintained by hundreds of people. And yet they are: maybe because people don't listen to folks like Carmack? We like stories about huge teams managing huge codebases. But what we should really be interested in is practices that small teams empl…

I didn't mean a team of hundreds maintaining the product concurrently, but over its long lifetime. A rather average codebase lifetime for server software is 15-20 years. The kind of codebase that Carmack has experience with has a lifetime of about five years, after which it is often abandoned or drastically overhauled, and it's not like games have an exceptional quality or that their developers report an exceptionally good experience that other domains would do well to replicate what games do. So if I were a game developer I would definitely be interested in Carmack's experience -- he's a leading expert on computer graphics (and some low-level optimisation) and has significant domain expertise in games, but he hasn't demonstrated some unique know-how in maintaining a very large and constantly evolving codebase over many years. Others have more experience than him in domains that are more relevant to the ones discussed here.

Re: Modules, not microservices

#309

Post by pjmlp »

dilyevsky wrote: post #288
pjmlp wrote: post #241

Earlier quoted context omitted.

So much for the theory, most services I see in the wild are stateful. As for scalability, most orgs aren't Facebook nor Google scale, regardless of how much they want it to be true. All of those issues can be tackled, when proper architecture design is done, instead of coding on the go and then will see attitude.

People keep regurgitating this “you aint going to be google” mantra but I worked there and in reality generic microservice stack is in a totally different league of complexity and sophistication of what google and co have. This argument is basically reductio ad absurdum

We keep regurgitating this, because most microservices are the 2nd coming of big data that fits into a USB stick.

Re: Modules, not microservices

#310

Post by ReflectedImage »

Pamar wrote: post #120
ReflectedImage wrote: post #101

Earlier quoted context omitted.

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

1 microservice. It's up to the software engineer to scope out the microservices properly.
Post reply on HN