4 ms·

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

waterproof 9mo ago
Yeah if services can't be used by multiple other services, then what's the point?
- spyspy 9mo ago
  Treating N4 as a service is fair. I think the article was leaning more toward that idea of N4 being a database, which is a legit bad idea with microservices (if fact defeating the point entirely). My takeaway is that if you're going to have a service that many other services depend on, you can do it but you need to be highly away of that brittleness. Your N4 service needs to be bulletproof. Netflix ran into this exact issue with their distributed cache.
- mon_ 9mo ago
  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.
  - PunchyHamster 9mo ago
    but why is having multiple paths to a service wrong ? The article just claims "it does bad things", without explaining how it does bad things and why it would be bad in that context.
deleted 9mo ago
[deleted]
davewritescode 9mo ago
There’s a million reasonable situations where this pattern could arise because of you want to encapsulate a domain behind a micro service. Take the simplest case of a CRM system a service provides search/segmentation and CRUD on top of customer lists. I can think of a million ways other services could use that data.
Alupis 9mo ago
There's no particular reason an Auth system must be designed like counterexample #2. There's many ways to design that system and avoid cycles. You can leverage caching of role information - propagated via messages/bus, JWT's with roles baked-in and IDP's you trust, etc. Hitting an Auth service for every request is chaotic and likely a source of issue.
- joshuamorton 9mo ago
  You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies. If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.
  - Alupis 9mo ago
    You shouldn't depend on the auth service, just subscribe to it's messages and/or trust your IDP's tokens. This article, in my interpretation, is about hard dependencies, not soft. Each of your services should have their own view of "the world". If they aren't able to auth/auth a request, it's rejected - as it should be, until they have the required information to accept the request (ie. broadcasted role information and/or an acceptable jwt).

waterproof 9mo ago

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

spyspy 9mo ago
Treating N4 as a service is fair. I think the article was leaning more toward that idea of N4 being a database, which is a legit bad idea with microservices (if fact defeating the point entirely). My takeaway is that if you're going to have a service that many other services depend on, you can do it but you need to be highly away of that brittleness. Your N4 service needs to be bulletproof. Netflix ran into this exact issue with their distributed cache.
mon_ 9mo ago
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.
- PunchyHamster 9mo ago
  but why is having multiple paths to a service wrong ? The article just claims "it does bad things", without explaining how it does bad things and why it would be bad in that context.

deleted 9mo ago

[deleted]

davewritescode 9mo ago

There’s a million reasonable situations where this pattern could arise because of you want to encapsulate a domain behind a micro service. Take the simplest case of a CRM system a service provides search/segmentation and CRUD on top of customer lists. I can think of a million ways other services could use that data.

Alupis 9mo ago

There's no particular reason an Auth system must be designed like counterexample #2. There's many ways to design that system and avoid cycles. You can leverage caching of role information - propagated via messages/bus, JWT's with roles baked-in and IDP's you trust, etc. Hitting an Auth service for every request is chaotic and likely a source of issue.

joshuamorton 9mo ago
You don't necessarily need to hit the auth service on every request, but every service will ultimately depend on the auth service somewhere in its dependencies. If you have two separate systems that depend on the auth system, and something depends on both, you have violated the polytree property.
- Alupis 9mo ago
  You shouldn't depend on the auth service, just subscribe to it's messages and/or trust your IDP's tokens. This article, in my interpretation, is about hard dependencies, not soft. Each of your services should have their own view of "the world". If they aren't able to auth/auth a request, it's rejected - as it should be, until they have the required information to accept the request (ie. broadcasted role information and/or an acceptable jwt).