# On the Empirical Evidence of Microservice Logical Coupling

A Registered Report

Dario Amoroso d’Aragona  Tampere University
TampereFinland<EMAIL_ADDRESS>,  Luca Pascarella  ETH Zurich
ZurichSwizerland<EMAIL_ADDRESS>,  Andrea Janes  FHV Vorarlberg
University of Applied Sciences
DornbirnAustria<EMAIL_ADDRESS>,  Valentina Lenarduzzi  University of
Oulu
OuluFinland<EMAIL_ADDRESS>,  Rafael Peñaloza  University of
Milano-Bicocca
MilanItaly<EMAIL_ADDRESS>and  Davide Taibi  University of Oulu
Tampere UniversityOuluFinland<EMAIL_ADDRESS>
###### Abstract.

[Context] Coupling is a widely discussed metric by software engineers while
developing complex software systems, often referred to as a crucial factor and
symptom of a poor or good design. Nevertheless, measuring the logical coupling
among microservices and analyzing the interactions between services is non-
trivial because it demands runtime information in the form of log files, which
are not always accessible.

[Objective and Method] In this work, we propose the design of a study aimed at
empirically validating the Microservice Logical Coupling (MLC) metric
presented in our previous study. In particular, we plan to empirically study
Open Source Systems (OSS) built using a microservice architecture.

[Results] The result of this work aims at corroborating the effectiveness and
validity of the MLC metric. Thus, we will gather empirical evidence and
develop a methodology to analyze and support the claims regarding the MLC
metric. Furthermore, we establish its usefulness in evaluating and
understanding the logical coupling among microservices.

Microservices, Logical Coupling, Empirical Software Engineering

##  1\. Introduction

Coupling and cohesion are two fundamental metrics in software engineering:
coupling measures the degree of interdependence between modules (low is
preferred) and the cohesion of a module indicates the extent to which its
individual components are needed to perform its task (high is preferred)
(Fenton and Pfleeger, 1997). Low coupling and high cohesion are often
mentioned in connection with maintainable code: code with low coupling means
that one module can be modified without impacting other modules; a highly
cohesive module means that that module has a single, well-defined purpose.

This paper studies to what extent software systems whose development
architecture is based on microservices respect a _“low coupling”_. In
Microservice Architecture (MSA), a system is composed of independently
deployable microservices where each service has a single responsibility,
meaning they only manage one specific part of the organization’s needs (Lewis
and Fowler, [n.d.]). Microservices should be loosely coupled since coupling
increases maintenance effort and—particularly in the context of
microservices—increases the need for synchronization between teams. A
development team in charge of a single service should need to know as little
as possible about other services. Highly coupled services might require
synchronizing with other services before deploying new features, reducing the
benefits of microservices. Coupling not only slows down the development
process but also impacts other qualities e.g., performance, since
communication between services is slow compared to communication within a
service. Along the same lines, microservices should be highly cohesive,
keeping all the related logic in a single service rather than splitting it
into multiple services (Newman, 2021).

Software engineers agree on the importance of low coupling between
microservices referring to “independence between teams” (Hastie, 2022),
“independent deployment” (Ford et al., 2021) or “no need to synchronize
between teams before deploying” (Richardson, 2022). Indeed, practitioners
often mention low coupling as a main benefit of microservices (Taibi et al.,
2017; Soldani et al., 2018).

