Mitigating Microservice Anti-patterns during the Pre-Migration
of Monolith Legacy Systems
Guilherme L. D. Villaca Ivonei F. da Silva
guidvillaca@gmail.com ifsse3@gmail.com
PPGComp – Western Paraná State PPGComp – Western Paraná State
University (UNIOESTE) University (UNIOESTE)
Cascavel, PR, Brazil Cascavel, PR, Brazil
ABSTRACT
Microservice architectures are affected by anti-patterns, which are
bad implementation habits that affect software quality. In many
cases, they have arisen due to errors in pre-migration planning
and incorrect execution during the migration phase from mono-
lithic systems to a microservice architecture. Anti-patterns must
be avoided in the early stages of the migration process because
they negatively impact the microservice architecture and cause
maintainability, management, and evolution issues. We address the
anti-patterns already catalogued in the literature and defines which
ones can be mitigated through better pre-migration planning when
migrating from monolithic to microservice-based systems. We also
present an exploratory study that examines existing strategies for
mitigating microservice anti-patterns during pre-migration. This
study relies on multi-methods composed of a systematic literature
mapping, a rapid review, and interviews with practitioners. As a
result, ten strategies were identified: DDD, strangler pattern, avoid
tight coupling, backlog, group entities, business data, data first,
clean architecture, twelve-factor App, and evolvability assurance.
KEYWORDS
mitigating, microservices, anti-patterns, pre-migration, monolith,
legacy systems
ACM Reference Format:
Guilherme L. D. Villaca, Ivonei F. da Silva, and Wesley K. G. Assunção.
2022. Mitigating Microservice Anti-patterns during the Pre-Migration of
Monolith Legacy Systems. In Proceedings of Trilha de Trabalhos Técnicos
(SBQS 2022). ACM, New York, NY, USA, 9 pages. https://doi.org/10.1145/
nnnnnnn.nnnnnnn
1 INTRODUCTION
Due to extensive maintenance and evolution, monolithic legacy sys-
tems suffer degradation over time [91]. These problems usually oc-
cur when architectural violations are introduced in the architecture
and/or bad design decisions drive the software development [56]. To
contain degradation, there are several approaches, as for example,
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
SBQS 2022, July, 2022, Curitiba, PR
© 2022 Association for Computing Machinery.
ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00
https://doi.org/10.1145/nnnnnnn.nnnnnnn
Wesley K. G. Assunção
wassuncao@inf.puc-rio.br
Pontifical Catholic University of Rio
de Janeiro - PUC-Rio
Rio de Janeiro, RJ, Brazil
to complete rebuilding using new design techniques and technolo-
gies [57]. However, software modernization is a more cost-effective
approach [91]. Software modernization is one of the paths to be
taken, whether in the form of refactoring, remodeling, or migration
to modern platform or paradigm such as microservices [11]. The
migration of monolithic legacy systems to microservices has been
an industry trend in recent years, inspired by large companies like
Amazon, Linkedin, Netflix and others, and gaining popularity [91].
The essence of microservices is to decompose the application’s com-
ponents into small unities logically grouped as services, each one
running in its own process and communicating with lightweight
mechanisms, usually an HTTP resource API [62].
Microservices are a good solution for the modernization of legacy
systems [91]. However, this architectural style also suffers from the
so-called anti-patterns. Anti-patterns are bad practices that occur
during development and affect some quality attributes of the soft-
ware such as understandability, testability, extensibility, reusability
and maintainability [82, 84]. Therefore, practitioners must carefully
make proper decisions when migrating to microservices to avoid
some pains [54]. Potentially, some microservice anti-patterns can
be mitigated since from the pre-migration/planning phase of the
migration. Based on this assumption, the aim of this research is to
investigate what strategies can be used before the migration process
initiates, i.e., during the pre-migration, to mitigate microservice
anti-patterns.
This study was guided to answer the following research ques-
tion: Which actions in the pre-migration phase of legacy systems to
microservices can be performed to mitigate anti-patterns? The aim is
to gain a deep understanding of the challenges and solutions in this
matter. In the literature we can find few studies that discuss bad
smells and anti-patterns for microservices [12, 82, 84]. Some of these
studies propose solutions of anti-patterns in microservices systems
without deeply discussing about the migration from monolithic
systems. For example, it was identified that some of anti-patterns
are unique for microservices, that is, they are problems related to
distributed systems, communication between microservices, use or
lack of use of tools or patterns etc [82, 84]. Other anti-patterns were
considered that can be analyzed even with the monolithic system,
and with a better planning or study/analysis can be mitigated when
the system with the architecture in microservices is ready [12].
However, none of these studies focused on strategies to be taken
for the monolithic system before migrating to microservices.
The main contribution of this work is to identify, understand,
and describe strategies to mitigate anti-patterns. Thus, we help
researchers and practitioners to analyze the monolithic system in
terms of degradation, defects, and architectural design issues, as
SBQS 2022, July, 2022, Curitiba, PR
well as to enable better planning in the pre-migration and migration
phases to microservices so that the microservice anti-patterns are
minimized or mitigated.
The remainder of this paper is structured as follows. Section
2 covers the study background. Section 3 introduces the study
methodology. The results and the discussion are located in Section
4, respectively. Finally, Section 5 outlines overall conclusions and
directions for future work.
2 BACKGROUND
2.1 Monolithic Architecture and its
Modernization
Monolithic architectures are rigid and tightly coupled. In this kind
of systems, any small change has challenges and a hard impact
on productivity, time, cost, and deployment. However, to supply
business demands, currently software systems must be distributed,
scalable, and portable across different technologies and platforms.
This complexity makes the development more complicated for de-
velopers to change, test, and deploy systems in a short period of
time [34]. Monoliths suffer from degradation over time, which hap-
pens due to constant modifications in code, requirement changes,
growing number of defects (bugs), and design problems. In addition,
it can decrease software performance and substantially increase
evolutionary costs. In the software engineering, it is widely rec-
ommended that software systems must be continually adapted
or enhanced to remain operational [43]. Software evolution has
three main activities: maintenance, modernization, and replacement.
Modernization is important to increase maintainability, increase
flexibility, and reduce costs [17]. Based on that, monolithic sys-
tems are commonly modernized to microservices when [41]: (i) the
monolith became too big and complex to maintain or extend, (ii)
modularity and decentralization are an important aspect, and (iii)
the preference for long-term benefits over short-term.
2.2 Microservices
According to Fowler and Lewis, microservices consist of suites of
independently deployable services organized around business ca-
pability, automated deployment, intelligence in the endpoints, and
decentralized control of languages and data [25]. Each microser-
vice focuses on providing a single business function and follows
the principle of single responsibility [46]. The benefits of adopting
a microservices architecture come with the complexities of dis-
tributed systems [12]. During the migration process, practitioners
often face common problems, which are due mainly to their lack of
knowledge regarding good practices and patterns. The so called bad
smells are indicators of situations that negatively affect software
quality attributes such as understandability, testability, extensibility,
reusability, and maintainability of the system under development
[82].
2.3 Microservices Anti-patterns
To help practitioners identify the potential pitfalls in microservices,
20 anti-patterns were identified [82, 84]. Carrasco2018 presented
five new architectural and four new migration bad smells found by
reviewing 58 different sources from academia and the gray literature.
Guilherme L. D. Villaca, Ivonei F. da Silva, and Wesley K. G. Assunção
These studies identified solutions to correct anti-patterns, but the
solutions are in the context of microservices, without considering
the migration process. There are some suggestions of anti-patterns
that are closely related to the monolithic system and therefore
should be considered in the pre-migration phase. For example, Taibi
et al. discussed [82, 84]: wrong cuts, cyclic dependency, shared
persistence, mega-service, shared libraries, microservice greedy,
and inappropriate service intimacy. However, some of these anti-
patterns may be exclusive to microservices and therefore cannot be
considered when conducting the migration from monolithic legacy
systems, which is the goal of our work.
2.4 Phases for Migration to Microservices
To migrate monolithic legacy systems to microservices, there are
different phases that should be conducted. Wolfart et al. reported
four phases [91]: (i) Comprehension the monolithic legacy system;
(ii) Definition of the microservice architecture; (iii) Execution of
the transformation; (iv) Monitoring after the migration. In this
study, among these four identified phases, the first two (i and ii)
are considered pre-migration, as they are actions taken before the
migration of the monolithic system and when the modernization of
the software is considered. On the other hand, the last two phases
(iii and iv) refers to the migration and post-migration. The last
phase (iv) was not considered in this study.
3 METHODOLOGY
For the methodology, a multi-method was conducted with a sys-
tematic literature mapping, a rapid review, interviews with practi-
tioners, and a thematic analysis.
3.1 Systematic literature mapping
A systematic literature mapping (SLM) is used to identify, evaluate,
and interpret all available research relevant to a particular research
question, topic, or phenomenon of interest [45]. The main RQ in
this study, and for the SLM, is: Which actions in the pre-migration
phase of legacy systems to microservices can be performed to mitigate
anti-patterns? This research question is discussed from the view-
points of the PICO structure [32]. According to PICO guidelines,
we articulated the RQ in terms of its four anatomic parts: Prob-
lem/Population, Intervention, Comparison, and Outcome (PICO).
This facilitates searching for a precise RQ answer.
3.1.1 Search process. The primary studies was searched by fol-
lowing keywords: monolith, microservice; smell, anti-pattern, bad
practice, pitfall, refactor, reengineer, violation, defect and degrada-
tion. Search strings construction is based on research questions and
PICO structure. They are assembled by using operators ANDs and
ORs to merge keywords. Following the search strings used in this
review are listed: “( ( monolith* ) AND ( smell* OR anti-pattern* OR
bad practice* OR pitfall* OR refactor* OR reengineer* OR violation
OR defect OR degradation ) AND ( microservice* OR micro-service*
OR "micro services" ) )”. The search process was conducted manu-
ally and based on relevant digital libraries for software engineering
literature. More specifically, we use: Scopus, IEEEXplore, Science
Direct, and Google Scholar.
The inclusion criteria (IC) for the papers selection were based
on: IC1 : the study outlines strategies to refactor monolithic systems
Mitigating Microservice Anti-patterns during the Pre-Migration of Monolith Legacy Systems
before migrating or upgrading to microservice; IC2 : the study de-
scribes challenges or recommendations to refactor the monolithic
system before migrating or upgrading to microservices; IC3 : the
study shows degradation conditions, failures or defects before mi-
grating or upgrading from monolithic to microservices; IC4 : the
study presents tools or frameworks that assist or monitor defects in
the design of the monolithic system. The exclusion criteria (EC) to
discard studies were: EC1 : duplicated studies, whenever a certain
study has been published in different publications, venues or search
engines (or databases); EC2 : the study is not a scientific research
article nor a conference article; EC3 : study is not written in English.
As papers were read, exclusion/inclusion criteria must be obey
and, if any are achieved, it must be rejected but its details are
kept in a reference repository system (spreadsheets) containing
information to further analysis and research, when necessary. Our
search retrieved 513 primary sources, 62 of them from a previous
study realized [91]. After applying the inclusion and exclusion
criteria, 55 studies remained [1–3, 5, 6, 8, 9, 12, 14–16, 19, 20, 22–
24, 26, 31, 35, 37, 39–42, 44, 46, 48, 49, 52, 53, 55, 57, 60, 63–66, 72–
75, 77, 79, 81–90, 92, 93].
The data extraction forms was designed to collect all the infor-
mation needed to address the RQ and the study quality criteria. The
following were extracted from each study:
• The study’s title and authors.
• The source (conference, journal, and so on).
• The year when the study was published.
• Classification (related work or approach).
• Scope (Refactoring strategies, Modularization Techniques).
• The answers for research questions addressed by the publi-
cation.
• Summary (a summary with brief analysis, overview of its
weaknesses and strengths).
After analyzing the studies, they were categorized to facilitate
the tabulation and subsequent comparative analysis that will appear
in Section 4 of this study.
3.2 Rapid review on Gray Literature
After the SLM, a rapid review (RR) was conducted. RRs are light-
weight secondary studies focused on delivering evidence to prac-
titioners in a timely manner [13]. RRs tend to be more connected
to practice, when compared to Systematic Reviews. The kick start
of a RR is a practical problem that exist in a software project. This
particular problem must motivate researchers to screen the litera-
ture looking for potential answers. As a consequence, researchers
must work closely to practitioners to guarantee that the RR is close
tied to a practical context [13].
Our RR was intended to search the Grey Literature that has been
published by experts in the field regarding the pre-migration and
migration phase, enabling us to understand whether the results of
the mapping are similar or if they bring another perspective. Over
recent years, Grey Literature stands out as an essential source of
knowledge to be used alone or complementing research findings
within the traditional literature [38].
As indicated in [27], the responses that were a motivation for
conducting a grey literature review were Yes for the following
questions:
SBQS 2022, July, 2022, Curitiba, PR
• Is the subject “complex” and not solvable by considering
only the formal literature?
• Is there a lack of volume or quality of evidence, or a lack of
consensus of outcome measurement in the formal literature?
• Is the contextual information important to the subject under
study?
• Is it the goal to validate or corroborate scientific outcomes
with practical experiences?
• Would a synthesis of insights and evidence from the indus-
trial and academic community be useful to one or even both
communities?
3.2.1 Rapid Review - Criteria. For this RR the inclusion criteria (IC)
was: IC1 : blog posts, video, white paper; IC2 : practice experience
in migration from monolithic system to microservices; IC3 : tips,
suggestions, steps; IC4 : failures in microservices that are connected
with anti-patterns (that can be mitigated in monolithic) identified in
mapping. For the exclusion criteria (EC): EC1 : create microservices
as a green development; EC2 : SOA, or any other service solution;
EC3 : only theoretical opinion, without practical experience; EC4 :
product marketing information recommendation content only.; EC5 :
no snowballing in links of articles, videos or blog posts; EC6 : tips,
suggestions or experience in a brief or shallow manner; EC7 : video
without transcription; EC8 : Link unavailable/signature required;
EC9 : copy of another white paper without credit. The stop criteria
was the first 100 hits on Google.
The search process was designed to use the same search string
as the SLM. Google was used in this case, because Google Scholar
was already used in SLM. With the search string most of the results
were similar to the mapping, but even so eight grey articles were
collected. For the RR, we used a more direct and embracing search
string: “migration from monolithic to microservice”. This string re-
trieved better results: 21 out of 100 analyzed links were relevant.
Among the links, 80 ones pointed to a spreadsheet shared by soft-
ware engineering researchers who collect and fill in / update the
spreadsheet regularly, which we used for our analysis. In total, 109
articles were used for inclusion and exclusion criteria. After the
reading, 20 gray literature articles met the inclusion and exclusion
criteria [4, 21, 28–30, 33, 36, 47, 50, 51, 58, 61, 62, 67–71, 76, 78].
3.3 Interviews with Practitioners
The goal of the interviews is to explore the experiences and opin-
ions of software engineers/developers who migrate systems from
monolithic to microservices. It can be considered primarily as being
qualitative in nature. Semi-structured interviews are particularly
suitable for collecting qualitative data because they provide the
opportunity for discussion or exploration of new topics that arise
during data collection [59]. The purpose of this semi-structured
interview is to understand the state of practice at the following
points: (i) validity of the research, context of what can be done to
mitigate anti-patterns, and if there is something to be done, which
techniques and strategies; and (ii) Organizational context of the pre-
migration phase, if the necessary investments are made in training,
specialized staff, infrastructure, planning, etc.
The interview on expert opinion can have high external validity,
good potential for theory generation, are straightforward to repli-
cate, and are relatively cheap to organize. The main goal of this
SBQS 2022, July, 2022, Curitiba, PR
interview is to confirm or refuse the insights and findings from the
systematic mapping study and rapid review, as well, as, to explore
more evidence from the experts.
3.3.1 Goal, Question and Metrics. To assist and guide the interview
with practitioners in industry, we used the GQM approach. GQM
represents a systematic approach for tailoring and integrating goals
to models of the software processes, products and quality perspec-
tives of interest, based upon the specific needs of the project and the
organization [7]. GQM defines a certain goal, refines this goal into
questions, and defines metrics that should provide the information
to answer these questions [80].
The basic template/guidelines for goal definition is to set a pur-
pose, perspective and environment [7]. For this research the goal
was defined as: (purpose) Understand practices done in mono-
lithic systems before migrating to microservices architecture for
the purpose of characterization with respect to their effectiveness
for addressing the microservices anti-patterns (perspective) from
the point of view of experts in the area of migration from monolithic
system to microservices architecture (environment) in the context
of the software engineering community. For this goal, the following
questions were raised: Q1 : What strategies are taken before the
migration?. Q2 : What microservice anti-patterns are considered by
practitioner in the pre-migration?. Q3 : The mentioned strategies
were addressed to mitigate any anti-patterns in microservices.
Once the goal was refined into a list of questions, metrics should
be defined that provide all the quantitative information to answer
the questions in a satisfactory way. Therefore, metrics are a re-
finement of questions into a quantitative process and/or product
measurements. After all these metrics have been measured, suffi-
cient information should be available to answer the questions [80].
In the metric definitions both quantitative metrics and qualitative
metrics was used to take also a subject opinion of the intervie-
wees: (M1 ) Years of experience of the respondents. (M2 ) Understand
what were the motivations for the migration from monolithic to
microservices. (M3 ) How was the study process. (M4 ) Members in
the migration team. (M5 ) How many microservices were planned.
(M6 ) Metrics to defining the size of each microservice. (M7 ) What
was the team’s preparation time. (M8 ) What were the technologies
of the monolithic system and microservices. (M9 ) What were the
domains of the system that was migrated to microservices. (M10 )
Which anti-patterns were known by the respondents before the
interview. (M11 ) Which anti-patterns were considered in the pre-
migration phase. (M12 ) What were the approaches to separate the
monolith or create the microservices and separate the database.
3.3.2 Questions. The interview questionnaire was composed of 17
questions, which are presented in Table 1. These questions were
defined around the GQM questions and metrics. The questions was
divided in two groups. The first group has open questions about
microservices, experience of the experts, knowledge about anti-
patterns in microservices. The second group was specific of this
research. We select the insights from the systematic mapping to
develop each question.
3.3.3 Expert selection. Brooks et al. recommend the selection of
experts from industry and academia with different backgrounds and
Guilherme L. D. Villaca, Ivonei F. da Silva, and Wesley K. G. Assunção
Table 1: Interview Questionnaire
Id Grp Question
What was the motivation for you to consider the migration
1 1 from monolith to microservices in what was the context of
the monolith?
What were the steps to study/understand/research the
2 1
complexities of microservices? What training were done?
How many stakeholders participated in the pre-migration
3 1
and migration process?
How many microservices were planned in the pre-
4 1
migration phase?
Was any metric used to define the size of each
5 1 microservice? Ex: lines of code, number of features,
classes, models, etc.
What is the estimated time for each phase of the pre-
6 1 migration and migration process? Planning, Study,
Refactoring, Implementation, etc.
What roles are involved? Software engineer/architect,
7 1
developer, responsible for infrastructure etc.
What is the technology of the monolith? What technologies
are adopted for microservices? If it’s the same, why keep it?
8 1 if it changed, why did it change? If it changed how much
time was considered/spent for the learning curve of the new
technology, was investment made in hiring/training?
What is the level of knowledge and experience of the team
9 1 in relation to Object Orientation, design standards,
microservices, distributed systems, etc.
Which projects have already participated? What were the
10 1
areas/domains? How many?
Did you know about existing anti-patterns in microservices
11 2
before this interview? If so, which ones did you know?
In the pre-migration phase, was any action taken to address
anti-patterns? whether by studying what these anti-patterns
12 2
were in detail or any other approach? If yes, which anti-
pattern was considered?
What were the steps to separate the monolith into
13 2
microservices?
14 2 What was the approach to separating the database?
Has any refactoring technique or software been thought of
15 2 to eliminate other anti-patterns, other than those related to
microservices, during pre-migration?
What are your considerations regarding the pre-migration
and migration phase, what are the difficulties/barriers
16 2
envisioned and/or lessons learned that could be useful for
future migrations to microservices?
To conclude, in a possible new implementation, would
you consider developing a direct software in microservices
17 2
or would you prefer to develop in monolith and then
migrate? What are the reasons for your choice?
affiliations [10]. These authors defined several guidelines for the se-
lection of experts. For this study, the main need was for experts with
hands-on experience and a wide perspective on the topic of this
research, because the main requirement for selecting researchers
was knowledge and experience in migrating from monolithic to mi-
croservices. After analysis 11 interviewees were selected, of which
nine participated.
Mitigating Microservice Anti-patterns during the Pre-Migration of Monolith Legacy Systems
3.3.4 Interview Procedures. The interviews for this study were
carried out in November and December 2021. In all, seven inter-
views were carried out, the first of which was carried out with
three respondents simultaneously. Of the nine people who partic-
ipated in the interview, one of them stood out in terms of length
of experience, having more than 20 years of experience and hav-
ing a management position. The others ranged in roles, developer,
software engineering, back-end developer, and architect software
ranging from two to eight years of experience.
3.4 Thematic Analysis
Thematic analysis is an approach that is often used for identifying,
analyzing, and reporting patterns (themes) within data in primary
qualitative research. It minimally organizes and describes the data
set in rich detail and frequently interprets various aspects of the
research topic. Thematic analysis can be used within different the-
oretical frameworks, and it can be an essentialist or realist method
that reports experience, meanings, and the reality of participants
[18].
The steps for thematic analysis are [18]: Extract Data, Code
data, Translate codes into themes, Create a model of higher-order
themes, and Assess the trustworthiness of the synthesis. Codes are
descriptive labels that are applied to segments of text from each
study. Coding is the process of examining and organizing the data
contained in each study of the systematic review. A theme at a
minimum describes and organizes possible observations or at the
maximum interprets aspects of the phenomenon. The themes that
emerged will be further explored and interpreted to create a model
consisting of higher-order themes and the relationships between
them. The aim is to return to the original research questions and the
theoretical interests that support them, and to approach them with
arguments based on the themes that emerged in the exploration of
the texts.
4 RESULTS AND ANALYSIS
In this section we discuss the results based on the evidence we
collected. A thematic synthesis map was created to graphically
represent the codes/themes and their relationships so that we can
answer the main research question.
4.1 Systematic Literature Mapping Analysis
After the initial reading of the main points of each study, we used a
table with rows and columns, where the first column was the article
ID and each subsequent column represented a research question.
When analyzing the responses of the SLM, they were divided into
categories that represented the study (by analysing title, abstract
and keywords of each study): Modularization, Decomposition, and
Technical Debt. Within Technical Debt, three subcategories were
found: Anti-patterns, Architectural Debt, and Refactoring.
• Modularization: In this category, the primary sources were
grouped focusing on modularizing the monolithic system.
We collected the strategies to achieve this goal and assist in
the definition of each microservice. We noticed that there
is a tendency to seek the modularized system, or even de-
velop a modularized monolithic system in order to migrate
to microservices more easily in the future.
SBQS 2022, July, 2022, Curitiba, PR
• Decomposition: In this category, we grouped studies that
aimed to extract microservices from the monolithic system,
using strategies or frameworks for this.
• Technical Debt: Studies dealing with problems of the mono-
lith related to architectural defects, smells, the need for refac-
toring, and so on.
– Anti-patterns: Studies that focus on analyzing problems
that occurred in the phase of migration from monoliths to
microservices, which show a lack of understanding about
the complexity of microservices.
– Architectural debts: Studies that showed types of defects
related to the difficulty of maintaining a system.
– Refactoring: Studies that show refactoring techniques or
strategies as a way to migrate the monolithic to microser-
vices.
After organizing and separating the findings the following strate-
gies emerged: adoption of Domain-Driven Design (DDD), adoption
of the Evolvability Assurance, Strategy to Identify Tight Coupling,
Group Entities, and Classify Data in Business Subsystem. Each
strategy was transformed in code (Table 2).
4.2 Rapid Review Analysis
When analyzing the texts, it was difficult to extract the strategies
in order to answer our question. This is due to the novelty of this
research, because the anti-patterns were only recently cataloged
and not all practitioners know them. For this reason it is not al-
ways the case that practitioners reason on how to to mitigate such
anti-patterns. But we were able to classify the information into
the following categories after a thorough analysis of the collected
responses:
• Log Aggregation: Use of a log tool to assist developers to
identify which bugs and functionalities that could be decom-
posed in microservices;
• Data: Look at data first, to analyze entities and group them
in subsystems;
• Coupling and Cohesion: Look at coupling and cohesion to
identify bottlenecks in the system, this category also could
be related to refactoring in SLM categories;
• Strangler Pattern: Strategy to decompose the monolithic in
migration phase, develop each functionality until the mono-
lithic is extinct.
• Modularization: Use of strategies, like DDD, for modular-
ization. Category also founded in SLM.
When analyzing each category, the following strategies emerged:
Use of Backlog strategy, Look at data first, measure coupling and
cohesion, use of strangler pattern and DDD for modularization.
Each strategy was transformed in code (Table 2).
4.3 Interview Analysis
The interview analysis process was different because we did an-
other type of data collection, seeking initial information that could
help to understand the migration. Additionally, we considered the
operational context of each interviewee. Thus, different categories
were observed, but not all of them were transformed into code. The
categories defined were planning, anti-patterns knowledge, anti-
patterns mitigate strategies, anti-patterns decomposition strategies
SBQS 2022, July, 2022, Curitiba, PR Guilherme L. D. Villaca, Ivonei F. da Silva, and Wesley K. G. Assunção

