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

41–50 of 121 posts

Re: Microservices should form a polytree

#41

Post by nyrikki »

rcxdude wrote: post #21
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.

As we are talking about micro services, K8s has two patterns that are useful.

A global namespace root with sub namespaces will just desired config and current config will the complexity hidden in the controller.

The second is closer to your issue above, but it is just dependency inversion, how the kubelet has zero info on how to launch a container or make a network or provision storage, but hands that off to CRI, CNI or CSI

Those are hard dependencies that can follow a simple wants/provides model, and depending on context often is simpler when failures happen and allows for replacement.

E.G you probably wouldn’t notice if crun or runc are being used, nor would you notice that it is often systemd that is actually launching the container.

But finding those separation of concerns can be challenging. And K8s only moved to that model after suffering from the pain of having them in tree.

I think a DAG is a better aspirational default though.

Re: Microservices should form a polytree

#43

Post by nineteen999 »

otterley wrote: post #36
jayd16 wrote: post #7

Earlier quoted context omitted.

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.

Since you called the problem “trivial,” we can now all depend on you to resolve these problems for us at little cost, correct?

The solution requires AWS since the gp thinks that's the only access control mechanism that matters. So I doubt there is going to be little cost about it.

Re: Microservices should form a polytree

#44

Post by sethammons »

jayd16 wrote: post #8

It's about the same for most code all the way down to single threaded function flow.

Yes! This is not unique to microservices.

If you look at this proposal and reject it, i question your experience. My experience is not doing this leads to codebases so intertwined that organizations grind to a halt.

My experience is in the SaaS world, working with orgs from a few dozen to several thousand contributors. When there are a couple dozen teams, a system not designed to separate out concerns will require too much coordinated efforts to develop against.

Re: Microservices should form a polytree

#45

Post by whstl »

nightpool wrote: post #11
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…

I don't understand this. Can you help explain it with a more practical example? Say that N1 (the root service) is a GraphQL API layer or something. And then N2 and N3 are different services feeding different parts of that API—using Linear as my example, say we have a different service for ticket management and one for AI agent management (e.g. Copilot integration). These are clearly different services with different…

Yeah, a lot of cross-cutting concerns fall into this pattern: logging, authorization, metrics, audit trails, feature-flags, configuration distribution, etc

The only way I can see to avoid this is to have all those cross-cutting concerns handled in the N1 root service before they go into N2/N3, but it requires having N1 handle some things by itself (eg: you can do authorization early), or it requires a lot of additional context to be passed down (eg: passing flags/configuration downstream), or it massively overcomplicates others (eg: having logging be part of N1 forces N2/N3 to respond synchronously).

So yeah, I'm not a fan of the constraint from TFA. It being a DAG is enough.

Re: Microservices should form a polytree

#46

Post by advisedwang »

Requiring that no service is depended on by two services is nonsense.

You absolutely want the same identity service behind all of your services that rely on an identity concept (and no, you can't just say a gateway should be the only thing talking to an identity service - there are real downstream uses cases such as when identity gets managed).

Similarly there's no reason to have multiple image hosting services. It's fine for two different frontends to use the same one. (And don't just say image hosting should be done in the cloud --- that's just a microservice running elsewhere)

Same for audit logging, outbound email or webhooks, acl systems (can you imagine if google docs, sheets, etc all had distinct permissions systems)

Re: Microservices should form a polytree

#47

Post by 9rx »

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?

"Micro" refers to the economy, not the technology. A service in the macro economy is provided by another company. Think of a SaaS you use. Microservices takes the same model and moves it under the umbrella of a micro economy (i.e. a single company). Like traditional SaaS, each team is responsible for their own product, with communication between teams limited to sharing of documentation. You don't get to call up a developer when you need help.

It's a (human) scaling technique for large organizations. When you have thousands of developers they can't possibly keep in communication with each other. You have to draw a line between them. So, we draw the line the same way we do at the global scale.

Conway's Law, as usual.

Re: Microservices should form a polytree

#48

Post by liampulles »

advisedwang wrote: post #46

Requiring that no service is depended on by two services is nonsense. You absolutely want the same identity service behind all of your services that rely on an identity concept (and no, you can't just say a gateway should be the only thing talking to an identity service - there are real downstream uses cases such as when identity gets managed). Similarly there's no reason to have multiple image hosting services. It's…

I agree with you. Its interesting when I look at the examples you provide, that they are all non-domain services, so perhaps that is what codifies a potential rule.

Re: Microservices should form a polytree

#49

Post by isotropy »

Lucasoato wrote: post #26

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

Without necessarily endorsing the article's ideas....I took this to be like the diamond-inheritance problem.

If service A feeds both B and C, and they both feed service D, then D can receive an incoherent view of what A did, because nothing forces B and C to keep their stories straight. But B and C can still both be following their own spec perfectly, so there's no bug in any single service. Now it's not clear whose job it is to fix things.

Re: Microservices should form a polytree

#50

Post by pavlov »

If a service n4 can't be called by separate services n2 and n3 in different parts of the tree (as shown in counterexample #2), then n4 isn't really a service but just a module of either n2 or n3 that happens to be behind a network interface.
Post reply on HN