Although practitioners agree about the impact of these metrics on the software
quality, they remain reluctant to a practical usage by choosing a short-
circuit approach based on their gut feeling to structure a system into
services, causing an uncontrolled degree of coupling. Possible reasons for not
adopting the metrics proposed by the scientific community are over-optimism,
inadvertence, or the unavailability of data. As an example, (Taibi and Systä,
2020; Gadler et al., 2017) assume the availability of log files describing
calls to software components, used to extract usage processes, which are then
used to propose microservices. Such logs are not always available or might
require major changes in the system under development. Moreover, the
measurement of coupling proposed in the literature is based on the static
(Cerny et al., 2022) or dynamic analysis (Gortney et al., 2022) of source
code. Coupling between teams such as the need to wait or to synchronize with
other service teams before committing is not captured by such metrics.
Previous works addressed the problem of coupling in monolithic systems
thoroughly. Also, the concept of logical coupling was introduced, i.e.,
coupling, which is not based on a dependency in source code, but on the
implicit dependency between artifacts that are often changed together. In
particular, (D’Ambros et al., 2009) extended the logical coupling metric,
originally proposed by (Robbes et al., 2008) to capture whether changes made
in a predefined time window are logically coupled.

In this research, our objective is to propose a study design aimed at
empirically validating the Microservice Logical Coupling (MLC) metric we
introduced in our previous work (Amoroso d’Aragona et al., 2023). To this aim,
we plan to conduct an empirical study by focusing our analysis on Open Source
Systems (OSS) whose software design is based on microservices architecture.
The primary focus of this study is to provide empirical evidence supporting
the effectiveness and validity of the Microservice Logical Coupling (MLC)
metric.

The expected outcome from this work is two-fold:

  * •

a new validated context-aware metric to calculate the logical coupling between
microservices;

  * •

a detailed replication package reporting all the data and scripts to open
further research studies.

Practitioners can benefit from these results from both research and practical
perspective by assessing one aspect of the coupling between microservices.

Paper structure: Section 2 describes the background, Section 3 depicts related
work, Section 4 introduces our study design, Section 5 reports the study
execution, Section 6 discusses the possible threats, Section 7 shows the risk
management, and Section 8 draws conclusions and future work.

##  2\. Background

Complex software systems are not always created by ardent practitioners for
various reasons. Developers are continuously dealing with project demand and
restrictions. As a consequence, developers incur the potential risk of
performing changes to the software which aren’t related to their expertise,
assignments, or component. Logical coupling uses a software system’s
development history to detect change patterns among code units that are
modified together in order to spot entangled changes in versioning systems.

Robbes et al.’s (Robbes et al., 2008) metric, adopted by D’Ambros et al.
(D’Ambros et al., 2009), measures whether changes performed within a specified
time range are logically coupled.
In our previous work (Amoroso d’Aragona et al., 2023), we investigated changes
involving multiple microservices committed atomically in the same working
unit. In their work, they consider two microservices logically coupled if
these have been co-changed more than 5 times during the history of the
project. However, the proposed metric (Amoroso d’Aragona et al., 2023)
considers neither the decoupling of two microservices – thus when due to some
refactoring in the code the two microservices are not logically coupled
anymore – nor the evolution of the coupling during the development process nor
the context of the project – commit frequency, number of developers, number of
microservices and so on – that can influence the metric leading in an
inaccurate result. For this reason, we proposed a new metric that can be used
to analyze the evolution of the coupling during the history of the project,
allowing us to study when two microservices start to be logically coupled and
when they could be considered decoupled. We will perform different analyses to
understand how we can define a threshold to consider two microservice
logically coupled based on a single specific project, in this way, we can
develop a proposal to identify the best threshold depending on the specified
project. Furthermore, we will perform a study to understand which factors can
influence the metrics and how we can mitigate this influence by setting
differently the metrics parameters.

##  3\. Related work

Several metrics have been suggested for monolithic systems, some of which have
been adapted for service-based systems, particularly for microservices, as
demonstrated in previous research (see e.g., (Fenton and Pfleeger, 1997)).
Bogner et al. (Bogner et al., 2017) conducted a systematic literature review
on maintenance metrics for microservices, with a focus on service-based
systems rather than metrics developed for object-oriented systems. Their
findings indicate that most of the metrics that were originally designed for
monolithic systems and Service Oriented Architectures are also relevant in the
context of microservices. This study is considered to be the first to focus
exclusively on microservices, and subsequent research has expanded on these
findings to further enhance our understanding of the topic.

