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

111–120 of 121 posts

Re: Microservices should form a polytree

#111

Post by seanhunter »

Alupis wrote: post #97
lacker wrote: post #93

At first this sounds cool but I feel like it falls apart with a basic example. Let's say you're running a simple e-commerce site. You have some microservices, like, a payments microservice, a push notifications microservice, and a logging microservice. So what are the dependencies. You might want to send a push notification to a seller when they get a new payment, or if there's a dispute or something. You might want…

Is your example really a "triangle" though? If you have a broker/queue, and your services just push messages into the ether, there's no actual dependency going on between these services. Nothing should really depend on your logging service. They should push messages onto a bus and forget about them... ie. aren't even aware of the logging service's existence.

That example is still an undirected cycle so not a polytree and so, by the reasoning of the author of tfa not kosher for reasons they don’t really explain.

Honestly I think the author learned a bit of graph theory, thought polytrees are interesting and then here we are debating the resulting shower thought that has been turned into a blog post.

Re: Microservices should form a polytree

#112

Post by rco8786 »

jayd16 wrote: post #57
rco8786 wrote: post #22

Earlier quoted context omitted.

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

Ah, you don't mean enforce a novice making a mistake, you mean ensure from a design purity perspective? I don't think its true that you need requests to flow both ways. For example, if a downstream API needs more context from an upstream one, one solution is to pass that data down as a parameter. You don't need to allow the downstream services to independently loop back to gather more info.

Again, it depends on the business case. Software is simply too fluid to be able to architect any sort of complex system that guarantees an acyclic data flow forever.

Re: Microservices should form a polytree

#114

Post by sebastianconcpt »

lacker wrote: post #93

At first this sounds cool but I feel like it falls apart with a basic example. Let's say you're running a simple e-commerce site. You have some microservices, like, a payments microservice, a push notifications microservice, and a logging microservice. So what are the dependencies. You might want to send a push notification to a seller when they get a new payment, or if there's a dispute or something. You might want…

The issue is that one of the services is the events hub for the rest to remain in loose coupling (observer pattern).

The criticality of Kafka or any event queue/streams is that all depend on it like fish on having the ocean there. But between fishes, they can stay acyclicly dependent.

Re: Microservices should form a polytree

#115

Post by Scubabear68 »

gpm wrote: post #102
Scubabear68 wrote: post #94

Earlier quoted context omitted.

I don’t understand why you would have a logging microservice vs just having a library that provides logging that is used wherever you need logging.

Logs need to go somewhere to be collected, viewed, etc. You might outsource that, but if you don't it's a service of it's own (probably actually a collection of microservices, ingestion, a web server to view them, etc)

In my experience this is best done as an out of band flow in the background eg one of the zillion services that collect and aggregate logs.

Re: Microservices should form a polytree

#116

Post by whstl »

seanhunter wrote: post #111
Alupis wrote: post #97

Earlier quoted context omitted.

Is your example really a "triangle" though? If you have a broker/queue, and your services just push messages into the ether, there's no actual dependency going on between these services. Nothing should really depend on your logging service. They should push messages onto a bus and forget about them... ie. aren't even aware of the logging service's existence.

That example is still an undirected cycle so not a polytree and so, by the reasoning of the author of tfa not kosher for reasons they don’t really explain. Honestly I think the author learned a bit of graph theory, thought polytrees are interesting and then here we are debating the resulting shower thought that has been turned into a blog post.

That was my impression as well. There's pretty much no argument for why a DAG is worse than a polytree.

Re: Microservices should form a polytree

#117

Post by whstl »

solid_fuel wrote: post #68
jayd16 wrote: post #59

Earlier quoted context omitted.

Services handle the permissions of their own features. Authentication is handled at the gateway. Not sure if I agree its really the best way to do things but it can be done.

That implies that every service has a `user -> permissions` table, no? That seems to contradict the idea brought up elsewhere in the thread that microservices should all be the size of one table.

Well, depends on the permission model.

For RBAC or capability-based permissions, the gateway can enrich the request or the it can be in (eg) a JWT. Then each service only has to know how to map roles/capabilities to permissions.

For ABAC it depends on lots of things, but you often evaluate access based on user attributes and context (which once again can be added to the request or go into the JWT) plus resource attributes (which is already in the microservice anyway).

For ACL you would need a list of users indeed...

Something like Google Zanzibar can theoretically live on the gateway and apply rules to different routes. Dunno how it would deal with lists, though.

After writing it down: sounds like an awful lot of work for a lot of cases.

Btw: the rule for microservices that I know of, is that they must have their own database, not their own table.

Re: Microservices should form a polytree

#118

Post by jschorr »

whstl wrote: post #117
solid_fuel wrote: post #68

Earlier quoted context omitted.

That implies that every service has a `user -> permissions` table, no? That seems to contradict the idea brought up elsewhere in the thread that microservices should all be the size of one table.

Well, depends on the permission model. For RBAC or capability-based permissions, the gateway can enrich the request or the it can be in (eg) a JWT. Then each service only has to know how to map roles/capabilities to permissions. For ABAC it depends on lots of things, but you often evaluate access based on user attributes and context (which once again can be added to the request or go into the JWT) plus resource attri…

Dealing with lists is complicated with ReBAC, but possible. See my other comment on this: https://news.ycombinator.com/item?id=45662850

Re: Microservices should form a polytree

#119

Post by advisedwang »

spyspy wrote: post #65
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…

The trick is to have your gateway handle authn, and then proxy authz data upstream so those services can decide how to handle it without needing to make a second call to the identity service.

You probably want to have a UI for account creation and password resets, right? There's a frontend that has to talk directly to identity service.

You may want to bill based on # of active users - well that's interactive with the identity service (you can do this without billing calling the identity services' API, but the alternatives are just other common dependencies.

You may want a tool for the support team to search identity service to find a user or their account status.

If you have a sharing feature, you may want that to verify you are sharing with an account that exists.

Re: Microservices should form a polytree

#120

Post by spyspy »

advisedwang wrote: post #119
spyspy wrote: post #65

Earlier quoted context omitted.

The trick is to have your gateway handle authn, and then proxy authz data upstream so those services can decide how to handle it without needing to make a second call to the identity service.

You probably want to have a UI for account creation and password resets, right? There's a frontend that has to talk directly to identity service. You may want to bill based on # of active users - well that's interactive with the identity service (you can do this without billing calling the identity services' API, but the alternatives are just other common dependencies. You may want a tool for the support team to sear…

The way I've set these things up, nothing talks directly to the identity service. The ID service is a backend behind your gateway like any other service and any UI would have to have the request proxied through the gateway to reach it. Now, you can carve out certain rules (if you control the gateway) where requests headed to /users/* don't require the same authN steps other requests do because it's already headed to the ID server. Internal UIs may or may not work the same, that's really up to you - they won't likely be super high scale. Often the support teams won't even be querying the real DB, but instead a view or copy so they can't affect real user data. A share code for users A->B would just be a request from the UI to the ID server via the gateway, authenticated as User A, and responding with the code for B if possible. Or, I've do it where you could have special logic in the gateway to query 2 servers and combine the responses. No need for services to make requests sideways. Hope that makes sense.
Post reply on HN