and lessons learned. The list of categories observed in the interviews Table 2: Methodology Codes
are as follows:
Code Description SLM RR I
• Planning: how was the planning process from pre-migration
and migration; Strategy to Ways to
• Anti-patterns knowledge: what was the knowledge of Identify Tight prevent high ✓
anti-patterns of interviewee and members; Coupling coupling in the system
• Anti-patterns mitigate strategies: what was the strategies Ways to separate
to mitigate anti-patterns; Classify DB in and classify tables
• Anti-patterns decomposition strategies: what was the Business of database based on ✓
strategies to decompose the microservices; Subsystem business
• Lessons learned: what was the lessons learned of the pre- Domain
migration and migration process. Ways to ensure
Group Entities group entities based ✓
Of the categories analysed the following strategies appear: DDD, on Business Domain
Clean Architecture and Twelve Factor App (Table 2). Use of methods,
and tools to
Evolvability
4.4 Themes Assurance
improve evolvability ✓
The codes founded in the three phases of this research (Table 2), long-term
were grouped and transformed in the themes [18], which are: mod- development
ularity, data and organization culture, as presented in Table 3. Measure Strategy to
Modularity includes DDD, which was mentioned in SLM, RR, coupling and Identify Tight ✓
and Interview; strangler pattern, identify tight coupling, and use cohesion Coupling
of backlog. Data includes group entities, classify DB in business Analyse entities
subsystem, and data first. Organizational Culture includes use of Look at data and group them in
✓
clean architecture, twelve factor app, and evolvability assurance. first subsystems before
The process for thematic analysis is to reduce overlap and trans- looking at code
form codes into themes and then create models or high order themes. Extract each
For this research we did not feel the need for do this process of Use of strangler functionality until the
✓
create a theme and then another high order themes, because we did pattern monolithic
not have enough data. Thus, from codes we could extract themes is extinct
and this make sense at the time [18]. Use of Backlog Use of a log
✓
As presented in Figure 1, we grouped the codes into themes. Mod- strategy tool to assist developers
ularity was linked with Data because each module, or later each Using DDD for a
microservice, will have his own data, so it makes sense that these better understanding
strategies could be related, and on the other hand, this Databases DDD for Modu- of the domain and find
✓ ✓ ✓
strategies could not be inside Modularity theme because you look at larization the right
data before you look at the code, or at the system as a whole. Clean boundaries for each
Architecture was linked with DDD because this was mentioned in microservice
the interviews, as a strategy to take in parallel and more than a Create layered
strategy to create a microservice, clean architecture it is to imple- Clean architectures that are
✓
ment in an intrinsic way inside the organization. The same way we Architecture simple and, easy
linked twelve factor app to data first, because makes sense to use a to maintain.
strategy that can help the organization to maintain the system in a 12 principles of
consistent manner, which means to start to use an approach and making software that
Twelve Factor
stick with it at the end. can be scaled quickly ✓
App
and maintained
in a consistent manner
Organizational
Data Modularity
Culture