Apolinaro et al. (de Freitas Apolinário and de França, 2020) presented a
theoretical use case proposing a roadmap to apply four metrics defined by
(Bogner et al., 2017):

  * •

Absolute Importance of the Service (AIS): number of consumers invoking at
least one operation from a service

  * •

Absolute Dependence of the Service (ADS): number of services on which the
service depends

  * •

Service Coupling Factor (SCF) as the density of a graph’s connectivity.
SCF=SC/N2-N where SC is the sum of calls between services, and N is the total
number of services.

  * •

Average Number of Directly Connected Services (ADCS): the average ADS metric
of all services.

In their study, Taibi et al. (Taibi and Systä, 2020) suggested four measures
(coupling between microservices, number of classes per microservice, number of
duplicated classes, and frequency of external calls) to be considered when
breaking down an object-oriented monolithic system into microservices.
However, these metrics rely on the concept of classes and lack empirical
validation. On the other hand, Panichella et al. (Panichella et al., 2020)
proposed a structural coupling metric, which was tested in 17 open-source
microservice-based projects (Imranur et al.(Imranur et al., 2019)). The metric
calculates the coupling of services at runtime based on the inbound and
outbound calls between services.

In our recent work (Amoroso d’Aragona et al., 2023), we proposed a new metric
to measure the level of logical coupling between microservices, which is based
on the analysis of commits to versioning systems. To validate the
effectiveness of this metric, the authors collected data from 145 open-source
microservices projects and performed an initial analysis. The results show
that logical coupling has a significant impact on the overall system and tends
to increase over time.

##  4\. The Empirical Study

We now describe our empirical study reporting goal, research questions,
context, data collection, and data analysis.

###  4.1. Goal and Research Questions

Our goal is to empirically validate Microservice Logical Coupling (MLC) metric
we defined in our previous work (Amoroso d’Aragona et al., 2023). Therefore,
we formulated the following three Research Questions (RQs):

RQ1. _Does the MLC metric respect the representation condition of
measurement?_

In this RQ, we will consider measurement as a mapping from the empirical world
to the formal, relational world. Consequently, a measure is the number or
symbol assigned to an entity by this mapping in order to characterize an
attribute (Fenton and Bieman, 2014). Now for us, the empirical relationship we
want to measure is logical coupling in the context of microservices.

That is, the representation condition asserts that a measurement mapping (a
measurement) M must map entities into numbers and empirical relations into
numerical relations in such a way that the empirical relations preserve and
are preserved by the numerical relations. For example, if we measure height
using a meter, the measurement method M that we use to determine height needs
to respect the following representation condition: A is taller than B if and
only if M(A)>M(B) (Fenton, 1994; Fenton and Bieman, 2014).

In this context, “validating a software measure is the process of ensuring
that the measure is a proper numerical characterization of the claimed
attribute by showing that the representation condition is satisfied (Fenton
and Pfleeger, 1997)”, which is what RQ1 wants to investigate.

RQ2. _How does the project context impact the MLC metric?_

When validating a measure, it “must be viewed in the context in which it will
be used” (Fenton and Pfleeger, 1997). Therefore, validation must take into
account the measurement’s purpose since a measure may be valid for some uses
but not for others (Fenton and Pfleeger, 1997). Therefore, with RQ2, we want
to investigate how the following factors (F) influence the accuracy of the
metric:

  * F1:

Commit scope Since we assume that a commit indicates a change in a particular
microservice, large refactoring or application-wide user interface changes
should be excluded from this consideration to avoid them from being
interpreted as that all microservices are coupled.

  * F2:

Commit size (F2) It is necessary to study in detail which commits need to be
excluded or particularly considered in the proposed metric. Moreover, the more
rarely a developer commits while changing code, the more changes are included
in each individual commit, and thus this increases the probability that two
different microservices seem coupled. For example, in the extreme case of one
commit per month, all microservices might appear coupled, so it is necessary
to understand the sensitivity of our metric with respect to the commit size.

  * F3:

