Crisp: Critical Path Analysis for Microservice Architectures
eng.uber.comThe book in the course [1], specially ch. 4, I think, provides some analytical category-theoretical tools to model feasibility/performance in that kind of situation. In [2] the same technique (enriched profunctors) applies for critical path analysis in project management PERT diagrams. Looks to me (having just skimmed the Uber post) a very similar dependency structure.
[1] https://math.mit.edu/~dspivak/teaching/sp18/
[2] https://golem.ph.utexas.edu/category/2013/03/project_plannin...
Is the graph of microservice calls really necessarily acyclic with respect to the services themselves?
Certainly not limited to acyclic by pedantic definition, but it might be a reasonable assumption that they are acyclic if you limit yourself to non-buggy releases of real-world microservices.
Any true "cycle" would manifest as a "broken" backend (infinite loop), so may not be worth analyzing with a tool like this.
Some microservices may look like "cycles" depending on how you view them, but actually are "not" in the sense of how this tool sees them. Calls may bounce between microservices A/B/C, but never the exact same calls/state, so two slightly different endpoints/functions on a single microservice could be "seen" as two different microservices.
In other words, this tool analyzes granular contributions to the overall latency of request responses which have an overall latency less than infinity. That removes cyclic graphs.
If our vertices are (service, call) tuples, then a cycle seems clearly to be breakage. But if vertices are simply services, that's not necessarily the case, is it?
I agree completely, and this puts it much cleaner than I worded it.
Are those still microservices?