# On Microservice Analysis and Architecture Evolution:
## 5 Results and Discussion
### RQ4: Future Research Directions
One outstanding challenge is prediction. For instance, since tuning configuration parameters can improve latency [36], researchers could look at the prediction of calls. Prediction of future system call could predict possible faults and learn from comparing the predicted system call and the actual to find specific patterns. Predictive models could helpto detect potential system bottlenecks and system capacity saturation for timely reactions to better handle such situations [12]. A trendy research topic is migration from monolithic applications to microservices. Since microservice-based applications have many desirable characteristics, a wide array of tools and methods that aid in the migration process would be extremely desirable. Further research into a way to accurately automate the process of decomposition with minimal impact by identifying potential candidate microservices would be of extreme significance for the industry. This would be beneficial because the current automated decomposition methods are either inaccurate or could have significant repercussions on the system, and human analysis is extremely time-consuming and sometimes leads to nowhere. A better-automated tool would allow companies to focus resources on further developing and improving their architecture. One specific problem in microservice migration has many names and deals with accurate system decomposition, service boundaries, or proper service cuts. Some suggest that there are too many characteristics (e.g., non-functional requirements [50]) to take into account and propose the task for artificial intelligence. However, it can be a dynamic problem of continuous microservice system re-modularization. The situation is complicated by new advancements such as serverless or micro-frontends; should they be considered, or does migration from monoliths ultimately lead to technical debt? Perhaps the core challenge is understanding how to develop microservice systems. Alternatively, perhaps we need better evaluation metrics to answer this challenge. One of the topics with great potential is software architecture reconstruction, especially its automation. Current approaches use static or dynamic analysis, but joint forces are inevitable since one deals well with decentralization and the other with a white-box view. Such system architecture can help with consistency checking and be the core artifact to refer to when dealing with evolution and technical debt. One challenge is proper visualization of the architecture or its perspectives. In the context of visualization, researchers challenged proper execution trace visualization or improved fault localization. Others challenged visualization for data-flow across the system, recognizing reads and writes. Furthermore, it could be used for modeling and simulation of an actual microservices-based application. With respect to technical debt, metrics for measuring debt are needed to quantify costs and benefits and support prioritization and decision-making. More investigation is needed on the relationship and composition between microservices availability tactics and microservices patterns. And some take the ambitious future goal to define an exhaustive and uniform catalog of microservices antipatterns. Finally, one of the greatest deficiencies in related research is the lack of benchmarks [45]. We need more microservice data sets to test the systems. These specifically need to represent industrial settings [45]. Furthermore, to support advancements, unification could occur, and researchers should develop theme-specific benchmarks, such as a unified benchmark for fault injections and anomaly detection where approaches can compare easily, similar to what is common in other disciplines.