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

531–540 of 671 posts

Re: Modules, not microservices

#531

Post by vaughan »

mavelikara wrote: post #508
vaughan wrote: post #224

Earlier quoted context omitted.

> Only when this is all done, you think about the communication patterns and discuss how to scale the app. The main thing is that regardless of scaling, the app should always be able to run/debug/test locally in a monolithic thing. Once people scale they seem to abandon the need to debug locally at their peril. Scaling should just be a process of identifying hot function calls and when a flag is set, to execute a cal…

The execution model of local calls are quite different from remote calls. Because of these differences, many efforts have been made, but "transparent remoting" is still not achieved [1]. [1] https://scholar.harvard.edu/waldo/publications/note-distribu...

Thanks for the interesting read.

I agree with sentiment of the paper in that it can never be fully transparent. When I say "it should just be a process of identifying hot function calls..." this is admittedly a little contrived - there would need to be a more thorough analysis.

The main point seems to be that partial failure is too difficult to handle without explicitly declaring some objects as "remote".

> Merging the models by making local computing follow the model of distributed computing would require major changes in implementation languages (or in how those languages are used) and make local computing far more complex than is otherwise necessary

Given that the paper is from 1994, I'm wondering if there have been language changes that make this more achievable.

What comes to mind is the event loop. The fact that in Node.js, almost every function call is now an asynchronous promise due to the non-blocking paradigm coupled with the convenience of async/await syntax. These event loop runtimes provide a universal way to hook into asynchronous calls.

I would imagine that in 1994, envisioning the code added to the languages of the day needed to handle timeout and asynchronous invocations would have felt overwhelming.

Also thinking about ORMs and databases. It seems TOPLink for SmallTalk was the first, released in 1995 after this paper was. ORMs seem kind of like "transparent remoting", as they usually can run against an in-memory database or db on a local system, or over an TCP connection, which then needs to deal with latency and failure. And for any app talking to a DB with an ORM, means that the failure cases of the ORM must prevade throughout the stack.

Re: Modules, not microservices

#532

Post by thayne »

nthj wrote: post #513
thayne wrote: post #476

Earlier quoted context omitted.

> I don't really think microservices are fundamentally more scalable It depends on what you are scaling. I think microservices are fundamentally more scalable for deployment, since changes can be rolled out only to the services that changed, rather than everywhere. Unless your language and runtime support hot-loading individual modules at runtime.

Git and/or feature flags exist for this reason. Adding a network layer isn't the fundamental insight here, but it can cause additional consequences.

I'm talking about the scalability of actually delivering new code to servers (or "serverless" runtimes). Feature flags don't help with that.

Admittedly, it isn't a scalability problem you will run into right away.

But when you need to roll out an emergency fix, there is a big difference between deploying to thousands of servers that all have everything, and ten servers running a single service.

Re: Modules, not microservices

#533

Post by varsketiz »

mixermachine wrote: post #524
gadflyinyoureye wrote: post #517

Earlier quoted context omitted.

Sometimes. If the services are all interrelated, you’re as dead on the water with Microservices was you would be in a monolith.

Sure depends on the architecture. When the auth service is down, everything else should be down. But when the "optional feature" service is down, a core component should be unaffected by that. Split up services where it makes sense and don't over do it. That's how I design my projects.

For many websites, there is considerable amount of content that should be available if auth is down. Think eshops, news portals, etc.

Re: Modules, not microservices

#535

Post by noobermin »

FpUser wrote: post #503
Xeoncross wrote: post #412

Earlier quoted context omitted.

Helps to have a language that natively uses more CPU cores and/or training for the devs. Ruby, Python, PHP and Node.js startups have to figure out how to use the cores while C++, Rust, Erlang and Go have no issues running a single process that maxes out all 64 CPU cores.

This is exactly what I do. When it comes to your regular backend business server I write stateful multithreaded monolith in C++ sitting on the same computer as the database hosted on some multicore server with gobbles of RAM (those are cheap now). Performance is insane and is enough to serve any normal business for years or decades to come. So it does not work for FAANG companies but what do I care. I have the rest o…

>So it does not work for FAANG companies but what do I care. I have the rest of the world to play with ;)

