Hacker News Reader

Comment by muvlon | Hacker News Reader

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.

View on HN

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?

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.

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.

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.

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.

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.

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.

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).

Suppose we were critiquing an article that was advocating the health benefits of black coffee consumption, say, we might raise eyebrows or immediately close the tab without further comment if a claim was not backed up by any supporting evidence (e.g. some peer reviewed article with clinical trials or longitudinal study and statistical analysis).

Ideally, for this kind of theorising we could devise testable falsifiable hypotheses, run experiments controlling for confounding factors (challenging, given microservices are _attempting_ to solve joint technical-orgchart problems), and learn from experiments to see if the data supports or rejects our various hypotheses. I.e. something resembling the scientific method.

Alas, it is clearly cost prohibitive to attempt such experiments to experimentally test the impacts of proposed rules for constraining enterprise-scale microservice (or macroservice) topologies.

The last enterprise project I worked on was roughly adding one new orchestration macroservice atop the existing mass of production macroservices. The budget to get that one service into production might have been around $25m. Maybe double that to account for supporting changes that also needed to be made across various existing services. Maybe double it again for coordination overhead, reqs work, integrated testing.

In a similar environment, maybe it'd cost $1b-$10b to run an experiment comparing different strategies for microservice topologies (i.e. actually designing and building two different variants of the overall system and operating them both for 5 years, measuring enough organisational and technical metrics, then trying to see if we could learn anything...).

Anyone know of any results or data from something resembling a scientific method applied to this topic?

Came here to say the same thing. A general-purpose microservice that handles authentication or sends user notifications would be prohibited by this restriction.

Or DNS.

I think the article is just nonsense.

Reply on news.ycombinator.com