# Fostering Microservice Maintainability Assurance through a Comprehensive
Framework

Amr S. Abdelfattah  Computer Science Department
Baylor University
Waco, TX, USA
<EMAIL_ADDRESS>
###### Abstract

Cloud-native systems represent a significant leap in constructing scalable,
large systems, employing microservice architecture as a key element in
developing distributed systems through self-contained components. However, the
decentralized nature of these systems, characterized by separate source codes
and deployments, introduces chal- lenges in assessing system qualities.
Microservice-based systems, with their inherent complexity and the need for
coordinated changes across multiple microservices, lack established best
practices and guidelines, leading to difficulties in constructing and
comprehending the holistic system view. This gap can result in performance
degrada- tion and increased maintenance costs, potentially requiring system
refactoring. The main goal of this project is to offer maintainability
assurance for microservice practi- tioners. It introduces an automated
assessment framework tailored to microservice architecture, enhancing
practitioners’ understanding and analytical capabilities of the multiple
system perspectives. The framework addresses various granularity levels, from
artifacts to constructing holistic views of static and dynamic system
characteristics. It integrates diverse perspectives, encompassing human-
centric elements like architec- tural visualization and automated evaluations,
including coupling detection, testing coverage measurement, and semantic clone
identification. Validation studies involving practitioners demonstrate the
framework’s effectiveness in addressing diverse quality and maintainability
issues, revealing insights not apparent when analyzing individual
microservices in isolation.

###### Index Terms:

Software Evolution, Metrics, Software Architecture Reconstruction, Viewpoints,
Software Architecture

##  I Introduction

Microservice architecture is commonly employed in complex systems,
facilitating selective scalability and decomposing intricate organizational
structures into smaller, self-contained, independently managed units. These
units are then overseen by separate development teams. It becomes critical to
understand the architecture of such systems to effectively evolve them. System
evolution is inevitable, driven by various factors such as new market demands,
technological shifts, and optimization efforts. This evolutionary process
often involves new features, resolving bugs, and potentially introducing new
services with their respective data models and system dependencies.

However, due to the decentralized nature of this evolution, which spreads
across semi-autonomous teams, the holistic system-centric architectural
perspective is often lost [bogner2021industry]. Moreover, individual teams may
inadvertently make suboptimal design choices, leading to inefficiencies that
affect the overall system. Consequently, system architecture may degrade over
changes as system complexity increases.

To address these challenges, specifically the absence of a system-centered
view, signified by a lack of assessment and reasoning mechanisms in system
evolution, we propose constructing a centralized perspective of the system’s
architecture while deriving quantifiable metrics across system versions from
such perspectives to trace the system evolution and impact of changes to
individual microservices.

Software architecture can be described by various viewpoints
[isoiecieee42010]. A viewpoint represents a set of conventions for creating,
interpreting, and utilizing an architectural view to address specific
concerns. For microservices, literature proposed service and domain viewpoints
to describe the system holistic perspective [8417116,
10.1007/978-3-030-49418-6_21, abdelfattah2023comparing]. While these
viewpoints are used to explain the overall system architecture, they have not
been used to assess system evolution.

The main objective of this paper is to adopt service and domain viewpoints and
translate them into quantifiable metrics to trace microservice system
evolution and individual change impact across miroservices. These metrics
serve as measures for understanding the system’s evolution in response to
changes. Furthermore, we introduce a visualization approach for these
perspectives to assess their effectiveness in understanding the system’s
evolution.

This paper addresses the following research questions (RQs):

RQ1 _How to assess the evolution of service viewpoint?_
RQ2 _How to assess the evolution of domain viewpoint?_

This work showcases a comprehensive case study with a practical application of
the proposed metrics in the context of system evolution analysis. The case
study employs a variety of approaches to demonstrate the underlying reasons
driving the evolution of systems across various releases. The contributions of
this paper can be summarized as follows:

  * •

Introduction and definition of seven system-centric metrics.

  * •

Explanation of the automated metric extraction methods.

  * •

Provision of Java-based prototype calculating and reporting the metrics.

  * •

Providing a prototype for visualizing architectural views for the service and
domain viewpoints.

  * •

Publishing a dataset that contains the extracted data from both viewpoints of
a testbench.

  * •

Conducting a case study to interpret the metrics’ results.

The rest of this paper is organized as follows: Section II explains the
related works. In Section III, the paper details the methodology used for
metric extraction and the visualization of viewpoint representations. Section
IV focuses on the case study and the presentation of its results. Section V
extends the case study to offer reasoning on evolution analysis. Section VI
delves into the RQs answers and discussion of the implications and potential
extensions of the methodology. Section VII highlights potential threats to the
validity of the research. Section VIII concludes the study.

##  II Related Work

The evolution of microservice architecture brings up multifaceted challenges
across various dimensions of the system. To proactively identify and mitigate
potential errors, gaining a comprehensive understanding of how the system
evolves with each change becomes imperative. Consequently, multiple studies
have introduced diverse approaches and metrics aimed at comprehending the
system and its intricate perspectives.