As long as hype chasers in middle management don't get in the way after convincing themselves they too must be like FAANG with a few orders of magnitude less of a consumer base.

Re: Modules, not microservices

#536

Post by JAlexoid »

dkarl wrote: post #277
mpweiher wrote: post #92

Earlier quoted context omitted.

> Microservices [..] actually solve for a human problem in scaling up an organization. So does modularity. "The benefits expected of modular programming are: (1) managerial_development time should be shortened because separate groups would work on each module with little need for communication..." On the Criteria To Be Used in Decomposing Systems into Modules , D.L. Parnas 1972. http://sunnyday.mit.edu/16.355/parnas-…

For code modularity to serve the same purpose, I think there needs to be explicit language-level support, because on a medium-sized or larger project, when the modularity exists only in the minds of developers, it might as well not exist at all. You need virtually all of your developers to understand the design and respect the seriousness of violating it, and beyond a certain project size, that isn't possible. Develo…

You would hope so... but it's not necessarily the case.

Often people are too lazy to issue API version change on a "bugfix", and take down multiple applications.

Funny thing, a modularized monolith may have identified some of those issues.

Re: Modules, not microservices

#537

Post by JAlexoid »

kevincox wrote: post #487
brunoborges wrote: post #484

Earlier quoted context omitted.

> scalability (being able to increase the amount of compute, memory and IO to the specific modules that need it). I gave a talk [1] about scalability of Java systems on Kubernetes, and one of my recommendations is that Java-based systems - or any system on a runtime similar to the JVM, like CLR or even Go - should be scaled diagonally. Efficiency is the word. While horizontal scaling can easily address most performan…

Basically any software, even something in C or C++ with manual memory management will scale more efficiently vertically than horizontally. Basically it would be better to run one twice as big as it would be to run two instances on the same machine. There is almost always some overhead or cache that will make the performance of fewer instances better. The only exception is resource contention but it is generally not t…

It's really not a big surprise, tbh.

Making data available to a thread on the same core has exceptionally high bandwidth. Just that alone will help with scaling.

Re: Modules, not microservices

#538

Post by JAlexoid »

brundolf wrote: post #510
oflor wrote: post #506

Earlier quoted context omitted.

Tech zoo sometimes considered to be an anti-pattern in microservices. By introducing a different language into your organization, you decrease the mobility of developers between code bases and dilute technical knowledge.

Everybody shouldn't pull in their favorite stack just for fun, but it seems valuable to have the option of trying out new things that could turn out to be a better way forward for the org

Not worshiping the Microservice, doesn't mean that you avoid services in different languages.

Not all engineers need to move around - DS and MLEs are generally useless on the frontend, and vice versa.

Re: Modules, not microservices

#539

Post by JAlexoid »

jacobr1 wrote: post #313
MuffinFlavored wrote: post #271

Earlier quoted context omitted.

devil's advocate: > A few ways, the easiest being to scale up the whole monolith with more instance as far as I know, there's no way to granularly scale up a monolith. if the monolith has 20 or 50 or 100 modules and you need 1 or 2 of them scaled, you have to scale up the entire thing which is huge, expensive, etc. > Another way is run multiple "services" using the same codebase, so you have workload segmentation, ei…

> you have to scale up the entire thing which is huge, expensive, etc. Yes, yet people still do it that way. This is tradeoff against the costs of microservices. I'm not saying it is worth it, but yes, sometimes you can just inefficiently throw hardware resources at scaling problems. > this is interesting. a monolith with some form of IPC? why not do microservices at that point? that sounds like microservices-ish? Be…

>I'm not saying it is worth it, but yes, sometimes you can just inefficiently throw hardware resources at scaling problems

Microservice scaling is also an inefficient hardware scaling option.

Re: Modules, not microservices

#540

Post by lucasyvas »

n1c00o wrote: post #399
lucasyvas wrote: post #227

The biggest draw of microservices to those just adopting them is not scalability or separation of concerns, but independent deployability (move fast and deploy new features in a particular area unencumbered). Good LUCK getting that property with a monolithic or modular system. QE can never be certain (and let's be honest, they should be skeptical) that something modified in the same codebase as something else does no…

This sounds like Bell Labs' Plan9

I am "too young" to get the reference but I looked it up and once again smiled at how little I know :)
Post reply on HN