Microservice size (F3) It is common practice to suggest small changes to
facilitate the code review process, and to reduce the need for regression
testing. For example, a study showed that in open source projects a change in
the 80% of the time involves four files (Arafat and Riehle, 2009). So if a
change in 80% of cases involves 4 to 5 files, it seems more likely that in the
extreme case of having very small microservices will result in a higher
probability of logical coupling. Conversely, having large microservices this
consideration seems less likely.

###  4.2. Data Collection

To understand the coupling and decoupling of microservices, we need to know
when different microservices are updated, and how often they are modified in
correspondence to each other. We will collect all the commits in a project,
grouped by commit day, and by microservice. That is, for each day, we will
signal which microservices were updated.

To avoid spurious conclusions derived from gaps in the work , we will remove
from the dataset all days in which no commits were made to the project. Hence
we consider only “active” days (rather than calendar days).

###  4.3. Data Analysis

Figure 1. Selection of the relevant active days for the microservices couple
$(\mu,\nu)$

In order to answer our RQ1, we need to measure the coupling of microservices
and their evolution over time. We will use a _sliding window_ approach. Fixed
a number $n$, we look at each window of $n$ consecutive (active) days. For
each pair $\mu,\nu$ of microservices of interest, we will count the number of
instances in which _both_ services were updated within the window.
Specifically, a microservice is updated if at least one of its associated
files is modified at the commit. The proportion of days with shared updates is
associated with the _coupling value_ at the end of the window. For example, if
$\mu$ is updated on days $\\{1,2,4,6,10\\}$ and $\nu$ is updated on active
days $\\{1,2,3,4,5,10\\}$ (Figure 1), assuming a sliding window of 3 days,
during the first window the microservices are mutually updated in two (1 and
2) of the three days (Figure 2), yielding a coupling value of $2/3$. The
second window considers days 2–4, and yields a coupling value of $2/3$ again.
On the third window (days 3–5) the coupling value decreases to $1/3$ and
remains like that in the successive window. The days 7, 8, and 9 are not
considered even if they are active days—$\rho$ is committed—because they are
not relevant for the couple $(\mu,\nu)$. We consider only the number of days
(in the window) when at least one of the services is updated. In the example
above, the days 7–9 are removed since neither $\mu$ nor $\nu$ is updated on
those days (they are thus irrelevant for the pair). Note that, thanks to this
focus on relevant active days, the coupling value between the services remains
at least $1/3$, in contrast with the 0 that is observed if days 7–9 were
included. In this way, we can model the decrease in coupling. If we considered
all the active days, we would have a value of 0, of occurrences in a single
day, both when none of the microservices is committed and when only one of the
two is committed. But active days when neither of the two microservices of
interest is committed add no information and act as noise in the data.
Furthermore, if two microservices are seldom updated, their coupling value
would be small, even if they are constantly updated together.

The coupling value increases as $\mu$ and $\nu$ co-occur more often, and
decreases otherwise. Using these values, we can apply different techniques for
understanding the evolution of coupling between the services. Given a
threshold, we can find instances where the services are “sufficiently”
coupled. But using specific numerical values allows us to apply time-series
analyses—in particular, time-series segmentation—to understand the periods of
time where the coupling is growing, stable, or decreasing, respectively.

