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

61–70 of 121 posts

Re: Microservices should form a polytree

#61

Post by jayd16 »

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…

Yeah even further, does that mean that SAAS like S3 shouldn't exist because it has multiple users?

I guess one possible solve would be to separate shared services into separate private deployments. Every upstream service gets its own imagine hosting service. Updates can roll out independently. I guess that would solve the blast radius/single source of failure problems but that seems really extreme.

Re: Microservices should form a polytree

#62

Post by 9rx »

nicodjimenez wrote: post #30
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.

It is simpler than that. You only want microservices in the same cases you want services (i.e. SaaS). Meaning, when your team benefits from an independent third-party building and maintaining it. The addition of "micro" to "service" indicates that you are reaching out to a third-party that is paid by the same company instead of paying a separate company.

Re: Microservices should form a polytree

#64

Post by jayd16 »

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…

> it really doesn't matter how they end up being connected.

I think you just mean that it should be robust to the many ways things end up being connected but it always does matter. There will always be a cost to being inefficient even if its ok to be.

Re: Microservices should form a polytree

#65

Post by spyspy »

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.

Re: Microservices should form a polytree

#66

Post by jayd16 »

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?

I always took it to be a minimum and that "micro" meant "we don't need to wait for a service to have enough features to exist. They can be small." Instead, people see it as a maximum and services should be as small as possible, which ends up being a mess.

Re: Microservices should form a polytree

#67

Post by mon_ »

waterproof wrote: post #53
henryfjordan wrote: post #39

Earlier quoted context omitted.

An AuthN/Z system would probably end looking like counterexample #2, which immediately raised a red flag for me about the article.

Yeah if services can't be used by multiple other services, then what's the point?

The article doesn't make that claim. For example, the service n7 is used by multiple other nodes, namely n3 and n4. There is no cycle there, so it's okay.

Re: Microservices should form a polytree

#68

Post by solid_fuel »

jayd16 wrote: post #59
Perz1val wrote: post #18

Rule #2 sounds dumb. If there can't be a single source of truth, for let's say permission checking, that multiple other services relay on, how would you solve that? Replicate it everywhere? Or do you allow for a new business requirement to cause massive refactors to just create a new root in your fancy graph?

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.

Re: Microservices should form a polytree

#69

Post by [deleted] »

henryfjordan wrote: post #39
muvlon wrote: post #31

Avoiding cyclic dependencies is good, sure. And they do name specific problems that can happen in counterexample #1. However, the reasoning as to why it can't be a general DAG and has to be restricted to a polytree is really tenuous. They basically just say counterexample #2 has the same issues with no real explanation. I don't think it does, it seems fine to me.

An AuthN/Z system would probably end looking like counterexample #2, which immediately raised a red flag for me about the article.

[deleted]

Re: Microservices should form a polytree

#70

Post by adrianco »

All sounds like a good plan, but there’s no easy way to enforce the lack of cycles. I’ve seen helper functions that call a service to look something up, called from a library that is running on the service itself. So a service calls itself. There was probably four or five different developers code abstractions stacked in that loop.
Post reply on HN