Microservices should form a polytree

A general pub/sub bus between all the nodes does generally encourage everything to become tangled together, for sure.

Take Counterexample #2. Add n5 as another arrow from n3. That looks like a legitimate use case to me.

Or DNS.

I think the article is just nonsense.

I think what the article is doing wrong is treating all microservices the same.

Microservices can be split into at least 3 different groups:

  - infrastructure (auth, messaging, storage etc.)
  - domain-specific business logic (user, orders)
  - orchestration (when a scenario requires coordination between different domains)

If we split it like this, it's evident that:

   - orchestration microservices should only call business logic microservices 
  - business logic microservices can only call infrastructure microservices
  - infra microservices are the smallest building blocks and should not call anything else

This avoids circular dependencies, decreases the height of the tree to 3 in most cases, and also allows to "break" the rule #2 in the article, because come on, no one is going to write several versions of auth just to make it a polytree.

It also becomes clearer what a microservice should focus on when it comes to resilience/fault tolerance in a distributed environment:

  - infra microservices must be most resilient to failure, because everyone depends on them
  - orchestration microservices should focus on compensating logic (compensating transactions/sagas)
  - business logic microservices focus on business logic and its correctness

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?