Various studies have introduced SAR techniques that enable the extraction of
viewpoints from the system. Maffort et al. [maffort2016mining] employ static
analysis coupled with reflection modeling to create a high-level model that
depicts architectural components and data/control flows. Soldani et al.
[soldani2021mutosca] analyze Docker configurations to grasp the microservice
deployment topology, providing insights into component interactions.
Additionally, various studies [richner1999recovering, riva2002combining,
huang2006runtime] combine static and dynamic analysis to furnish both static
and dynamic viewpoints, facilitating comprehensive architecture
reconstruction.

However, while these studies have proposed approaches to reconstruct different
system perspectives, they often overlook the critical aspect of system
evolution. For instance, Mayer et al. [mayer2018approach] address system
evolution by considering snapshots of the current architecture, yet they do
not consider the dynamic evolution of microservices over time. Moreover,
Sampaio et al. [sampaio2017supporting] propose an approach that leverages both
static and dynamic information to generate a representation of evolving
microservice systems based on service evolution modeling.

The evolution of microservice architecture significantly impacts the cohesion
and coupling of system components. Several studies have introduced metrics
designed to assess these critical features of the system. For instance, de
Freitas et al. [de2020towards] emphasize metrics at both the individual
service level and in aggregate. These metrics delve into the frequency of
interactions between microservices, patterns of relationships formed through
these interactions, the equilibrium of dependencies across services, and the
significance of each service within the architecture. Meanwhile, Moreira et
al. [moreira2022analysis] propose three metrics that focus on the internal
perspective of services, assessing aspects such as the consistency in
parameters and return types across exposed interfaces, internal cohesion based
on inputs and outputs, and the overall cohesion within a service reflecting
unity in its operational implementations.

On the other hand, visualization plays a crucial role in conveying the
evolution to human experts, enabling them to analyze and reason effectively.
Rahman et al. [rahman2019curated] introduced MicroDepGraph, a tool presenting
connected services, plotting the dependency graph of microservices. However,
it lacks the ability to distinguish different service types effectively.
Oberhauser et al. [oberhauser2019vr] proposed a virtual reality (VR) solution
for immersive visualization of large-scale enterprise system architecture.
Cerny et al. [cerny2022microvision] introduced a 3D augmented reality method
for microservice data visualization, enhancing scalability and navigation.
Abdelfattah et al. [abdelfattah2023microservice] demonstrated dependency
matrix visualization for showcasing service and data dependencies among
microservices pairs in the system.

The proposed methods in existing literature have limitations when it comes to
reconstructing abstract system-centric views directly from the source code. In
contrast, this paper presents the construction and utilization of these views,
which are subsequently visualized and mined to extract comprehensive metrics
that provide an insightful perspective on the entire system. This approach
enables a more profound understanding of microservice architecture evolution
and enhances the capacity for reasoning about it.

##  III The Proposed Centric Metrics

The two viewpoints we consider in this work are the service and domain
viewpoints focused on relevant concerns of services and the domain.
Consequently, an architecture view is a collection of models representing the
system architecture relative to a set of architectural concerns. In
particular, the service view constructs service models specifying
microservices, endpoints, and interactions. This essential view provides the
system’s holistic perspective [mayer_weinreich_dashboard] is used to explain
the system dependencies and the overall microservice ecosystem, and becomes
useful when assessing potential ripple effects during microservice evolution
[bogner2021]. Similarly, the data view from the domain viewpoint uses data
models to explain which data are used by which microservice and their
interconnection. We can highlight the presence of data entity overlaps, which
signifies a coupling between particular services. While these views are used
to explain the overall system architecture, they have not been used to assess
system evolution.

The evolution of the system’s architecture is a direct consequence of the
modifications made to the source code. Source code modifications predominantly
influence both the service and data views. The addition or removal of
microservices, endpoints, and inter-service calls significantly impacts the
service view. Furthermore, an examination of the data model highlights the
duplication of data items within different bounded contexts of microservices.
Notably, the presence of multiple data item duplications in various
microservices signifies a coupling between those services.

While architecture viewpoints serve as a frame of reference for addressing
concerns pertinent to the architecture description’s purpose
[isoiecieee42010], this approach utilizes Software Architecture Reconstruction
(SAR) [guo1999software, abdelfattah2023roadmap] for microservices to generate
service and data views corresponding to particular viewpoints. Consequently,
analyzing these views yields a timeline of the system’s evolution,
facilitating an understanding of the motivations behind modifications and the
broader impact of these changes.

Objective: This methodology introduces seven convenient and automated metrics
derived and adapted from both the service (S1, S2) and data (D1-D5) views.
These metrics are designed to quantify changes within both aspects of the
architecture to serve as indicators of the system’s main development stream
and offer early insights into potential architectural degradation. Moreover,
these metrics provide a centralized explanation of system properties. They can
be tracked across different versions of the system to ensure that system
properties align with the changes made in each version. Practitioners can
create a timeline of these metrics, illustrating how system attributes evolve
across various versions. Additionally, this approach offers visual
representations of both views, annotating the reasoning process for
practitioners and enabling them to visually investigate specific aspects of
the system from a centralized perspective.

###  III-A Intermediate Representation Construction

Figure 1: Service and Data Model Views Construction.

This methodology applies SAR by leveraging static code analysis techniques to
construct the service view and data model of the data view from the source
code.

The methodology commences by iteratively examining the project folders within
the system to identify standalone projects as microservices. This can be
achieved through parsing specific deployment or configuration scripts found in
the project folders, such as Docker Compose deployment files. Once identified,
we harness the source code of each microservice to create the corresponding
views.