The size $n$ of the sliding window cannot be fixed _a-priori_ , as it depends
on the specific properties of the project. Yet, it can be seen that a longer
window yields a more stable behavior, where the numerical values differ less
between successive active days. We will experiment with different window sizes
(i.e., 10–30–100) to better understand this behavior. Finally, rather than
checking the co-occurrence of microservice updates, we can verify for
_logical_ dependencies: if service $\mu$ is updated, do we expect to update
$\nu$ as well? This value is obtained by modifying the proportion described
before to the number of co-occurrences divided by the active days where $\mu$
is updated within the window. This can be seen as the conditional probability
of modifying $\nu$ given that $\mu$ was modified. Importantly, contrary to
“pure” coupling, this measure is not symmetric; that is, the likelihood of
modifying $\nu$ when $\mu$ is changed is not necessarily equal to that of
modifying $\mu$ under the assumption that $\nu$ is modified. This asymmetry
allows us to better understand the relationships and dependencies between
microservices.

Figure 2. Three days sliding window example

Regarding RQ2, to understand the influence of the three relevant factors on
our metrics, we will analyze the impact of selecting different thresholds for
filtering out commits, and for filtering microservices of different sizes, in
the overall time series through a correlation test.

###  4.4. Verifiability and Replicability

We will make the scripts and raw data available in our online appendix to
allow verifiability and replicability.

##  5\. Execution Plan

This Section shows the execution plan we will aim to implement according to
the study design defined in Section 4. The execution plan is constructed by
splitting the activities into six main steps: project selection, retrieving
co-changed microservices, time series analysis, conditional probability,
exploratory analysis, and validation.

###  5.1. Project Selection

As the first step of our study, we must collect data from well-developed
software projects. For this aim, we will initially focus on projects whose
source code is systematically developed by using git versioning system and is
hosted publicly on GitHub. Then, we will define all the characteristics needed
by a project to be included in our analysis (e.g., _age, number of commits,
number of developers. number of stars, number of watchers, supported by
companies/governments/foundation_). In addition, we will include only those
projects that implement a consistent architecture based on microservices .

###  5.2. Retrieving co-changed microservices

As a successive step, we will need to collect all microservices whose
associated source code is modified within a single time window. More
precisely, we refer to co-changed microservices as cases in which at least two
files belonging to two different microservices are changed simultaneously, or
in other words, they are changed within the same day. To do so, we will first
focus on relevant active days by excluding all calendar days which do not
present changes on the given microservices and then will extract all the files
that changed on these days. Successively, we will create a map to associate
each microservice with the related changed file.

###  5.3. Time series analysis

In the third step, we will proceed with a time series analysis by considering
all changes associated with each microservices. In particular, for each
defined sliding window, we will count in how many active days, in the same
sliding window, the microservices have been committed together divided by the
length of the sliding window, in Figure 2 the result of this step will be:
$2/3$ for the first and second window and $1/3$ for the last three windows.

###  5.4. Conditional Probability

In the fourth step, we will focus on the conditional probability. For each
pair of microservices, we will extract the active days where at least one of
the two microservices has been changed. It is worth noticing that the
conditional probability of Figure 2 depends on the order in which the two
microservices are analyzed. For example, the conditional probability
$P(\mu\mid\nu)$ corresponds to $2/3$ while the conditional probability
$P(\nu\mid\mu)$ is $2/2$.

###  5.5. Exploratory Analysis

In the fifth step, we will extract the commit scope (_e.g.,_ _refactoring, bug
fix, improvement, new feature_) by parsing the commit message. We will extract
the commit size (e.g _chunks_). We will study how the results change using
different _thresholds_ to consider two microservices logically coupled,
different lengths of the _sliding window_ and filtering out the commit based
on the commit scope and the commit size. We will compare the different results
by grouping the projects by the number of microservices. Each variation
produces a different time series. These variations will be compared through a
correlation analysis.

###  5.6. Validation

In the last step, we will validate our metric. In particular, since we are
interested in understanding (i) how the proposed metric depicts the evolution
of the logical coupling over time and (ii) to what extent microservices
labeled as coupled are effectively united, we will:

  * •

Manually calculate the coupling of a statistically relevant sample of
microservices (e.g., confidence level 95%, confidence interval 1) so as to
create our ground truth.

  * •