Group Entities Data First Strangler Pattern DDD Clean Architecture

Evolvability

Classify DB in Business
Identify Tight Backlog
Assurance

4.5 Discussion
Coupling Twelve Factor App

Subsystem
The main research question came clear so that the use of some
strategies can help to mitigate anti-patterns in microservices. We
Figure 1: Thematic map of strategies to mitigate anti-patterns highlight the use of DDD [4, 24, 50, 62, 71, 77] or Strangler Pattern
in microservices [28, 47, 67, 78] to mitigate megaservice and wrong cuts.
Any of Data theme to mitigate shared persistence. Relational data
needs to be designed conceptually from the start, before one even
Mitigating Microservice Anti-patterns during the Pre-Migration of Monolith Legacy Systems
Table 3: Themes & Codes
Theme Code SLM RR
Modularity Domain-Driven Design ✓ ✓
Strangler Pattern ✓ This study reported ways to mitigate anti-patterns in microservices
Identify Tight Coupling ✓ ✓
Backlog ✓ ated. The assumption is that a monolithic system with problems,
Data Group Entities ✓ when modernized to a new architecture, could face similar prob-
Classify DB in Business
✓ ✓
SubSystem
Data First ✓ multi-method study including a systematic literature mapping, a
Organizational
Clean Architecture
Culture
Twelve Factor App
Evolvability Assurance ✓ Microservices is still a new topic in the field of software engineer-
consider the placement and design of functions to carry out busi-
ness processes [33]. Group entities strategy is to define similarity
measures between domain entities and use a clustering algorithm
that returns clusters of entities [72].
Each of the organizational culture themes can mitigate shared
libraries and cyclic dependencies as mentioned by the interviewees,
as well as concerns about maintaining and developing clean and
scalable code in the long term. The use of backlog strategy can also
mitigate megaservice and microservice greedy because you can
measure if a functionality uses few resources or if it can be aggre-
gated with another [62, 76]. Also identify tight coupling can help to
mitigate shared libraries. When designing applications, avoid using
library code that increases coupling between applications, so that
developers building clients are free to make different technology
choices if that becomes advantageous [21]. Rewrite all services
into microservices at once can be mitigated using strangler pattern
[28, 47, 67, 78].
These strategies found in this study are not a guarantee to avoid
anti-patterns, they are only ways to mitigate them. It is important
to keep in mind that these strategies must be taken along with
good planning, team training, investment in consulting when pos-
sible, and other measures that can ensure that the migration to
microservices can be done gradually and with as few errors as
possible.
4.6 Limitations of the study
The limitations of the proposed strategies for mitigate anti-patterns
in microservices are listed as follows:
• Strategies were defined at a high level, more information
could be extracted in each step from the methodology, espe-
cially from the interviewees;
• Each strategy could be more explored, e.g., more studies
from DDD could be analyzed and detailed strategies could
be described;
• Strategies comparable to those that appeared in this study
could be analyzed, e.g., for clean architecture there would
be other strategies that could have the same effect.
• Although they produced good responses, the interviews con-
ducted for this study could be done differently, with a longer
SBQS 2022, July, 2022, Curitiba, PR
implementation time that would bring more respondents
into the study.
I
✓ 5 CONCLUSION
✓ by first looking at the monolithic system before migration is initi-
lems in the future, i.e., a buggy system and the only thing that has
changed is the architecture. For this investigation, we conducted a
rapid review, an interview, and a thematic analysis. We were able
✓
to find ten strategies that can be used to mitigate the anti-patterns
✓ revealed in this study.
ing and there is still a lot of work emerging on this subject, perhaps
new anti-patterns will emerge in the future and this research needs
to be revised and updated. It may also be necessary to start from the
point of direct development in microservices and use the strategies
mentioned in this research to see if anti-patterns can be mitigated.
The strategies founded in this research can be validated in another
studies, like a case study, to see if the strategies can be applied,
what is the scenario that would be applied and what would be the
results.
REFERENCES
[1] Manel Abdellatif, Anas Shatnawi, Hafedh Mili, Naouel Moha, Ghizlane El
Boussaidi, Geoffrey Hecht, Jean Privat, and Yann-Gaël Guéhéneuc. 2021. A
taxonomy of service identification approaches for legacy software systems
modernization. Journal of Systems and Software 173 (2021), 110868. https:
//doi.org/10.1016/j.jss.2020.110868
[2] Muhammad Abdullah, Waheed Iqbal, and Abdelkarim Erradi. 2019. Unsupervised
Learning Approach for Web Application Auto-Decomposition into Microservices.
Journal of Systems and Software 151 (02 2019). https://doi.org/10.1016/j.jss.2019.
02.031
[3] Mohammad Javad Amiri. 2018. Object-Aware Identification of Microservices.
https://doi.org/10.1109/SCC.2018.00042
[4] Philippe Assouline and Victor Grazi. 2017. Perspective on Architectural Fitness
of Microservices. https://www.infoq.com/articles/Microservices-Architectural-
Fitness/.
[5] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. 2015. Migrating to
Cloud-Native Architectures Using Microservices: An Experience Report. https:
//doi.org/10.1007/978-3-319-33313-7_15
[6] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. 2016. Microservices
Architecture Enables DevOps: an Experience Report on Migration to a Cloud-
Native Architecture. IEEE Software 33 (05 2016), 1–1. https://doi.org/10.1109/MS.
2016.64
[7] V.R. Basili and H.D. Rombach. 1988. The TAME project: towards improvement-
oriented software environments. IEEE Transactions on Software Engineering 14, 6
(1988), 758–773. https://doi.org/10.1109/32.6156
[8] Justus Bogner, Jonas Fritzsch, Stefan Wagner, and Alfred Zimmermann. 2019.
Assuring the Evolvability of Microservices: Insights into Industry Practices and
Challenges. https://doi.org/10.1109/ICSME.2019.00089
[9] Antonio Brogi, Davide Neri, Jacopo Soldani, and Olaf Zimmermann. 2019. Design
principles, architectural smells and refactorings for microservices: A multivocal
review. (06 2019).
[10] Andrew Brooks, John Daly, James Miller, Marc Roper, and Murray Wood. 1989.
Reactor risk reference document - Technical Report NUREG-1150. Technical Report.
U.S. Nuclear Regulatory Commission, Office of Nuclear Regulatory Research,
Washington D.C.
[11] Ivan Candela, Gabriele Bavota, Barbara Russo, and Rocco Oliveto. 2016. Using
Cohesion and Coupling for Software Remodularization. ACM Transactions on
Software Engineering and Methodology (TOSEM) 25 (2016), 1 – 28.
[12] Andrés Carrasco, Brent van Bladel, and Serge Demeyer. 2018. Migrating towards
microservices: migration and architecture smells. 1–6. https://doi.org/10.1145/
3242163.3242164
[13] Soares S Cartaxo B., Pinto G. 2020. Rapid Reviews in Software Engineering.
(2020). https://doi.org/10.1007/978-3-030-32489-6_13
SBQS 2022, July, 2022, Curitiba, PR
[14] Luiz Carvalho, Alessandro Garcia, Wesley K. G. Assunção, Rodrigo Bonifácio,
Leonardo P. Tizzei, and Thelma Elita Colanzi. 2019. Extraction of Configurable
and Reusable Microservices from Legacy Systems: An Exploratory Study. In
Proceedings of the 23rd International Systems and Software Product Line Conference
- Volume A (Paris, France) (SPLC ’19). Association for Computing Machinery, New
York, NY, USA, 26–31. https://doi.org/10.1145/3336294.3336319
[15] Andreas Christoforou, Lambros Odysseos, and Andreas Andreou. 2019. Migration
of Software Components to Microservices: Matching and Synthesis. In Proceedings
of the 14th International Conference on Evaluation of Novel Approaches to Software
Engineering (Heraklion, Crete, Greece) (ENASE 2019). SCITEPRESS - Science and
Technology Publications, Lda, Setubal, PRT, 134–146. https://doi.org/10.5220/
0007732101340146
[16] Michel Cojocaru, Alexandru Uta, and Ana-Maria Oprescu. 2019. MicroValid: A
Validation Framework for Automatically Decomposed Microservices. In 2019 IEEE
International Conference on Cloud Computing Technology and Science (CloudCom).
78–86. https://doi.org/10.1109/CloudCom.2019.00023
[17] Comella-Dorda, Wallnau, Seacord, and Robert. 2000. A survey of black-box mod-
ernization approaches for information systems. In Proceedings 2000 International
Conference on Software Maintenance. 173–183. https://doi.org/10.1109/ICSM.2000.
883039
[18] Daniela S. Cruzes and Tore Dyba. 2011. Recommended Steps for Thematic
Synthesis in Software Engineering. In 2011 International Symposium on Empirical
Software Engineering and Measurement. 275–284. https://doi.org/10.1109/ESEM.
2011.36
[19] Saulo S. de Toledo, Antonio Martini, and Dag I.K. Sjøberg. 2021. Identifying
architectural technical debt, principal, and interest in microservices: A multiple-
case study. Journal of Systems and Software 177 (2021), 110968. https://doi.org/
10.1016/j.jss.2021.110968
[20] Utkarsh Desai, Sambaran Bandyopadhyay, and Srikanth Tamilselvam. 2021.
Graph Neural Network to Dilute Outliers for Refactoring Monolith Applica-
tion. (02 2021).
[21] Amit Deshpande and Nampreet Pal Singh. 2020. Challenges and pat-
terns for modernizing a monolithic application into microservices.
https://developer.ibm.com/articles/challenges-and-patterns-for-modernizing-
a-monolithic-application-into-microservices/.
[22] Paolo Di Francesco, Patricia Lago, and Ivano Malavolta. 2018. Migrating Towards
Microservice Architectures: An Industrial Survey. In 2018 IEEE International
Conference on Software Architecture (ICSA). 29–2909. https://doi.org/10.1109/
ICSA.2018.00012
[23] Daniel Escobar, Diana Cárdenas, Rolando Amarillo, Eddie Castro, Kelly Garcés,
Carlos Parra, and Rubby Casallas. 2016. Towards the understanding and evo-
lution of monolithic applications as microservices. In 2016 XLII Latin American
Computing Conference (CLEI). 1–11. https://doi.org/10.1109/CLEI.2016.7833410
[24] Chen-Yuan Fan and Shang-Pin Ma. 2017. Migrating Monolithic Mobile Ap-
plication to Microservice Architecture: An Experiment Report. In 2017 IEEE
International Conference on AI Mobile Services (AIMS). 109–112. https://doi.org/
10.1109/AIMS.2017.23
[25] Martin Fowler. 2014. Microservices a definition of this new architectural term.
http://martinfowler.com/articles/microservices.html.
[26] Andrei Furda, Colin Fidge, Olaf Zimmermann, Wayne Kelly, and Alistair Barros.
2018. Migrating Enterprise Legacy Source Code to Microservices: On Multite-
nancy, Statefulness, and Data Consistency. IEEE Software 35, 3 (2018), 63–72.
https://doi.org/10.1109/MS.2017.440134612
[27] Vahid Garousi, Michael Felderer, and Mika Mäntylä. 2017. Guidelines for includ-
ing the grey literature and conducting multivocal literature reviews in software
engineering. (07 2017).
[28] Amit Goel. 202. CHOOSING THE RIGHT STRATEGY TO MIGRATE YOUR
MONOLITHIC APPLICATION TO A MICROSERVICES-BASED ARCHITEC-
TURE. shorturl.at/deJV7.
[29] Amit Gupta. 2021. From Monolith to Microservices: An epic Migration
Journey. https://dzone.com/articles/from-monolith-to-microservices-an-epic-
migration-j.
[30] Dan Haywood and Thomas Betts. 2017. In Defence of the Monolith, Part 1.
https://www.infoq.com/articles/monolith-defense-part-1/.
[31] Alexis Henry and Youssef Ridene. 2020. Migrating to Microservices. Springer
International Publishing, Cham, 45–72. https://doi.org/10.1007/978-3-030-31646-
4_3
[32] Xiaoli Huang, Jimmy Lin, and Dina Demner-Fushman. 2006. Evaluation of
PICO as a Knowledge Representation for Clinical Questions. AMIA ... Annual
Symposium proceedings. AMIA Symposium (02 2006), 359–363.
[33] Todd Hubers. 2021. How big is a microservice? https://medium.com/geekculture/
the-size-of-a-microservice-b9e6bc90475.
[34] B. Jambunathan and Kalpana Y. 2016. Multi cloud deployment with containers. 8
(02 2016), 421–428.
[35] Andrea Janes and Barbara Russo. 2019. Automatic Performance Monitoring and
Regression Testing During the Transition from Monolith to Microservices. In
2019 IEEE International Symposium on Software Reliability Engineering Workshops
(ISSREW). 163–168. https://doi.org/10.1109/ISSREW.2019.00067
Guilherme L. D. Villaca, Ivonei F. da Silva, and Wesley K. G. Assunção
[36] Thorben Janssen. 2021. From Monolith to Microservices – Migrating a Persistence
Layer. https://thorben-janssen.com/monolith-to-microservices-persistence-
layer/.
[37] Wuxia Jin, Ting Liu, Qinghua Zheng, Di Cui, and Yuanfang Cai. 2018.
Functionality-Oriented Microservice Extraction Based on Execution Trace Clus-
tering. 211–218. https://doi.org/10.1109/ICWS.2018.00034
[38] Fernando Kamei, Igor Wiese, Crescencio Lima, Ivanilton Polato, Vilmar Nepo-
muceno, Waldemar Ferreira, Márcio Ribeiro, Carolline Pena, Bruno Cartaxo,
Gustavo Pinto, and Sérgio Soares. 2021. Grey Literature in Software Engineer-
ing: A critical review. Information and Software Technology 138 (2021), 106609.
https://doi.org/10.1016/j.infsof.2021.106609
[39] Alex Kaplunovich. 2019. ToLambda–Automatic Path to Serverless Architectures.
In 2019 IEEE/ACM 3rd International Workshop on Refactoring (IWoR). 1–8. https:
//doi.org/10.1109/IWoR.2019.00008
[40] Justas Kazanaviius and D. Mazeika. 2020. Analysis of Legacy Monolithic Software
Decomposition into Microservices. In Doctoral Consortium/Forum.
[41] Justas Kazanavičius and Dalius Mažeika. 2019. Migrating Legacy Software to
Microservices Architecture. In 2019 Open Conference of Electrical, Electronic and
Information Sciences (eStream). 1–5. https://doi.org/10.1109/eStream.2019.8732170
[42] Gabor Kecskemeti, A. Marosi, and A. Kertesz. 2016. The ENTICE approach to
decompose monolithic services into microservices. 2016 International Conference
on High Performance Computing & Simulation (HPCS) (2016), 591–596.
[43] Ravi Khadka, Prajan Shrestha, Bart Klein, Amir Saeidi, Jurriaan Hage, Slinger
Jansen, Edwin van Dis, and Magiel Bruntink. 2015. Does software modernization
deliver what it aimed for? A post modernization analysis of five software modern-
ization case studies. In 2015 IEEE International Conference on Software Maintenance
and Evolution (ICSME). 477–486. https://doi.org/10.1109/ICSM.2015.7332499
[44] Lisa J. Kirby, Evelien Boerstra, Zachary J.C. Anderson, and Julia Rubin. 2021.
Weighing the Evidence: On Relationship Types in Microservice Extraction. In
2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC).
358–368. https://doi.org/10.1109/ICPC52881.2021.00041
[45] Barbara Ann Kitchenham and Stuart Charters. 2007. Guidelines for performing
Systematic Literature Reviews in Software Engineering. Technical Report EBSE
2007-001. Keele University and Durham University Joint Report. https://www.
elsevier.com/__data/promis_misc/525444systematicreviewsguide.pdf
[46] Holger Knoche and Wilhelm Hasselbring. 2019. Drivers and Barriers for Mi-
croservice Adoption - A Survey among Professionals in Germany. 14 (01 2019),
1–35. https://doi.org/10.18417/emisa.14.1
[47] Dmitry Kornilov. 2020. Monolithic to microservices: Design patterns to ensure mi-
gration success. https://blogs.oracle.com/cloud-infrastructure/post/monolithic-
to-microservices-how-design-patterns-help-ensure-migration-success.
[48] Dilshodbek Kuryazov, Dilshod Jabborov, and Bekmurod Khujamuratov. 2020.
Towards Decomposing Monolithic Applications into Microservices. In 2020 IEEE
14th International Conference on Application of Information and Communication
Technologies (AICT). 1–4. https://doi.org/10.1109/AICT50176.2020.9368571
[49] Rodrigo Laigner, Sergio Lifschitz, Marcos Kalinowski, Marcus Poggi, and Mar-
cos Antonio Vaz Salles. 2019. Towards a Technique for Extracting Relational
Actors from Monolithic Applications. https://doi.org/10.5753/sbbd.2019.8814
[50] Lavann, EdPrice, and neilpeterson. 2021. Migrate a monolith application to
microservices using domain-driven design. https://docs.microsoft.com/en-us/
azure/architecture/microservices/migrate-monolith.
[51] Grahan Lea. 2016. Why “Don’t Use Shared Libraries in Microservices” is Bad
Advice. https://www.grahamlea.com/2016/04/shared-libraries-in-microservices-
bad-advice/.
[52] Valentina Lenarduzzi, Francesco Lomio, Nyyti Saarimäki, and Davide Taibi. 2020.
Does Migrating a Monolithic System to Microservices Decrease the Technical
Debt? Journal of Systems and Software 169 (07 2020). https://doi.org/10.1016/j.
jss.2020.110710
[53] Alessandra Levcovitz, Ricardo Terra, and Marco Valente. 2016. Towards a Tech-
nique for Extracting Microservices from Monolithic Enterprise Systems. (05
2016).
[54] Shanshan Li, He Zhang, Zijia Jia, Chenxing Zhong, Cheng Zhang, Zhihao Shan,
Jinfeng Shen, and Muhammad Ali Babar. 2021. Understanding and addressing
quality attributes of microservices architecture: A Systematic literature review.
Information and Software Technology 131 (2021), 106449. https://doi.org/10.1016/
j.infsof.2020.106449
[55] David S. Linthicum. 2016. Practical Use of Microservices in Moving Workloads
to the Cloud. IEEE Cloud Computing 3, 5 (2016), 6–9. https://doi.org/10.1109/
MCC.2016.114
[56] Isela Macia, Joshua Garcia, Daniel Popescu, Alessandro Garcia, Nenad Med-
vidovic, and Arndt von Staa. 2012. Are Automatically-Detected Code Anom-
alies Relevant to Architectural Modularity? An Exploratory Analysis of Evolv-
ing Systems. In Proceedings of the 11th Annual International Conference on
Aspect-Oriented Software Development (Potsdam, Germany) (AOSD ’12). As-
sociation for Computing Machinery, New York, NY, USA, 167–178. https:
//doi.org/10.1145/2162049.2162069
[57] Prabal Mahanta and Suchin Chouta. 2020. Translating a Legacy Stack to Microser-
vices Using a Modernization Facade with Performance Optimization for Container
Mitigating Microservice Anti-patterns during the Pre-Migration of Monolith Legacy Systems SBQS 2022, July, 2022, Curitiba, PR