####  III-A1 Service View Construction

The construction of the service view follows a two-phase process, as depicted
in Fig. 1 (Upper Part). In the first phase, known as Inter-service Detection,
we employ static analysis to extract endpoint declarations and endpoint
requests initiated within the source code. In the second phase, referred to as
Signature Matching, we employ a regex-like approach to match requests to their
corresponding endpoints across different microservices. This matching process
considers attributes of endpoints and requests, including endpoint paths,
parameters, and HTTP method types, ultimately identifying connections between
the source and destination microservices. The extracted information is
represented as an intermediate representation (IR) of the service view.

####  III-A2 Data Model View Construction

The construction of the data model view comprises three phases, as illustrated
in Fig. 1 (Lower Part). The first phase, termed Components Detection, involves
identifying classes and their attributes within the source code. In the second
phase, known as Entity Filtering, we select the data entities among the
extracted class components. Then, we distinguish data entities, both
persistent and transient. Transient entities are identified based on
attributes such as setters and getters, which are used in the responses of
endpoint methods. Additionally, entity relationships are identified from
attribute fields that reference other entities within the system. The third
phase, termed Entity Merging, identifies entities that are candidates for
merging from different microservices based on similar names and matching data
types between their fields. The resulting information is represented as an
intermediate representation (IR) of the data model view.

####  III-A3 Intermediate Representation Formulization

The two intermediate representations constructed from both views encompass
vital attributes for depicting the system’s inter-connections and data
dependencies. These attributes can be expressed using the following notations:

$S=\\{ms_{1},ms_{2},\cdots,ms_{n}\\}\text{; }ms_{i}=\langle
E_{i},C_{i},D_{p_{i}},D_{t_{i}}\rangle$ $E_{i}=\\{\langle
u_{j},r_{j},P_{j}\rangle,\cdots\\}\text{; }C_{i}=\\{\langle
ms_{j},u_{k},r_{k},P_{k}\rangle,\cdots\\}\text{; }$ $D_{p_{i}}=\\{\langle
F_{j},R_{ij}\rangle,\cdots\\}\text{; }D_{t_{i}}=\\{\langle
F_{j},R_{ij}\rangle,\cdots\\}$ $P=\\{\langle t,n\rangle,\cdots\ \\}\text{;
}F_{i}=\\{\langle t,n\rangle,\cdots\ \\}$ S  \- Microservice system,  $ms_{i}$
\- Single microservice.
$E_{i}$ \- Endpoints defined in the microservice $ms_{i}$
$C_{i}$ \- Calls made from the microservice $ms_{i}$ to all other
microservices.
$D{p_{i}}$ \- Persistent data entities in the microservice $ms_{i}$.
$D{t_{i}}$ \- Transient data entities in the microservice $ms_{i}$.
$R_{j}$ \- Relationships that start from a data entity $j$ to other entities.
$F_{j}$ \- Fields in a data entity $j$.
$P$ \- Parameters in an endpoint or in a call.
$u$ \- URL path.  $r$ \- Return type.  $t$ \- Field date type.  $n$ \- Field
name.

The constructed views and their properties can be elucidated by categorizing
the mentioned main five sets of extracted attributes. The process begins with
a microservice system as input and subsequently analyzes the system to yield
the following sets of attributes per each microservice. Firstly, a set of
endpoints ($E$) introduced within each microservice. Secondly, a set of
request calls ($C$) initiated from each microservice towards endpoints in
other microservices. Lastly, the system yields two sets of data entities: one
for the persistent data entities ($D_{p}$) and the other for the transient
data entities ($D_{t}$).

###  III-B Metrics Definition

The seven proposed metrics utilize centralized attributes extracted from the
system. Metrics S1 and S2 pertain to the service view, while metrics D1
through D5 are associated with the domain view. They quantify the following
attributes to describe a centric perspective of the microservice system and to
assist in the reasoning about its evolution.

S1:

