Bipartite Workflow Graph for Microservice Compute Monitoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In microservice design architectures, monitoring and performance analysis of overall services composed of multiple independent microservices is challenging due to siloed approaches and the need for token passing, which can be unwieldy and create linear or tree-like chains, making it difficult to achieve a multi-hop understanding of the service and detect servicewide disruptions.
Innovation Solution
A bipartite workflow graph with 'processes' and 'entities' that can be defined as either processes or entities, using a universal schema, where each microservice can maintain its state through separately addressable execution units executing state machines, allowing for real-time metric collection and notification of servicewide disruptions without token passing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If a siloed approach is used to monitor each microservice individually, then each microservice can be understood within its own service boundaries, but an overall understanding of the service cannot be achieved and multi-hop understanding is lost
Solution Approach 1:
The patent merges individual microservice monitoring data into a unified workflow graph that represents the entire service. The workflow graph combines process nodes and entity nodes from multiple microservices into a single coherent structure, enabling holistic service understanding while maintaining individual service independence.
Solution Approach 2:
The patent introduces a workflow graph as an intermediary structure between individual microservices and the monitoring system. This workflow graph acts as a mediator that captures cross-service relationships and enables multi-hop understanding without requiring direct complex interactions between all microservices.
2Reliability
If token passing is used to track data exchanged between microservices, then data flow can be traced, but the mechanism becomes unwieldy when multiple microservices pass the same token and requires rigorous token passing
Solution Approach 1:
The patent extracts the token passing mechanism from the microservice implementation details and represents it at the workflow graph level. Instead of tracking individual tokens through multiple microservices, the workflow graph captures data flow relationships abstractly, eliminating the need for rigorous token passing while maintaining data flow traceability.
Solution Approach 2:
The patent inverts the approach by not tracking tokens through microservices, but rather defining workflows independently and then mapping microservices to these workflows. This inversion eliminates the unwieldy token passing problem while achieving the same data flow tracking goal.
3Loss of information
If a crawler mechanism is used to collect information from each microservice, then overall understanding can be pieced together, but the crawler must be informed of any changes to microservices or the understanding becomes invalid
Solution Approach 1:
The patent performs preliminary action by defining the complete workflow graph upfront based on service-level agreements and contracts. This workflow graph serves as a stable reference that doesn't require constant updates when individual microservices change, as long as their interfaces remain consistent.
Solution Approach 2:
The patent creates a universal workflow graph model that can represent any microservice architecture. This universal model adapts to changes in individual microservices without requiring fundamental changes to the monitoring approach, providing both service-wide insight and adaptability.
4Productivity
If microservices are designed to be independent and executable, then each microservice can be developed by different teams, but monitoring and performance analysis across multiple microservices becomes challenging
Solution Approach 1:
The patent adds another dimension to performance analysis by mapping microservice execution to a workflow graph that exists at a higher abstraction level. This dimensional shift enables performance analysis across multiple independent microservices without compromising their independence or development efficiency.
Data Source
AI summary
A bipartite workflow graph, representing an understanding of an overall service, comprises two different graph elements: entities and processes and each individual microservice defines their logical constructs as either an entity or a process in accordance with a universal schema. Notifications from such microservices conform to the universal schema, thereby enabling microservices to individually change how they operate internally, without affecting an understanding of the overall system as represented by the workflow graph. Each graph element has its state maintained by a separately addressable execution unit executing a state machine, which can be individually updated based on information received from the microservices. Changes to the workflow graph are logged and an insight engine monitors such a log to insert insight markers in accordance with predefined events, thereby enabling the collection of metrics on a service wide basis and across multiple microservices.