3 ms·

Its an insightful read and the final graph analogy seems very apposite. But here is the rub: if microservices is a general graph pattern, it includes all the ot

Its an insightful read and the final graph analogy seems very apposite. But here is the rub: if microservices is a general graph pattern, it includes all the other patterns (likear, hub and spoke etc) as these are all just particular graphs. In other words, you could implememt unix pipe like or plugin like microservices by applying certain constraints.

Nevermark 3y ago
Right, but implementing a restricted domain (pipes) with tools designed for a more general domain (graphs), gives up the efficiencies and reduced complexity of the restricted domain. That is why we have restricted domains.
- nologic01 3y ago
  The efficiency argument depends a bit on the scope one considers. If you only ever need pipes it makes sense to optimize and learn how to build pipes and your toolkit will reflect that. But if you need a variety of patterns you need to weigh in the inefficiency and cost of switching. The analogy would be a multi-purpose tool versus many special purpose ones (and the knowledge of operating each). This is all theoretical ofcourse, but my sense is that the debate about microservices is colored first of all by the extra complexity of networked computation (which raises the bar for a succesful architecture) and maybe indeed the absence of well defined constraints that would guide people on different possible best practices for segmenting monoliths.
lelanthran 3y ago
Is that relevant, though? An undirected cyclic graph is a superset of all other data structures[1], yet we still differentiate between them and choose the most suitable. [1] And can be used to build all other data structures. A tree is a directed acyclic graph, a list is a tree with no more than one child per node, etc
- nologic01 3y ago
  The proof would be in eating the pudding, but the thrust of the argument would be to indeed recognize that "microservices" is too general a pattern and one might benefit and make them more usable by developing tailored patterns (imposing constraints adapted to the data exchanges that dominate the application). Its just a thought sparked by that interesting diagram at the end of the post and motivated by the fact that the REST architecture is also specified as a set of constraints...

Nevermark 3y ago

Right, but implementing a restricted domain (pipes) with tools designed for a more general domain (graphs), gives up the efficiencies and reduced complexity of the restricted domain. That is why we have restricted domains.

nologic01 3y ago
The efficiency argument depends a bit on the scope one considers. If you only ever need pipes it makes sense to optimize and learn how to build pipes and your toolkit will reflect that. But if you need a variety of patterns you need to weigh in the inefficiency and cost of switching. The analogy would be a multi-purpose tool versus many special purpose ones (and the knowledge of operating each). This is all theoretical ofcourse, but my sense is that the debate about microservices is colored first of all by the extra complexity of networked computation (which raises the bar for a succesful architecture) and maybe indeed the absence of well defined constraints that would guide people on different possible best practices for segmenting monoliths.

lelanthran 3y ago

Is that relevant, though? An undirected cyclic graph is a superset of all other data structures[1], yet we still differentiate between them and choose the most suitable. [1] And can be used to build all other data structures. A tree is a directed acyclic graph, a list is a tree with no more than one child per node, etc

nologic01 3y ago
The proof would be in eating the pudding, but the thrust of the argument would be to indeed recognize that "microservices" is too general a pattern and one might benefit and make them more usable by developing tailored patterns (imposing constraints adapted to the data exchanges that dominate the application). Its just a thought sparked by that interesting diagram at the end of the post and motivated by the fact that the REST architecture is also specified as a set of constraints...