Number of Microservices ($\\#\mu_{s}$).
Description: The count of microservices in the system.
Value: $\\#\mu_{s}=|S|$.
Goal: Provides a quantitative measure of the system’s scale or complexity in
terms of microservices.
Motivation: Provides insights into the system’s modularity evolution by
showing expansions or contractions in high-level components between subsequent
versions and releases.

S2:

Number of Microservices Connections ($\\#C\mu_{s}$).
Description: Number of endpoint calls between microservices in the system.
Value: $\sum_{i=1}^{n}|C_{i}|$; where $n=|S|$.
Goal: Provides a measure of the communication intensity between microservices
in the system.
Motivation: Reveals changes in the dependency view across system releases and
identifies potential bottlenecks, such as excessive connections to a single
service.

D1:

Number of Persistent Data Entities ($\\#PDE_{s}$).
Description: The count of relational and non-relational persistent data
entities in the system.
Value: $\sum_{i=1}^{n}|D_{p_{i}}|$; where $n=|S|$.
Goal: Provides insight into the scale of persistent data entities within the
system.
Motivation: Provides insights into the data perspective, such as the storage
approaches per each microservices. In addition to the domain model, modularity
changes throughout the system releases.

D2:

Number of Transient Data Entities ($\\#TDE_{s}$).
Description: Number of data entities used as data transfer objects across
microservices (not persistent in storage).
Value: $\sum_{i=1}^{n}|D_{t_{i}}|$; where $n=|S|$.
Goal: Provides an indication of the usage scale of data transfer objects
(DTOs) across microservices.
Motivation: Illustrates the evolution of additional entities created for
customizing responses and data transfer purposes but not involved in domain
logic. It indicates whether each microservice consumes or delivers more data
models to others.

D3:

Number of Relationships between Data Entities ($\\#RDE_{s}$).
Description: The count of relationships between data entities in each
microservice’s data model.
Value: $|MR|/2$; Such that,
$MR=\bigcup_{i=1}^{n}\bigcup_{j=1}^{m}\\{r,f(r)\ |\
r\in\bigcup_{l}R_{ijl}\\}$; where $n=|S|$, $m=|D_{p_{i}}|+|D_{t_{i}}|$, $f(r)$
is a function that reverses relationships to prevent duplicate counting of
both the relationship and its reverse counterpart.
Goal: Provides a measure of the complexity and interconnectedness of data
entities within each microservice’s data model.
Motivation: Demonstrates the evolution of data model complexity and the
presence of cohesive models within each microservice over different releases.

D4:

Number of Merge Candidates Data Entities ($\\#MDE_{s}$).
Description: The count of entities duplicated in multiple bounded contexts.
These entities may retain different fields based on the purpose of each
bounded context.
Value: $(\sum_{i=1}^{n}|Dp_{i}|+|Dt_{i}|)-|DE|$; where
$DE=\\{f_{d}(d)\ |\ d\in\bigcup_{i=1}^{n}Dp_{i}+Dt_{i}\\}$,
$n=|S|$, $f_{d}(d)$ is a function that receives an entity and returns the
corresponding entity after the Entity Merging phase; it is defined as

$f_{d}(d)=\begin{cases}d\quad&\text{if}\,d\ \text{not merged}\\\
d^{\prime}\quad&\text{if}\,d\ \text{was merged into}\ d^{\prime}\\\
\end{cases}$

Goal: Provides insight into the level of duplication across bounded contexts,
highlighting potential opportunities for consolidation or optimization.
Motivation: Shows bounded context changes over system evolution; it reveals
data dependencies among microservices.

D5:

Number of Merge Candidates Relationships between Data Entities
($\\#MRDE_{s}$).
Description: The count of relationships that are candidate for merging based
on the merge candidates between entities ($\\#MDE_{s}$).
Value: $(\sum_{i=1}^{n}\sum_{j=1}^{m}|R_{ij}|)-|RDE|$; where
$RDE=\\{f_{r}(r)\ |\ r\in\bigcup_{i=1}^{n}\bigcup_{j=1}^{m}R_{ij}\\}$,
$n=|S|$, $m=|D_{p_{i}}|+|D_{t_{i}}|$, $f_{r}(r)$ is a function that receive an
relationship and returns the corresponding relationship after the Entity
Merging phase, it is defined as

$f_{r}(r)=\begin{cases}r\quad&\text{if}\,r\ \text{not merged}\\\
r^{\prime}\quad&\text{if}\,r\ \text{was merged into}\ r^{\prime}\\\
\end{cases}$

Goal: Provides an indication of potential opportunities for merging
relationships between entities, based on identified merge candidates.
Motivation: Provides a holistic data model view of the microservice system and
showcases changes in data fragments across different system releases.

###  III-C Demonstrating Example

This section provides an example to illustrate the proposed metrics. The
example consists of four microservices (MS-1 $\cdots$ MS-4), where each
microservice contains data entities, either persistent (P) or transient (T).
These entities have relationships with each other, and the connections between
microservices are depicted with arrows linking two transient entities that
facilitate data transfer through these connections. Refer to Fig. 2 for a
visual representation of this example.

Regarding the metrics related to the service view, we can observe that the
number of microservices in the system is four ($\\#\mu_{s}=4$). Additionally,
there are three request calls ($\\#C\mu_{s}=3$), which occur as follows: MS-1
$\rightarrow$ MS-2, MS-3 $\rightarrow$ MS-2, and MS-4 $\rightarrow$ MS-2.

In the context of data view metrics, there are 12 persistent data entities
($\\#PDE_{s}=12$). Specifically, MS-1 through MS-4 contain three, four, two,
and three persistent data entities, respectively. On the other hand, there are
five transient data entities ($\\#TDE_{s}=5$). MS-2 has two transient data
entities, while other microservices have one each. Furthermore, there are 14
relationships between these data entities ($\\#RDE_{s}=14$): three
relationships for each of MS-1 and MS-4, six relationships in MS-2, and two
relationships in MS-3.

To illustrate the two metrics related to merge candidates, we demonstrated an
entity merging process to identify potential merge candidates between data
entities, as depicted in Fig. 3. These resulting entities were generated by
tracing the connections between transient data entities among microservices
and the relationships between these transient and persistent data entities. In
these two figures, entities with the same color represent similar entities
that exist in multiple microservices’ bounded contexts. By merging these
similar entities into a single entity, the total number of data entity merge
candidates is four ($\\#MDE_{s}=4$). These candidates are (T-1.1 & T-2.1),
(P-1.3 & P-2.1), (P-2.3 & T-3.2), and (P-2.4 & P-4.1). Additionally, there are
one relationship merge candidate ($\\#MRDE_{s}=1$), which is produced of merge
of the relationship between (T-1.1 & P-1.3) and (T-2.1 & P-2.1). These two
relationships were merged because the merging process occurred in both of the
entities they connected (T-1.1 & T-2.1) and (P-1.3 & P-2.1).

Figure 2: Demonstrating example for metrics.
(P: Persistent Entity, T: Transient Entity).

###  III-D Intermediate Representation Visualization

An essential component of the extracted information and the constructed
intermediate representations lies in facilitating human-centered reasoning
about the overall system. This approach to human-centered reasoning relies on
visualization techniques to explore various facets of the system
[mayer2018approach].

Moreover, the challenge of rendering space becomes crucial when visualizing
microservices architecture and its associated views [visualization_16]. In
particular, visualizing the service view poses more intricate challenges due
to its need to provide an overview of holistic, large, and scalable systems.
To address this, we employ a three-dimensional visualization approach to
present the service view intermediate representation. The three-dimensional
display offers more rendering space, reducing the overlap among service
connections. Additionally, our visualization allows for interactivity,
enabling users to select nodes to highlight nodes that are invoked by the
selected node. Furthermore, we employ a color-coding scheme for microservices
nodes, differentiating them based on their number of dependencies in
comparison to a predefined value.

Conversely, for visualizing the data view, the class diagram is an apt choice.
It displays the fields of each entity and their relationships. Our proposed
visualization adapts the spatial representation by incorporating horizontal
scrolling within a 2D space, allowing easy navigation through all system
entities. To create a comprehensive data model, this methodology combines the
entities identified as merge candidates ($\\#MDE_{s}$) and the relationships
indicated as merge candidate relationships ($\\#MRDE_{s}$) into the model.
This process results in the construction and visualization of a holistic
context map for the entire system.

These visual representations are instrumental in supporting the process of
analyzing system evolution. They offer visual-centric perspectives of the
system, aiding in the understanding of architectural changes as the system
evolves.

Figure 3: Entity Merging in the demonstrating example.
(P: Persistent Entity, T: Transient Entity).

##  IV Case Study

This section showcases the application of our proposed methodology to
facilitate reasoning about system evolution. While the proposed metrics
provide insights into central system perspectives, they do not inherently
reveal the underlying reasons for variations between different system
versions. Consequently, these metric values serve as indicators, prompting
architects and practitioners to explore the drivers of system changes.
Therefore, centralized system view visualizations play a pivotal role as an
instrument for enabling practitioners to delve into the causes behind the
metric fluctuations.

We have implemented the proposed metrics and visualizations in a prototype and
applied them to an open-source testbench to assess and discuss its
architectural evolution characteristics. This case study serves the following
objectives:

  * •

Evaluating the feasibility of applying the proposed metrics to a real-life
system.

  * •

Emphasizing the significance of the proposed metric measurements in guiding
practitioners to investigate specific aspects of the system.

  * •

Demonstrating the role of visualizations in presenting holistic views of the
entire system.

###  IV-A TestBench

We utilized a TrainTicket [trainticket] microservice testbench to demonstrate
the case study. It is commonly used in the research community as a
representative of real-life systems. It is implemented using Java-based Spring
Boot framework111Spring Boot: https://spring.io/projects/spring-boot, it
contains a couple of Python microservices. Its repository contains seven
releases (at the time of this paper written). To demonstrate the evolution
impact on the system architecture, this case study selects the following three
different releases (versions): v0.0.1222v0.0.1:
https://github.com/FudanSELab/train-ticket/tree/0.0.1, v0.2.03330.2.0:
https://github.com/FudanSELab/train-ticket/tree/v0.2.0, and v1.0.0444v1.0.0:
https://github.com/FudanSELab/train-ticket/tree/v1.0.0. Those versions show a
progressive evolution of the system starting from the first release (v0.0.1)
until the current latest release (v1.0.0).

###  IV-B Prototype Implementation

We implemented the proposed approach in a prototype555Prototype: Censored for
the blind review.. It is built for analyzing Java-based microservices projects
that use the Spring Boot framework. It utilized static source code analysis
techniques to extract the data necessary for calculating the metrics and also
for constructing the intermediate representations of the service view and data
view. The extracted data is published at an online dataset666Dataset:
https://zenodo.org/records/10052375.

It accepts its input as a GitHub repository containing microservices-based
projects. It scans each microservice for finding the Spring Boot REST client
(i.e., RestTemplate client) to detect HTTP calls between the services. It
matches the detected calls with the endpoints. Moreover, it extracts the
bounded context data model of the individual microservices. It scans all local
classes in the project using a source code analyzer. To filter this list down
to classes serving as persistent and transient data entities, it checks for
persistence annotations (i.e., JPA standard entity annotations such as @Entity
and @Document), and also, for annotations from Lombok777Lombok:
https://projectlombok.org (i.e., @Data), a tool for automatically creating
entity objects. To check merge candidates, it uses the WS4J 888WS4J:
https://github.com/Sciss/ws4j project, which uses the WordNet project
[wordnet] to detect name and fields similarity. This prototype outputs a JSON
representation for the service and data views intermediate representations.

Moreover, we implemented the 3D visualizer999Visualizer: Censored for the
blind review. to present the constructed intermediate representations. It uses
ThreeJS101010three.js: https://threejs.org library for helping to visualize
the service view in a graph representation, as shown in Fig. 5. On the other
hand, it uses Mermaid111111Mermaid: https://mermaid-js.github.io library for
rendering the data view in a class diagram representation, as shown in Fig. 6.

###  IV-C Metrics Quantification

The prototype was applied to the three distinct releases of the TrainTicket
Testbench. The seven proposed metrics are listed in Table I and plotted in
Fig. 4.

TABLE I: TrainTicket Metrics Values. Metric | v0.0.1 | v0.2.0 | v1.0.0 |
---|---|---|---|---
S1. $\\#\mu_{s}$ | 46 | 40 | 43 |  }2*[Service View]
S2. $\\#C\mu_{s}$ | 135 | 91 | 90 |
D1. $\\#PDE_{s}$ | 31 | 27 | 27 |  }5*[Data View]
D2. $\\#TDE_{s}$ | 0 | 182 | 81 |
D3. $\\#RDE_{s}$ | 0 | 41 | 43 |
D4. $\\#MDE_{s}$ | 11 | 139 | 32 |
D5. $\\#MRDE_{s}$ | 0 | 17 | 19 |
Figure 4: TrainTicket Metrics Evolution.

With these metrics at our disposal, we can interpret the system’s evolution
across the three versions, as outlined below:

S1:

Number of Microservices ($\\#\mu_{s}$).
It decreased from 46 in v0.0.1 to 40 in v0.2.0 and then slightly increased to
43 in v1.0.0. This indicates a reduction in the system’s high-level components
or a consolidation of functionality.

S2:

Number of Microservices Connections ($\\#C\mu_{s}$).
It decreased from 135 in v0.0.1 to 91 in v0.2.0 and remained relatively stable
at 90 in v1.0.0. This suggests a decrease in the interdependence between
microservices or a more optimized communication pattern.

D1:

Number of Persistent Data Entities ($\\#PDE_{s}$).
It remained relatively constant across all versions, starting at 31 in v0.0.1
and remaining consistent at 27 in both other versions. This indicates
stability in the storage approach and domain model for the microservices.

D2:

Number of Transient Data Entities ($\\#TDE_{s}$).
It increased significantly from 0 in v0.0.1 to 182 in v0.2.0 and dramatically
decreased to 81 in v1.0.0. This suggests the introduction of additional
entities for customizing responses and data transfer purposes, which decreased
in the latest version to optimize the usage of entities across microservices.

D3:

Number of Relationships between Data Entities ($\\#RDE_{s}$).
It started at 0 in v0.0.1, grew to 41 in v0.2.0, and 43 in v1.0.0, suggesting
the evolution of the data model complexity and the establishment of
relationships between entities.

D4:

Number of Merge Candidates Data Entities ($\\#MDE_{s}$).
It increased from 11 in v0.0.1 to 139 in v0.2.0 and decreased to 32 in v1.0.0.
This indicates a growing complexity in the bounded contexts and the need for
merging similar entities.

D5:

Number of Merge Candidates Relationships between Data Entities
($\\#MRDE_{s}$).
It started at 0 in v0.0.1, increased to 17 in v0.2.0, and further to 19 in
v1.0.0. This indicates the emergence of candidate relationships for merging
based on similar entities.

Analysis of these metrics offers valuable insights into the system’s
evolution, shedding light on shifts in microservice counts, connections,
diverse data entities, and their relationships across the entire system. A
more profound understanding can be achieved when considering the relationships
between these metrics and exploring the cause behind these metrics indicators.
Further exploration of the reasoning about the system will be addressed in the
subsequent subsections.

###  IV-D Service and Data Views Visualization

The prototype provides visual intermediate representations of the service view
and data model view of the system. The service view, presented using 3D
visualization in Fig. 5, highlights changes in the system’s microservices
($\\#\mu s$) and interconnections ($\\#C\mu s$). It exhibits reduced coupling
in the latest version compared to the initial one.

In terms of the data view, the number of entities increases in the holistic
context map as we move from one version to the next. After the prototype
merges entity candidates and relationships, the constructed context map
comprises 20, 70, and 76 entities in versions v0.0.1, v0.2.0, and v1.0.0, as
detailed in Table II. This reflects the merging of both persistent and
transient data models while eliminating candidate entities of both types. The
prototype visualizes the evolution of the context map, as shown in Fig. 6,
illustrating changes in the context map and how entities connected with each
other as the system evolves.

(a) v0.0.1

(b) v0.2.0

(c) v1.0.0∗

Figure 5: Service View Visualization for TrainTicket Versions
(Subsets of the diagrams are included due to space constraints) [∗partial
view]

(a) v0.0.1

(b) v0.2.0

(c) v1.0.0

Figure 6: Context Map Visualization for TrainTicket Versions
(Subsets of the diagrams are included due to space constraints)

##  V Architectural Evolution Reasoning

System architects and practitioners need to consider not only the raw metrics
but also the underlying architectural changes and design decisions that
influence these metrics. The interconnected nature of microservices means that
changes in one area can have ripple effects throughout the system. Further
analysis and exploration of the relationships between these metrics can
provide a more comprehensive understanding of the system’s evolution and its
implications for quality and performance.

This section builds upon the findings of the case study to explore two
reasoning approaches: question-based reasoning and resolution-based reasoning.

###  V-A Reasoning-Based Questions Analysis

Analyzing the metrics values prompts questions regarding the system’s
properties during its evolution. While some team members familiar with the
system may know the answers, practitioners often need to delve into the
individual source code of each microservice to investigate. Therefore,
centralized visualization of the system view is introdued to significantly
reduce the effort required to explore various aspects of the system,
especially when it requires an entire merged perspective. Several case study
reasoning questions (CQ) have arisen from this case study metrics values, the
following list highlights some of them:

  * CQ1.

What factors contributed to the high number of connections in the v0.0.1
service view compared to the other two versions?

  * CQ2.

What explains the disparity between the number of relationships and entities?

  * CQ3.

Why are there no relationships and transient entities in v0.0.1?

  * CQ4.

What is the reason for the substantial number of merged entity candidates
($\\#MDE_{s}$), particularly in v0.2.0?

In response to CQ1, the reduced number of connections in v0.0.1 can be
attributed to the presence of multiple composite microservices that require
communication with other services to fulfill their functionalities. This can
be exemplified by considering two services, ts-preserve-service and ts-
station-service. The former, ts-preserve-service, lacks persistence storage
but relies on 12 other microservices to accomplish its functions. Conversely,
the latter, ts-station-service, has no dependent services but boasts 21
dependencies.

Furthermore, addressing CQ2, the logical relationships between entities rather
than direct connections can explain the metrics indication. For instance, the
Listing 1 demonstrates that the FoodStore entity within ts-food-service
utilizes the stationId field to store the ID value of a Station entity, even
though no established relationship formally links the two entities.
Additionally, the structure of certain microservices, such as ts-station-
service, featuring persistent storage, while others, like ts-preserve-service,
lack this feature, can add more justification to this question.

Listing 1: Logical relationship in ts-food-service (FoodStore entity)

⬇

1@Data

2public class FoodStore {

3 private UUID id;

4 //logical relationship

5 private String stationId;

6}

Answering CQ3 involves two key considerations. Firstly, the absence of
transient data entities in v0.0.1, unlike the other two versions, is
attributed to the fact that v0.0.1 does not employ Lombok annotations to
annotate their transient data classes. Consequently, the prototype could not
guarantee other hypotheses for identifying transient entity types.
Furthermore, upon investigation, it was revealed that v0.0.1 uses some of the
persistent data entities for the purpose of transferring data between
microservices. While this may appear as a limitation in the prototype’s
implementation, after investigation, it highlights an evolutionary perspective
on the diverse techniques and strategies employed by v0.0.1 for handling
transient data entities, distinct from the approaches taken in the other two
versions. The second aspect of this question pertains to the different types
of persistent data entities. In v0.0.1, in addition to the absence of
transient data entities, no relationships were extracted. This is because
v0.0.1 utilizes MongoDB as its persistence storage, which is a non-relational
database. As summarized in Table III, the system transitioned from non-
relational to relational databases in the latest version.

TABLE II: Merging Data Entities. Data Entity | v0.0.1 | v0.2.0 | v1.0.0 |
---|---|---|---|---
$\\#PDE_{s}$ | 31 | 27 | 27 |  }3*[Merge]
$\\#TDE_{s}$ | 0 | 182 | 81 |
$\\#MDE_{s}$ | 11 | 139 | 32 |
Context Map (Merged) | 20 | 70 | 76 |
TABLE III: Data Entity Types. Data Entity | v0.0.1 | v0.2.0 | v1.0.0 |
---|---|---|---|---
NoSQL | 29 | 27 | 0 |  }2*[Merge]
SQL | 2 | 0 | 27 |
$\\#$PDEs | 31 | 27 | 27 |

Addressing CQ4, this study provides insights into the process of merging
entities across multiple bounded contexts. As highlighted in Table II, v0.2.0
contains a total of 209 entities ($\\#PDE_{s}+\\#TDE_{s}$) within its bounded
context. However, this number of entities is significantly reduced to 70
entities within the context map after merging 139 candidate entities. Upon
closer examination of the system’s source code, it becomes apparent that 39
entities are duplicated across multiple microservices in v0.2.0. This
duplication issue is particularly evident in v1.0.0, where 39 entities are
consolidated into a single shared microservice named ts-common to address this
concern. This is demonstrated in Fig. 7 illustrating three related entities
(Food, TrainFood, FoodStore) duplicated within bounded contexts of ts-food-
service and ts-food-map-service.

###  V-B Reasoning-Based Resolution Analysis

In addition to the case study questions, it is essential to delve into the
issues present in v0.0.1 and the resolutions in v1.0.0. The initial system
design exhibited some problematic tendencies, there are many small nano-
services, which is a recognized anti-pattern for microservices. It can also be
described as a microservice greedy anti-pattern, where new microservices were
created for each feature, even when they were unnecessary, as evident in later
versions when they were merged and consolidated. Furthermore, in v0.0.1, only
half of these microservices defined data entities, while the other half
appeared to serve as transfer services in the business layer. This approach
can be characterized as a wrong cuts anti-pattern, dividing the system into
layers based on functionality rather than domain considerations, as confirmed
by Walker et al. [app10217800] when analyzed this testbench.

Considering the service view at Fig. 5, v0.0.1 displayed numerous complex
coupling knots, indicating a design prioritizing over-engineered decomposition
rather than adhering to Conway’s law. In contrast, v1.0.0 showed better
alignment with Conway’s law. This correlation is also reflected in the number
of connections in Table I.

An important observation lies within Table II. While most dynamic analysis
tools consider service calls as the foundation for service connections, the
merge entity candidates can indicate another dimension of connectivity when
many entities within the system represent the same concept. This observation
presents an efficient mechanism for connecting microservices beyond service
calls. v0.2.0 contains 209 scattered entities across the system that are
reduced to 70 within the context map. Such a process is non-trivial for human-
based analysis and would require manual merging with each system change.

(a) Entities in ts-food-service

(b) Entities in ts-food-map-service

Figure 7: An Example of Duplicating Entities in Microservices

##  VI Discussion and answers to RQs

This study adopts a centric perspective to examine the architectural evolution
of microservices using their service and data views. In pursuit of this
objective, a set of seven metrics is introduced and employed to quantify
diverse properties within these two views. Two metrics focus on aspects of the
service view, such as microservice count and inter-service connections
(addressing RQ${1}$), while five metrics pertain to the data view, including
data entity types and relationships, including duplicates across different
bounded contexts (addressing RQ${2}$). 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 are then visually presented
using tailored techniques. The primary aim is to facilitate practitioners’
exploration and understanding of the system’s central properties. By comparing
the metric values and the visual representations across different system
versions, we gain a roadmap and guidance to understand the system’s evolution,
particularly in terms of changes in its 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.

Metrics Granularity. Proposed metrics present abstract indicators of the
holistic perspective of service and data views, 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 views 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 view. 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
[esparrachiari2018tracking, cinque2019framework]. 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.

Furthermore, the described methodology can be expanded to include event-based
connections. The current representation predominantly focuses on endpoint
connections, whereas event-based connections may require additional
considerations and interpretations, given the potential one-to-many
relationships between a single producer and multiple consumers in an indirect
communication manner. Additionally, the intermediate representation can be
augmented to encompass system viewpoints, including the technology view and
operational view.

Visualization Effectiveness. While the visualization introduced in this study
serves as an instrument for presenting a central view of the system, its
selection was informed by a series of user studies [??, ??, ??, ??] involving
practitioners. These studies validated the effectiveness of the visualization
approaches in enhancing system understandability.

Furthermore, the flexibility of the visualization offers the potential to
incorporate additional information that can aid practitioners in comprehending
more aspects of the system. It can include annotations for different data
entity types and various call types. Additionally, it can highlight additional
anti-patterns, as demonstrated by its color-coding approach to indicate the
degree of coupling between microservices.

In conclusion, integrating the implementation of these metrics with CI/CD
pipelines would make it an ideal tool for indicating and assessing the system
evolution.

##  VII Threats to Validity

The potential threats to the validity base on the classification proposed in
[WohlinExperimentation]. For the Construct Validity, our methodology focuses
on constructing service and data views. We utilize the TrainTicket testbench,
a widely accepted benchmark in the microservices community.

In terms of Internal Validity, manual analysis for validating the extracted
data performed by the authors. To ensure unbiased analysis, the data
validation and the prototype is executed by different authors. However,
potential threats may arise from the testbench project’s structure and
conversion. For instance, some entities in v0.0.1 lack Lombok annotations,
causing our methodology to miss them. This inconsistency can lead to
inaccurate indicators of extracted data entities, necessitating further
investigation. Furthermore, the prototype does not detect event-based
communications for interaction, although it does occur a few times within the
assessed testbench, where the main connections primarily rely on REST endpoint
calls. However, this does not affect the metrics’ evolution, as these
communication patterns remain consistent across different versions.

Regarding External Validity, our methodology offers general processes for
constructing service and data views, applicable regardless of the programming
language or framework. However, the implemented prototype is specific to the
Java language and the Spring Boot framework. Adapting it to different
languages would require non-trivial changes to the underlying logic.
Additionally, the choice of TrainTicket as the case study testbench is a
limitation since being a testbench rather than a real-world microservices
system somewhat limits its authenticity in reflecting actual system evolution.
Nonetheless, we selected a broad range of system versions to emphasize the
evolutionary changes.

Conclusion Validity is drawn from the case study’s results, which illustrate
the analysis capabilities of our method concerning specific architectural
views. The case study encompasses multiple reasoning approaches, as discussed
in the case study section, thereby validating and justifying our methodology
for reasoning about architectural evolution. The results clearly demonstrate
modifications in the system architecture and the resolution of multiple issues
as the system evolves.

##  VIII Conclusion

This paper addresses current gaps in microservice system evolution. It
utilizes two established architectural viewpoints (service and domain),
elaborating on the analysis process and results for comprehensive
visualization. Seven metrics were defined that serve as indicators for
understanding system changes holistically, facilitating efficient system
evolution reasoning and version comparisons.

A case study demonstrated the methodology, highlighting the significance of
metrics and visualization in enhancing the understanding of system evolution
properties. It showed that changes in system architecture could be approached
from different granularity levels, utilizing holistic insights for various
reasoning perspectives, including reasoning-based questions and resolutions.

Future work will apply these metrics at different granularity levels, extend
the intermediate representation to include event-driven calls, dynamic data,
and other architecture viewpoints.