Application Graph Clustering for Explainable Microservice Refactoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current automated techniques for refactoring applications into microservices lack explainability, making it difficult for developers to trust and validate the output, as they do not provide clear reasons for the number of microservices chosen, how code functions are grouped, and the confidence in the selected architecture, leading to inefficiencies and errors in the refactoring process.
Innovation Solution
A method that constructs an application graph by analyzing transaction data, clusters nodes into microservices, identifies central nodes and feature importance, and provides edge importance to explain the refactoring decisions, allowing for automated refactoring with human oversight and confidence validation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If automated refactoring techniques are used to convert applications into microservices, then productivity is improved through automation, but reliability deteriorates due to lack of explainability and developer trust
Solution Approach 1:
The system provides feedback to developers by generating natural language explanations that describe why specific microservice boundaries were chosen, what code modules were grouped together, and the confidence levels in these decisions. This feedback loop allows developers to understand and validate the automated refactoring output, building trust while maintaining automation benefits
Solution Approach 2:
The patent introduces an intermediary layer (the explainability module) between the automated refactoring engine and the developer. This intermediary translates complex algorithmic decisions into human-understandable explanations, bridging the gap between automated processing and human trust
2Reliability
If detailed analysis and explainability features are added to provide transparency, then reliability is improved through developer validation, but device complexity increases
Solution Approach 1:
The system segments the refactoring process into distinct functional modules: the core refactoring engine that performs the actual code transformation, and the explainability module that generates human-readable explanations. This segmentation allows each module to specialize in its function without increasing overall system complexity
Solution Approach 2:
The explainability module acts as an intermediary layer that sits between the core refactoring engine and the developer interface. It translates complex internal decisions into simple explanations without requiring changes to the core refactoring logic, thus adding transparency without increasing fundamental system complexity
3Reliability
If manual review and validation processes are implemented to increase trust, then reliability is improved, but loss of time increases due to additional developer workload
Solution Approach 1:
The system applies partial action by providing targeted explanations only for the most important or uncertain refactoring decisions, rather than requiring manual review of every aspect. The confidence score mechanism allows developers to focus their time on decisions with lower confidence, while high-confidence decisions can be accepted automatically
Solution Approach 2:
The explainability features provide immediate feedback to developers about the rationale behind refactoring decisions, enabling rapid validation without extensive manual review. Developers can quickly assess whether the automated decisions are appropriate based on the provided explanations, reducing the time investment required for validation
Data Source
AI summary
By analyzing transaction data of an executing application, an application graph is constructed, the application graph comprising a plurality of nodes and a plurality of edges connecting pairs of the plurality of nodes, a node in the application graph corresponding to a module of the application. The plurality of nodes is clustered into a set of clusters. Formation of a cluster in the set of clusters is analyzed, the analyzing identifying a central node of the cluster, a feature importance in placing a node into the cluster, and an edge importance in placing the node into the cluster. Responsive to a confidence value in the cluster being above a threshold confidence value, using the central node of the cluster, the application is refactored into a set of microservices, the cluster corresponding to a microservice, the central node of the cluster corresponding to a component of the microservice.