Use accuracy measures (e.g., _precision, recall, and f-measure_), checking
whether the microservices labeled as coupled are actually coupled;

  * •

Use the ground truth to evaluate the conditional probability and thus if our
probability corresponds to a real update in real life;

  * •

Check if the trend caught by our metric correspond to the actual trend.

##  6\. Threats to Validity

In this section, we discuss the threats that might affect the validity of our
empirical study.

We acknowledge the potential limitations of our research. Firstly, while we
have chosen a diverse and up-to-date dataset, it may not encompass the entire
spectrum of open-source microservices projects. Nonetheless, we believe it
represents a valuable collection in terms of microservice quantity, project
age, and developer involvement. Secondly, it’s important to note that
industrial projects might have different perspectives on coupling,
particularly due to the emphasis placed on minimizing coupling in practitioner
discussions. Nevertheless, exploring the microservice lifecycle (MLC) of a
project can shed light on ineffective team dynamics and workflow structures,
enabling organizational improvements.

Furthermore, our MLC validation analysis solely focuses on co-changes of
microservices within the same commit. Consequently, it does not capture
subsequent changes arising from the necessity to synchronize services. To
address this, one potential solution could involve introducing a time window
to account for co-changes. Additionally, considering the issues reported in
the project’s issue trackers could provide insights into whether developers
are requesting synchronization with other services for their changes.

##  7\. Risk management

During the execution of this study, we foresee mainly two risks that might
impact the results: Lack of OSS Projects and the Unavailability of some of the
original authors during the execution of the study.

For the first aspect, there is a risk of not finding OSS projects fulfilling
our criteria. However, we are aware that different works have already
performed studies investigating the quality of OSS Microservices, thus
minimizing this risk. For the second aspect, since not all authors have
permanent contracts, therefore there is the risk that some authors might
change affiliations or not be available to continue this work actively. To
mitigate this risk, the authors committed to continuing this work even without
some of the author’s contributions.

##  8\. Conclusion

In this work, we describe the design of an empirical study aimed at
understanding if the Microservice Logical Coupling (MLC) metric respect the
representation condition of measurement and how the project context impacts
the MLC metric itself.

We plan to shed light on the MLC, executing this study on Open Source Projects
developed with microservices.

The execution of this study will allow us to understand if the MLC is a viable
metric to measure logical coupling between microservices, and will allow
researchers and practitioners to eventually use and extend it in future works.

