Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices should form a polytree

bytesauna.com

Post reply on HN
Print view View original

21–30 of 121 posts

Re: Microservices should form a polytree

#21

Post by rcxdude »

didibus wrote: post #14

I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected. Think more actors/processes in a distributed actor/csp concurrent setup. Their interface should therefore be hardened and not break constantly, and they shouldn't each need deep knowledge of the intricate details of each other. Also for many system designs, you would expl…

Well, in practice you're likely to have hard dependencies between services in some respect, in that the service won't be able to do useful work without some other service. But I agree that in general it's a good idea to have a graceful degradation of functionality as other services become unavailable.

Re: Microservices should form a polytree

#22

Post by rco8786 »

jayd16 wrote: post #7
rco8786 wrote: post #6

Is there any way to actually enforce this in reality? Eventually some leaf service is going to need to hit an API on an upstream node or even just 2 leaf nodes that need to talk to each other.

IAM roles. Said less snarky, it should be trivial to define and restrict the dependencies of services (Although there are many ways to do that). If its not trivial, that's a different problem.

I don't mean that. I mean that eventually the business is going to need some feature that requires breaking the acyclic rule.

Re: Microservices should form a polytree

#23

Post by dragonwriter »

adamwong246 wrote: post #16

the problem with "microservices" is the "micro". Why we thought we need so many tiny services is beyond me. How about just a few regular sized services?

At the time “microservices” was coined, “service oriented architecture” had drifted from being an architectural style to being associated with inplementation of the WS-* technical standards, and was frequently used to describe what were essentially monoliths with web services interfaces.

“Microservices” was, IIRC, more about rejecting that and returning to the foundations of SOA than anything else. The original description was each would support a single business domain (sometimes described “business function”, and this may be part of the problem, because in some later descriptions, perhaps through a version of the telephone game, this got shortened to “function” and without understanding the original context...)

Re: Microservices should form a polytree

#24

Post by mkarrmann »

cientifico wrote: post #19

Services (or a set of Microservices) should mimic teams at the company. If we have polytree, that should represent departments.

Microservices should have clear owners reflected in the org chart, but the topology of dependencies should definitely not be isomorphic to your org chart.

Re: Microservices should form a polytree

#25

Post by edude03 »

adamwong246 wrote: post #16

the problem with "microservices" is the "micro". Why we thought we need so many tiny services is beyond me. How about just a few regular sized services?

Kind of - AFAIK "micro" was never actually throughly defined. In my mind I think of it as mapping to one table (IE, users = user service, balances = balances service) but that might still be a "full service" worth of code if you need anything more than basic CRUD

Re: Microservices should form a polytree

#26

Post by Lucasoato »

> Even without a directed cycle this kind of structure can still cause trouble. Although the architecture may appear clean when examined only through the direction of service calls the deeper dependency network reveals a loop that reduces fault tolerance increases brittleness and makes both debugging and scaling significantly more difficult.

While I understand the first counterexample, this one seems a bit blurry. Can anybody clarify why a directed acyclic graph whose underlying undirected graph is cyclic is bad in the context of microservice design?

Re: Microservices should form a polytree

#27

Post by Spivak »

throwaway894345 wrote: post #20
Neywiny wrote: post #4

Earlier quoted context omitted.

The explanation given makes sense. If they're operating on the same data, especially if the result goes to the same consumer, are they really different services? On the other hand, if the shared service provides different data to each, is it really one microservice or has it started to become a tad monolithic in that it's one service performing multiple functions? I like that the author provides both solutions: join…

Most components need to depend on an auth service, right? I don’t think that means it’s all necessarily one service (does all of Google Cloud Platform or AWS need to be a single service)?

That's immediately what I thought of. You'll never be able to satisfy this rule when every service has lines pointing to auth.

You'll probably also have lines pointing to your storage service or database even if the data is isolated between them. You could have them all be separate but that's a waste when you can leverage say a big ceph cluster.

Re: Microservices should form a polytree

#28

Post by marcosdumay »

throwaway894345 wrote: post #17
didibus wrote: post #14

I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected. Think more actors/processes in a distributed actor/csp concurrent setup. Their interface should therefore be hardened and not break constantly, and they shouldn't each need deep knowledge of the intricate details of each other. Also for many system designs, you would expl…

I agree with this, and also I’m confused by the article’s argument—wouldn’t this apply equally to components within a monolith? Or is the idea that—within a monolith—all failures in any component can bring down the entire system anyway?

> wouldn’t this apply equally to components within a monolith?

It's a nearly universal rule you'll want on every kind of infrastructure and data organization.

You can get away for some time with making things linked by offline or pre-stored resources, but it's a recipe for an eventual disaster.

Re: Microservices should form a polytree

#30

Post by nicodjimenez »

nicodjimenez wrote: post #29

This seems completely wrong. In an RPC call you have a trivial loop, for example. It would make more sense to say that the event tree should not have any cycles, but anyway this seems like a silly point to make.

My main take on microservices at this point is that you only want microservices to isolate failure modes and for independent scaling. Most IO bound logic can live in a single monolith.
Post reply on HN