# Assessing Evolution of Microservices Using Static Analysis
## 5 Discussion and Answers to RQs  
This study adopts a centric perspective to examine the architectural evolution of microservices using their service and data viewpoints. In pursuit of this objective, a set  
Figure 8: Matrix visualization for data view of TrainTicket v1.0.0. Figure 7: Matrix visualization for service view of TrainTicket v1.0.0. of seven metrics is introduced and employed to quantify diverse properties within these two viewpoints. Two metrics focus on aspects of the service view, such as microservice count and inter-service connections (addressing RQ1), while five metrics pertain to the data view, including data entity types and relationships, including duplicates across different bounded contexts (addressing RQ2). As a result, these metrics offer valuable insights into elucidating the system's evolution. Furthermore, the study leverages intermediate representations derived from the system's source code for these two views. These representations can be analyzed to extract metrics and visually presented using customized techniques for deeper exploration and reasoning. The primary aim is to facilitate practitioners' exploration and understanding of the system's central properties. **Metrics as Indicators. ** The significance of these metrics lies in their ability to serve as indicators of system evolution, offering insights across various dimensions. While the metrics provide indicators about the relative changes when compared across different versions, they also play a vital role in exploring relationships between different metrics within the same version. This enables the reasoning about specific system features and the detection of patterns within the system, as demonstrated in the case study. **Metric Granularity. ** The proposed metrics present abstract indicators of the holistic perspective of service and data viewpoints, and their granularity can be tailored to different levels within the system. This granularity can be examined at the individual microservice level, allowing the metrics to indicate correlations between microservices within the same version and a single microservice across multiple versions. Furthermore, the granularity can be extended from a technological standpoint, considering the polyglot architecture of microservice systems utilizing various programming languages and technologies. These metrics can offer insight into the evolution of service and data viewpoints in an additional dimension of heterogeneity. At the same time, granularity can be fine-tuned for each individual metric. For example, the metric of the number of persistent data entities (\(\#PDE_{s}\)) can be further divided into relational and non-relational data entities, as demonstrated in the case study. However, this study has chosen the current level of granularity to provide a direct indicator of persistence, with the option to explore different types if the metric values indicate the need for further investigation. A similar granularity approach can be applied to the metric of the number of microservice connections (\(\#C\mu\)), differentiating between synchronous and asynchronous calls, depending on the specific analysis requirements. **Intermediate Representation Extension. ** The proposed intermediate representations of the system views contain essential information used for metric extraction and viewpoint visualization. While the proposed methodology primarily employs static source code analysis, dynamic analysis is another valuable technique. Dynamic analysis involves runtime data, which can construct the service viewpoint from the execution perspective. Previous studies have utilized dynamic analysis to extract the service view based on remote procedure calls gathered from logs and traces and to detect anomalies in microservice-based systems [42; 43]. Therefore, extending the intermediate representation to include dynamic data analysis alongside the static representation, particularly for the service view, can offer additional metrics to illustrate the system's runtime behavior evolution.