## References

  * (1)
  * Amoroso d’Aragona et al. (2023) Dario Amoroso d’Aragona, Luca Pascarella, Andrea Janes, Valentina Lenarduzzi, and Davide Taibi. 2023.  Microservice Logical Coupling: A Preliminary Validation. In _International Conference on Software Architecture Companion (ICSA-C)_. 81–85.
  * Arafat and Riehle (2009) O. Arafat and D. Riehle. 2009.  The Commit Size Distribution of Open Source Software. In _Hawaii International Conference on System Sciences_. 1–8.
  * Bogner et al. (2017) Justus Bogner, Stefan Wagner, and Alfred Zimmermann. 2017\.  Automatically Measuring the Maintainability of Service and Microservice-Based Systems: A Literature Review. In _Int. Workshop on Software Measurement_.
  * Cerny et al. (2022) Tomas Cerny, Amr S. Abdelfattah, Vincent Bushong, Abdullah Al Maruf, and Davide Taibi. 2022\.  Microservice Architecture Reconstruction and Visualization Techniques: A Review. In _International Conference on Service-Oriented System Engineering (SOSE)_. 39–48.  https://doi.org/10.1109/SOSE55356.2022.00011
  * D’Ambros et al. (2009) Marco D’Ambros, Michele Lanza, and Romain Robbes. 2009\.  On the Relationship Between Change Coupling and Software Defects. In _Working Conference on Reverse Engineering_. 135–144.
  * de Freitas Apolinário and de França (2020) Daniel Rodrigo de Freitas Apolinário and Breno Bernard Nicolau de França. 2020\.  Towards a Method for Monitoring the Coupling Evolution of Microservice-Based Architectures. In _Brazilian Symposium on Software Components, Architectures, and Reuse_. 71–80.
  * Fenton (1994) N. Fenton. 1994\.  Software Measurement: A Necessary Scientific Basis.  _IEEE Trans. Softw. Eng._ 20, 3 (mar 1994), 199–206.  https://doi.org/10.1109/32.268921
  * Fenton and Bieman (2014) Norman Fenton and James Bieman. 2014.  _Software Metrics: A Rigorous and Practical Approach, Third Edition_ (3rd ed.).  CRC Press, Inc., USA.
  * Fenton and Pfleeger (1997) Norman Fenton and Shari Lawrence Pfleeger. 1997.  _Software Metrics: A Rigorous and Practical Approach_ (2nd ed.).  International Thomson Computer Press, London, UK.
  * Ford et al. (2021) N. Ford, M. Richards, P. Sadalage, and Z. Dehghani. 2021\.  _Software Architecture: the Hard Parts: Modern Trade-Off Analyses for Distributed Architectures_.  O’Reilly Media.
  * Gadler et al. (2017) Daniele Gadler, Michael Mairegger, Andrea Janes, and Barbara Russo. 2017.  Mining Logs to Model the Use of a System. In _International Symposium on Empirical Software Engineering and Measurement (ESEM)_. 334–343.
  * Gortney et al. (2022) Mia E. Gortney, Patrick E. Harris, Tomas Cerny, Abdullah Al Maruf, Miroslav Bures, Davide Taibi, and Pavel Tisnovsky. 2022.  Visualizing Microservice Architecture in the Dynamic Perspective: A Systematic Mapping Study.  _IEEE Access_ 10 (2022), 119999–120012.  https://doi.org/10.1109/ACCESS.2022.3221130
  * Hastie (2022) Shane Hastie. 2022\.  Kent Beck: Software Design is an Exercise in Human Relationships.  https://www.infoq.com/news/2022/10/beck-design-human-relationships.
  * Imranur et al. (2019) Mohammad Imranur, Sebastiano Panichella, and Davide Taibi. 2019.  A curated Dataset of Microservices-Based Systems. In _CEUR-WS_.
  * Lewis and Fowler ([n.d.]) James Lewis and Martin Fowler. [n.d.].  Microservices, a definition of this new architectural term.  https://martinfowler.com/articles/microservices.html.
  * Newman (2021) Sam Newman. 2021\.  _Building Microservices_.  O’Reilly Media.
  * Panichella et al. (2020) Sebastiano Panichella, Mohammad Imranur Rahman, and Davide Taibi. 2020.  Structural Coupling for Microservices. In _CLOSER_.
  * Richardson (2022) Chris Richardson. 2022\.  Minimizing Design Time Coupling a Microservice Architecture.  https://www.youtube.com/watch?v=EGOYRuuf2nQ.
  * Robbes et al. (2008) Romain Robbes, Damien Pollet, and Michele Lanza. 2008\.  Logical Coupling Based on Fine-Grained Change Information. In _Working Conference on Reverse Engineering_. 42–46.  https://doi.org/10.1109/WCRE.2008.47
  * Soldani et al. (2018) Jacopo Soldani, Damian Andrew Tamburri, and Willem-Jan Van Den Heuvel. 2018.  The pains and gains of microservices: A Systematic grey literature review.  _Journal of Systems and Software_ 146 (2018), 215–232.
  * Taibi et al. (2017) Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2017\.  Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation.  _IEEE Cloud Computing_ 4, 5 (2017), 22–32.
  * Taibi and Systä (2020) Davide Taibi and Kari Systä. 2020.  A Decomposition and Metric-Based Evaluation Framework for Microservices. In _CLOSER_. 133–149.