Deployments. 143–154. https://doi.org/10.1007/978-3-030-40907-4_14 2019).

[58] Sander Mak. 2017. Modules vs. microservices: Apply modular system design [82] Davide Taibi and Valentina Lenarduzzi. 2018. On the Definition of Microservice
principles while avoiding the operational complexity of microservices. https: Bad Smells. IEEE Software 35, 3 (2018), 56–62. https://doi.org/10.1109/MS.2018.
//www.oreilly.com/radar/modules-vs-microservices/. 2141031
[59] Christopher Marshall, Pearl Brereton, and Barbara Kitchenham. 2015. Tools to [83] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2017. Processes, Motivations
Support Systematic Reviews in Software Engineering: A Cross-Domain Survey and Issues for Migrating to Microservices Architectures: An Empirical Investi-
Using Semi-Structured Interviews. In Proceedings of the 19th International Con- gation. IEEE Cloud Computing 4 (10 2017). https://doi.org/10.1109/MCC.2017.
ference on Evaluation and Assessment in Software Engineering (Nanjing, China) 4250931
(EASE ’15). Association for Computing Machinery, New York, NY, USA, Article [84] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2019. Microservices Anti
26, 6 pages. https://doi.org/10.1145/2745802.2745827 Patterns: A Taxonomy. https://doi.org/10.1007/978-3-030-31646-4_5
[60] Genc Mazlami, Jürgen Cito, and Philipp Leitner. 2017. Extraction of Microservices [85] Davide Taibi and Kari Systä. 2019. From Monolithic Systems to Microservices: A
from Monolithic Software Architectures. In 2017 IEEE International Conference Decomposition Framework based on Process Mining. https://doi.org/10.5220/
on Web Services (ICWS). 524–531. https://doi.org/10.1109/ICWS.2017.61 0007755901530164
[61] Sam Newman and Leandro Guimarães. 2021. Migrating Monoliths to Microser- [86] Rafik Tighilt, Manel Abdellatif, Naouel Moha, Hafedh Mili, Ghizlane El-Boussaidi,
vices with Decomposition and Incremental Changes. https://www.infoq.com/ Jean Privat, and Yann-Gaël Guéhéneuc. 2020. On the Study of Microservices
articles/migrating-monoliths-to-microservices-with-decomposition/. Antipatterns: a Catalog Proposal. 1–13. https://doi.org/10.1145/3424771.3424812
[62] Sam Newman and Wes Reisz. 2020. Sam Newman: Monolith to Microservices. [87] Saulo Toledo, Antonio Martini, and Dag Sjøberg. 2020. Improving Agility by
https://www.infoq.com/podcasts/monolith-microservices/. Managing Shared Libraries in Microservices. 195–202. https://doi.org/10.1007/978-
[63] Luis Nunes, Nuno Santos, and António Silva. 2019. From a Monolith to a Mi- 3-030-58858-8_20
croservices Architecture: An Approach Based on Transactional Contexts. 37–52. [88] José Valdivia, Alonso Lora-Gonzalez, Xavier Limón, Karen Verdín, and Jorge
https://doi.org/10.1007/978-3-030-29983-5_3 Ocharán-Hernández. 2020. Patterns Related to Microservice Architecture: a
[64] Ilaria Pigazzini, Francesca Arcelli Fontana, and Andrea Maggioni. 2019. Tool Multivocal Literature Review. Programming and Computer Software 46 (12 2020),
Support for the Migration to Microservice Architecture: An Industrial Case Study. 594–608. https://doi.org/10.1134/S0361768820080253
In Software Architecture, Tomas Bures, Laurence Duchien, and Paola Inverardi [89] Andrew Walker, Dipta Das, and Tom Černý. 2020. Automated Code-Smell Detec-
(Eds.). Springer International Publishing, Cham, 247–263. tion in Microservices Through Static Analysis: A Case Study. Applied Sciences 10
[65] Ilaria Pigazzini, Francesca Arcelli Fontana, Valentina Lenarduzzi, and Davide (11 2020). https://doi.org/10.3390/app10217800
Taibi. 2020. Towards Microservice Smells Detection. In Proceedings of the 3rd [90] Yingying Wang, Harshavardhan Kadiyala, and Julia Rubin. 2021. Promises and
International Conference on Technical Debt (Seoul, Republic of Korea) (TechDebt challenges of microservices: an exploratory study. Empirical Software Engineering
’20). Association for Computing Machinery, New York, NY, USA, 92–97. https: 26 (07 2021). https://doi.org/10.1007/s10664-020-09910-y
//doi.org/10.1145/3387906.3388625 [91] Daniele Wolfart, Wesley K. G. Assunção, Ivonei F. da Silva, Diogo C. P. Domin-
[66] Zhongshan Ren, Wei Wang, Guoquan Wu, Chushu Gao, Wei Chen, Jun Wei, and gos, Ederson Schmeing, Guilherme L. Donin Villaca, and Diogo do N. Paza.
Tao Huang. 2018. Migrating Web Applications from Monolithic Structure to 2021. Modernizing Legacy Systems with Microservices: A Roadmap. In Eval-
Microservices Architecture. In Proceedings of the Tenth Asia-Pacific Symposium uation and Assessment in Software Engineering (Trondheim, Norway) (EASE
on Internetware (Beijing, China) (Internetware ’18). Association for Computing 2021). Association for Computing Machinery, New York, NY, USA, 149–159.
Machinery, New York, NY, USA, Article 7, 10 pages. https://doi.org/10.1145/ https://doi.org/10.1145/3463274.3463334
3275219.3275230 [92] Christian Zirkelbach, Alexander Krause, and Wilhelm Hasselbring. 2019. Modu-
[67] Chris Richardson. 2016. Refactoring a Monolith into Microservices. https://www. larization of Research Software for Collaborative Open Source Development. (07
nginx.com/blog/refactoring-a-monolith-into-microservices/. 2019).
[68] Chris Richardson. 2021. Refactoring a monolith to microservices. https: [93] C. Zirkelbach, Alexander Krause, and W. Hasselbring. 2019. On the Modulariza-
//microservices.io/refactoring/. tion of ExplorViz towards Collaborative Open Source Development.
[69] Wiebe Roos. 2020. Getting ready for microservices – strangling the mono-
lith. https://amazicworld.com/getting-ready-for-microservices-breaking-down-
the-monolith/.
[70] Bernd Ruecker. 2019. Complex Event Flows in Distributed Systems. https:
//www.infoq.com/presentations/event-flow-systems/.
[71] Vadim Samokhin. 2018. Why Microservices Fail. https://hackernoon.com/why-
microservices-fail-6cdc006f9540.
[72] Nuno Santos and António Rito Silva. 2020. A Complexity Metric for Microser-
vices Architecture Migration. In 2020 IEEE International Conference on Software
Architecture (ICSA). 169–178. https://doi.org/10.1109/ICSA47634.2020.00024
[73] Anika Sayara, Md. Shamim Towhid, and Md. Shahriar Hossain. 2017. A proba-
bilistic approach for obtaining an optimized number of services using weighted
matrix and multidimensional scaling. In 2017 20th International Conference of
Computer and Information Technology (ICCIT). 1–6. https://doi.org/10.1109/
ICCITECHN.2017.8281804
[74] Anfel Selmadji, Abdelhak Seriai, Hinde Bouziane, Christophe Dony, and Rahina
Mahamane. 2018. Re-architecting OO Software into Microservices: 7th IFIP WG 2.14
European Conference, ESOCC 2018, Como, Italy, September 12-14, 2018, Proceedings.
65–73. https://doi.org/10.1007/978-3-319-99819-0_5
[75] Atsushi Shimoda and Tsubasa Sunada. 2018. Priority Order Determination
Method for Extracting Services Stepwise from Monolithic System. In 2018 7th
International Congress on Advanced Applied Informatics (IIAI-AAI). 805–810. https:
//doi.org/10.1109/IIAI-AAI.2018.00165
[76] Sigma. 2021. MIGRATING MONOLITH TO MICROSERVICES: STEP-BY-STEP
GUIDE. https://sigma.software/about/media/migrating-monolith-microservices-
step-step-guide.
[77] Hugo Silva, Glauco Carneiro, and Miguel Monteiro. 2019. Towards a Roadmap for
the Migration of Legacy Software Systems to a Microservice based Architecture.
37–47. https://doi.org/10.5220/0007618400370047
[78] Alice Sitnikova. 2021. Monolith vs Microservices: Everything You Need To Know.
https://bambooagile.eu/insights/monolith-vs-microservices/.
[79] Jacopo Soldani, Damian Tamburri, and Willem-Jan Heuvel. 2018. The Pains and
Gains of Microservices: A Systematic Grey Literature Review. Journal of Systems
and Software 146 (09 2018). https://doi.org/10.1016/j.jss.2018.09.082
[80] Rini Solingen and Egon Berghout. 1999. The Goal/Question/Metric Method: A
Practical Guide for Quality Improvement of Software Development. (01 1999).
[81] Davide Taibi, Florian Auer, Valentina Lenarduzzi, and Michael Felderer. 2019.
From Monolithic Systems to Microservices: An Assessment Framework. (09