Exploring the Pros and Cons of Monolithic Applications versus

Microservices

Daniel dos Santos Krug

, Rafael Chanin

and Afonso Sales

School of Technology, PUCRS, Porto Alegre, RS, Brazil

Keywords:

Microservices Architecture, Monolithic Applications, Architectural Decision Making.

Abstract:

Microservices architecture emerged as an alternative to monolith architecture. With monoliths, applications

are developed in entire blocks that communicate internally, manage their data usually in a single database,

and each new feature demands the deployment of the application as a whole. On the other hand, microser-

vices splits the application into smaller blocks with unique responsibilities, using lightweight communication

mechanisms and managing their own data. This new architecture has several advantages, but it also has some

disadvantages. From the understanding of these advantages and disadvantages, the main goal of this research

is to identify how the two architectures have been used in professional practices. As well as how the academy

can help in the understanding that if the microservices architecture entails a longer development time for the

applications, in order to understand when the decision for an architecture may be more appropriate with an-

other in software development. To fulﬁll the explained objective, it is intended to carry out a systematic study

with the snowballing technique, research in the grey literature and a survey with specialists.

1 INTRODUCTION

The microservices architecture decomposes tradi-

tional monolithic applications into smaller, au-

tonomous services (Richardson, 2016). These ser-

vices, possibly written in different languages, interact

through APIs and are commonly managed in contain-

ers such as Docker and Kubernetes (Bernstein, 2014),

facilitating deployment across varied environments.

Early academic studies on microservices date

back to the mid-2010s (Viennot et al., 2015; Stubbs

et al., 2015), with discussions on the term’s origins

remaining unclear. Microservices offer several advan-

tages over monolithic architectures, such as faster de-

livery, improved scalability, and increased autonomy

(Soldani et al., 2018). These beneﬁts stem from prac-

tices as Domain Driven Design (Merson and Yoder,

2020) and its bounded contexts, promoting a modu-

lar structure ideal for larger development teams and

independent deployment, while allowing for diverse

technologies.

However, microservices also introduce chal-

lenges, including security concerns, as each service

https://orcid.org/0009-0008-8984-7801

https://orcid.org/0000-0002-6293-7419

https://orcid.org/0000-0001-6962-3706

requires individual protection (Yarygina and Bagge,

2018), and network performance issues due to API-

based communication (Liu et al., 2020). Data con-

sistency is another problem, as each service manages

its data, potentially leading to inconsistencies (Kholy

and Fatatry, 2019).

These disadvantages are well-studied and can

be mitigated during development. Nonetheless, the

added complexity and cost of developing communi-

cation layers, ensuring security, and maintaining data

consistency make the development process more de-

manding, which is the focus of this research.

It is crucial to note that this research does not dis-

courage the use of microservices; when properly im-

plemented, the architecture’s advantages often make

it the preferred choice for many applications.

The research foundation and examples highlight

signiﬁcant beneﬁts of adopting a microservices ar-

chitecture. However, it also reveals complexities not

fully addressed by the scientiﬁc community, suggest-

ing areas for further exploration.

Building on the aforementioned insights, and

given the absence of literature speciﬁcally address-

ing the potential increase in software development

time with microservices, this study proposes an ex-

ploratory investigation into whether this issue is sig-

niﬁcant. The study’s goal is to elucidate the pros

256

Krug, D., Chanin, R. and Sales, A.

Exploring the Pros and Cons of Monolithic Applications versus Microservices.

DOI: 10.5220/0012703300003690

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) - Volume 2, pages 256-263

ISBN: 978-989-758-692-7; ISSN: 2184-4992

and cons of implementing monolithic or microser-

vices architectures in software development, provid-

ing a balanced perspective to aid developers in mak-

ing informed architectural decisions.

The main research question of this work is formu-

lated as follows: “How can developers practicing mi-

croservices architecture be supported in making de-

cisions regarding its use or the choice of traditional

architectures, such as monoliths?”

The overarching goal of this research is to discern

the conditions under which monolithic architecture is

adequate for application development and when mi-

croservices present a more favorable option. The spe-

ciﬁc objective of the research is to create a recom-

mendation guide that assists developers, considering

the characteristics of the software to be developed, in

deciding between using microservices architecture or

monolithic architecture.

The remainder of this paper is structured as fol-

lows: Section 2 outlines the research methodology.

Section 3 discusses the ﬁndings from the analysis of

the proposed methodological steps. The conclusion

and future work are presented in Section 4.

2 METHODOLOGY

A Multivocal Literature Review (MLR) proposed by

Garousi et al. (Garousi et al., 2019) was conducted,

focusing on the execution of snowballing (Wohlin,

2014) - to obtain academic studies on the topic re-

search - as well as in the Grey Literature Review

guidelines, which consider the knowledge available in

non-academic sources, which are relevant to the soft-

ware industry (Figure 1).

Figure 1: Methodology stages.

2.1 Snowballing Process

To understand the academic community’s perspec-

tive on the increased development time associated

with choosing a microservices architecture, the snow-

balling methodology was employed. This systematic

study approach starts with an initial selection of arti-

cles, using their references and citations for a compre-

hensive review (Wohlin, 2014). It involves "backward

snowballing" (using references) and "forward snow-

balling" (using citations), with each round of selec-

tion considered an “iteration”. Iterations continue un-

til no more relevant articles meeting the inclusion and

exclusion criteria are found.

The inclusion criteria for the snowballing process

and subsequent iterations are: articles discussing the

advantages and disadvantages of using microservices;

articles in English or Portuguese. The exclusion cri-

teria include: grey literature works, to be covered in

the grey literature review; studies not in English or

Portuguese; theses and dissertations; books. These

results are presented in Section 3.1.

2.2 Grey Literature Review Process

The term “grey literature” encompasses a variety of

deﬁnitions with varying degrees of interconnected-

ness. The ﬁrst ofﬁcial deﬁnition was introduced at

the Third International Conference on Grey Literature

in Luxembourg, 1997, conceptualizing it as unpub-

lished primary studies containing information from

several sectors like government, academia, business,

and the electronic industry, not controlled by commer-

cial publishers. This deﬁnition was later expanded in

2004 at the same conference to include academic and

industrial reports, as well as dissertations and theses.

In 2010, at the Prague conference, the concept of

grey literature was further reﬁned to address intellec-

tual property issues related to internet-based works.

Grey literature now includes documents from govern-

mental, academic, business, and industrial levels, in

both print and electronic forms, protected by intellec-

tual property rights and of sufﬁcient quality for col-

lection and preservation by libraries or institutions,

without being under the control of primarily publish-

ing companies. Notably, this deﬁnition excludes blog

posts and tweets as grey literature.

Adams et al. (Adams et al., 2016) initiated in 2017

a formal evaluation on incorporating grey literature

in organizational studies, structuring it into categories

reﬂecting their scientiﬁc reliability. The ﬁrst category

(tier 1) encompassed sources with stringent source

control, such as books, journals, and governmental

reports. The second category (tier 2) included ma-

terials with moderate reliability, like corporate annual

reports and media content. The third category (tier

3) was designated for sources with lower academic

credibility, such as blogs and social media posts. This

approach aimed to ensure the scientiﬁc integrity and

relevance of grey literature in scholarly research.

In the Software Engineering context, Garousi et

al. (Garousi et al., 2019) tailored the concept by

Adams et al. (Adams et al., 2016) to consider all non-

peer-reviewed materials as grey literature. This adap-

tation was crucial to encompass the vast array of rel-

evant but academically peripheral content in the ﬁeld.

Exploring the Pros and Cons of Monolithic Applications versus Microservices

257

The grey literature review, complementing the

snowballing method ﬁndings, is particularly rele-

vant in Software Engineering due to the industry’s

rich practice-oriented knowledge. This approach

aligns with Garousi et al.’s rationale (Garousi et al.,

2019), emphasizing the importance of studies that

reﬂect real-world professional experiences, a per-

spective supported by additional researchers (Kamei,

2020; Soldani, 2020) advocating for more industry-

representative studies in Software Engineering.

The grey literature review phase was initiated in

parallel with the snowballing approach. To iden-

tify pertinent documents, a series of search strings

were crafted and applied within Google’s search

functionality. The speciﬁc search terms employed

are described as follows: (“comparison” “advan-

tages” “disadvantages” “microservices” “monolith”

site:“intended domain address”).

The choice to include the terms advantages and

disadvantages was due to the fact that this search

could provide results showing the advantages and

disadvantages of using monolithic and microservices

architectures. Similarly, the inclusion of the terms

monolith and microservices was motivated by the

search for articles comparing one architecture with

the other. The domain ﬁlter was chosen because

of the need to reﬁne the search, due to the num-

ber of results obtained. The six sites selected were

chosen because they are recognized by the software

development community and are listed as follows:

Stack Overﬂow blog; Site Point; GFG; freeCode-

Camp; DZone; Medium.

The following inclusion criteria were used to se-

lect the papers from the grey literature: text content;

texts from the selected blogs, due to the fact that there

is a large amount of content shared by the community

on this type of platform; content that addresses the is-

sue of comparing microservice and monolith architec-

tures; texts in English or Portuguese. The items that

formed the criteria for excluding grey literature works

are as follows: audio or video content without text

transcription; texts not originating from blogs; dupli-

cate texts; texts that do not compare the proposed ar-

chitectures; texts in languages other than English or

Portuguese. The results obtained from the review of

the grey literature are shown in Section 3.2.

2.3 Survey

Although the previous stages of systematic literature

analysis through snowballing, combined with the sys-

tematic review of grey literature, can already add

value to this research (Runeson and Höst, 2009), we

https://www.google.com/

have decided to expand the data source by conducting

a survey with experts.

In this stage, the objective was to identify, using

an exploratory qualitative approach, the understand-

ing of the use of proposed software architectures from

interviews with industry practitioners. Qualitative re-

search denotes a type of research that produces re-

sults not resulting from statistical or other quantiﬁ-

able procedures, but that qualiﬁes the phenomenon

under investigation (Corbin and Strauss, 2008). Stud-

ies of this nature refer to research about people’s lives,

experiences, behaviors, emotions, and feelings, as

well as organizational functioning, social movements,

cultural phenomena, and interactions between people

(Corbin and Strauss, 2008). Thus, qualitative research

involves the interpretation of the subjects studied, ex-

amining things in their natural settings in an attempt

to interpret the phenomenon based on the accounts

provided by the research participants (Taylor, 2005).

For the ﬁeld study, the survey method was used,

which, based on the theme of this research, employed

a questionnaire that was administered to participants

during interview sessions. The questionnaire was de-

signed in a way that the questions would result in an-

swers that add value to this work and that they were

also engaging, so that people would be more inclined

to provide complete and accurate responses if they

could see that the study’s results would likely be use-

ful to the community. The basis for formulating the

questions proposed to the interviewees came from the

analysis of the results of the methodologies applied in

previous steps of this same research.

Additionally, in order to propose an instrument of

value for a representative sample, a pilot test was con-

ducted with the initial interviewees. This allowed for

the identiﬁcation of issues with the questionnaire as

well as the follow-up rate procedure. The pilot test

was also useful in contributing to the assessment of

reliability (Singer et al., 2008).

2.3.1 Interview Process

Semi-structured interviews were conducted following

the guidelines associated with Software Engineering

(Hove and Anda, 2005) with 7 participants who ac-

cepted the invitation. The interviews were conducted,

transcribed, and analyzed by the author of this study.

For the interviews, questions were formulated based

on the results of previous methodological steps. All

participants were asked the initial set of questions;

however, as is common in semi-structured interviews,

new questions emerged during the interviews based

on speciﬁc responses. This allowed the participants

to freely express their perceptions and opinions.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

258

3 RESULTS ANALYSIS

This study employed the snowballing methodology

for the systematic collection and analysis of academic

data, expanding the sample through citations and ref-

erences from initial studies to gain a broader un-

derstanding of the ﬁeld (Wohlin, 2014). It also in-

corporated an analysis of grey literature, including

non-commercial sources, for a more comprehensive

view (Garousi et al., 2019). Moreover, a survey with

software development professionals was conducted to

gather their perceptions and opinions, complement-

ing the theoretical evaluation with practical insights.

Together, these methods provided an in-depth under-

standing of the use of software architectures under

study.

3.1 Snowballing

For the systematic study using the snowballing tech-

nique, the initial selection of articles was extracted

from the Association of Computer Machinery (ACM)

- Digital Library and IEEE Xplore databases. To

achieve this initial selection, the previously cited

search string was employed, with ﬁlters being applied

according to predeﬁned inclusion criteria. As a result

of this process, a total of 41 articles was identiﬁed. Of

these, 28 were from ACM and the remaining 13 were

from the IEEE Xplore database. All abstracts of these

articles were carefully read and analyzed.

After analyzing the abstracts, 29 articles from the

initial list were excluded. The main reason for the

removal of these articles was that their themes were

not aligned with the main focus of this research. Ad-

ditionally, some articles were excluded based on the

previously established inclusion and exclusion crite-

ria. This resulted in a total of 12 articles that were

selected for the ﬁrst iteration of the snowballing re-

view process.

The execution of the initial snowballing search en-

abled the acquisition of 12 articles that were analyzed

to extract the advantages and disadvantages present

in monolithic and microservices architectures. This

identiﬁcation and categorization work was essential

to deepen the understanding of these two architectures

and provide a solid foundation for the main objective

of this research.

One of the main points of interest of this study is

to understand how the adoption of microservices ar-

chitecture can lead to a longer software development

time.

It is important to emphasize that this research does

not intend to offer a deﬁnitive or exhaustive view,

but rather to provide a starting point for a more in-

depth discussion on the topic. Each disadvantage pre-

sented below represents a characteristic that should

be carefully considered by development teams and

decision-makers when evaluating the adoption of mi-

croservices architecture in their projects.

After the initial selection of articles and analy-

sis of their contents, the iteration process began, in-

volving the use of backward and forward snowballing

techniques. This approach allowed for the inclusion

of 14 additional articles to the initial set, resulting in

a signiﬁcant increase in information sources for the

research (see Table 1).

Table 1: Final selection of articles by Snowballing.

ID Reference ID Reference

S1 (Kyryk et al., 2022) S14 (Di Francesco et al., 2018)

S2 (Gos and Zabierowski, 2020) S15 (Ponce et al., 2019)

S3 (Vidie

ccan and Bobák, 2022) S16 (Benavente et al., 2022)

S4 (Raharjo et al., 2022) S17 (Christian et al., 2023)

S5 (Gördesli and Varol, 2022) S18 (Blinowski et al., 2022)

S6 (Velepucha and Flores, 2023) S19 (Karabey Aksakalli et al., 2021)

S7 (Akbulut and Perros, 2019) S20 (Kumar et al., 2021)

S8 (Afanasev et al., 2017) S21 (Liu et al., 2020)

S9 (Bian et al., 2022) S22 (Jamshidi et al., 2018)

S10 (Wei et al., 2021) S23 (Kurpad et al., 2023)

S11 (Taibi et al., 2017) S24 (Butzin et al., 2016)

S12 (de Oliveira Rosa et al., 2020) S25 (Hassan and Bahsoon, 2016)

S13 (Salii et al., 2023) S26 (Balalaie et al., 2016)

The added articles underwent detailed analysis,

during which the main points related to the disadvan-

tages of using microservices were extracted. Notably,

already in the second iteration of the snowballing pro-

cess, no new disadvantages beyond those previously

listed were identiﬁed, suggesting a saturation of infor-

mation on the topics of interest.

Given that subsequent iterations did not produce

new information, it was decided to conclude the itera-

tions proposed by the snowballing. This decision was

based on the assessment that further iterations would

not bring signiﬁcant new data, and that the time and

resources invested would be better used in analyzing

the data already collected.

The 26 articles selected for the research were read

in full to ensure a complete understanding of their

content and the context in which they were written.

Regarding the disadvantages associated with the

use of microservices architectures, a complete list of

all identiﬁed disadvantages, as well as the frequency

of their occurrences in all analyzed articles, is avail-

able in Table 2. This table provides a comprehensive

view of the perceptions and experiences reported in

the literature on the use of these architectures.

In the analysis of the results obtained through

the snowballing process, several challenges associ-

ated with the implementation of microservices archi-

tecture that can impact software development time

Exploring the Pros and Cons of Monolithic Applications versus Microservices

259

Table 2: Disadvantages associated with the use of microser-

vices.

Disadvantages Quotes

Operational complexity 20

Initial cost of adoption 12

Data consistency challenges 11

Network overhead 9

Increasing complexity of DevOps 9

More complex monitoring 5

Communication challenges 4

Debugging difﬁculties 4

Versioning difﬁculties 4

Challenging security standards 4

were identiﬁed. Operational complexity is one of the

main issues, as the multiplicity of autonomous ser-

vices requires intensive management and coordina-

tion, increasing the workload.

Other notable challenges include the initial cost

of adoption, which involves acquiring speciﬁc techni-

cal skills and implementing new tools and processes.

Additionally, data consistency is a recurring obstacle,

as each service manages its own database, leading to

data fragmentation and making it difﬁcult to maintain

consistency. Network overhead is also a signiﬁcant

challenge, as constant communication between ser-

vices can result in latency and degraded performance.

Increased complexity in DevOps, communication

challenges between services, difﬁculties in debugging

and versioning, as well as challenging security stan-

dards are other obstacles that can prolong the software

development cycle. Despite the beneﬁts of microser-

vices architecture, such as scalability and ﬂexibility, it

is crucial for organizations to be aware of these chal-

lenges and be prepared to manage them effectively.

The decision to adopt this architecture should there-

fore be carefully weighed, considering both the po-

tential beneﬁts and inherent challenges.

3.2 Grey Literature

The results obtained from internet blog searches to-

taled 90 articles. Among these articles, 68 were ob-

tained from Medium blogs, 1 from Site Point, 6 from

Geeks For Geeks, 1 from freeCodeCamp, 13 from

DZone, and 1 from the Stack Overﬂow blog.

For the selection of articles according to the in-

clusion and exclusion criteria, the texts were read and

the disadvantages mentioned by them were classiﬁed.

As some of the blogs contained a large number of re-

sults, this classiﬁcation of the disadvantages of using

microservices architecture was useful for generating

a knowledge base on these, which showed that the in-

dustry has a comprehensive perception of the prob-

lems related to the use of this architecture. The ﬁnal

number of selected texts was 27 articles, according

to the proposed exclusion criteria. Among these arti-

cles, 20 were obtained from the Medium blog, 1 from

Site Point, 2 from Geeks For Geeks, 1 from freeCode-

Camp, 3 from DZone, and none from the Stack Over-

ﬂow blog, as seen in Table 3.

Table 3: Results from the grey literature review.

Site Results Selected

Medium 68 20

DZone 13 3

Geeks For Geeks 6 2

Site Point 1 1

freeCodeCamp 1 1

Stack Overﬂow blog 1 0

Similarly to what was found in academia with the

use of snowballing, the study of the selected texts by

analyzing the grey literature reveals a series of chal-

lenges associated with the implementation and use

of microservices architecture. These challenges, al-

though varying in degree and complexity, highlight

the inherent difﬁculties of this architecture and the is-

sues that need to be considered when adopting it.

First of all, complexity in implementation and

maintenance is cited in 25 of the analyzed texts. This

challenge is due to the fact that microservices archi-

tecture involves the creation and management of mul-

tiple independent services, each with its own lifecy-

cle. This can lead to signiﬁcant complexity both in

the implementation phase and in the maintenance of

these services.

Secondly, challenges in managing distributed state

are mentioned in 18 of the texts. This problem arises

because, in a microservices architecture, the applica-

tion state is generally distributed among various ser-

vices. This can make managing the application state

complex and prone to errors.

Furthermore, difﬁculties in deploy automation and

conﬁguration are mentioned in 13 of the texts. Au-

tomation is essential for efﬁciently managing the large

number of services in a microservices architecture.

However, automation can be difﬁcult due to the com-

plexity and diversity of the services.

Additional infrastructure costs, cited in 12 of the

texts, are also a concern. As each service in a mi-

croservices architecture is usually run in its own en-

vironment, this can lead to increased infrastructure

costs.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

260

Other issues identiﬁed in the texts include in-

creased network latency due to communication be-

tween services (11 texts), the need to deal with a vari-

ety of technologies (11 texts), difﬁculties in conduct-

ing comprehensive and effective testing (11 texts), se-

curity challenges arising from the complexity of the

microservices architecture (8 texts), the need for an

entry point system to facilitate communication and

control between services (3 texts), the lack of ade-

quate training for development teams (2 texts), and

challenges in managing and controlling code version-

ing (2 texts).

The distribution of these issues can be visualized

in Table 4. This provides a comprehensive view of the

challenges associated with microservices architecture

and can help guide future research and practices in

this ﬁeld.

Table 4: Problems found in the grey literature review with

the use of microservices architecture.

Listed Problems Quotes

High complexity in implementation and maintenance 25

Challenges in distributed state management 18

Difﬁculties in automating deploy 13

Additional infrastructure costs 12

Increased network latency due to communication 11

Need to deal with diversity of technologies 11

Difﬁculties in conducting comprehensive tests 11

Security challenges arising from complexity 8

Need for a point of entry system 3

Lack of adequate training for teams 2

Management and control of code versioning 2

3.3 Survey

In this study, semi-structured interviews were con-

ducted to collect qualitative data on developers’ per-

ceptions and experiences with microservices and

monolithic architectures. The seven respondents rep-

resent a variety of roles, experiences ranging from 3 to

16 years of experience (avg. +8 years), and industry

sectors (such as ERP development, travel and others),

providing a comprehensive insight into the subject.

The analysis reveals that both types of architec-

ture have their advantages and disadvantages. Mi-

croservices architectures, while more complex, offer

greater scalability and ease of maintenance, especially

in large and complex projects. However, they can re-

sult in longer development times, particularly in the

initial stages or in less complex projects. On the other

hand, monolithic architectures are easier to develop

and test due to their simplicity and centralization but

can become more challenging to manage in larger and

more complex projects.

The respondents agree that the choice of architec-

ture depends on several factors, including the com-

plexity and size of the project, as well as the skills and

experiences of the developers. Moreover, the organi-

zation and management of the project may be more

relevant to the success of the development than the

choice of architecture itself. Therefore, the choice of

architecture should be based on a careful assessment

of the project’s needs, organizational context, avail-

able resources, and team experience.

3.4 Threats to Validity

Any ﬁndings and insights from this study are lim-

ited by the nature of the sub-studies of which it is

composed. Each study has associated limitations, but

some of these are more generally applied.

First, this study could have been submitted to

the research bias, where the researcher expects a re-

sult and thus interprets ﬁndings from this perspective.

This study has put in practice techniques which re-

duce this bias, such as multi-author analysis and dis-

cussion of results.

Given that this study has made use of interviews,

recordings and transcriptions, there is the limitation

towards transcription of interviews and interpretation

of responses by the researcher. This is mitigated by

the scientiﬁc procedures adopted, but cannot be fully

eliminated.

It is important to remark that our study involved

interviews with only seven experts in the ﬁeld. While

this number may seem modest, the depth and breadth

of insights provided by these seasoned specialists sig-

niﬁcantly enrich our research. Their extensive expe-

rience and profound understanding of software archi-

tectures lend our ﬁndings a depth that might not be

achievable through larger, less specialized participant

pools. This approach underscores the quality over

quantity principle, ensuring our conclusions are both

informed and nuanced.

Furthermore, the rapidly evolving ﬁeld of soft-

ware architecture means our results might be context-

bound or lose relevance over time. Recognizing these

limitations is crucial for a balanced understanding of

the study’s scope and applicability.

4 CONCLUSION

The research conducted in this study provided a com-

prehensive analysis of microservices and monolithic

architectures, considering their advantages and dis-

advantages and how the choice between them can

impact software development time. The results ob-

Exploring the Pros and Cons of Monolithic Applications versus Microservices

261

tained through snowballing methodologies, grey lit-

erature, and surveys with industry professionals indi-

cate that while microservices architecture offers sig-

niﬁcant beneﬁts in terms of scalability, ﬂexibility, and

fault isolation, it also presents challenges that can lead

to an increase in development time.

The challenges associated with microservices ar-

chitecture, such as operational complexity, initial

adoption cost, data consistency challenges, network

overhead, and increased DevOps complexity, require

careful management and may demand signiﬁcant time

and resource investment. However, for large and com-

plex projects, microservices may be the better option,

offering advantages that outweigh the disadvantages.

This research contributed to the existing literature

by providing a detailed view of the implications of ar-

chitectural choice on software development time. The

ﬁndings reinforce the need for a thorough assessment

of the project’s needs and available resources before

deciding between microservices and monoliths.

4.1 Future Works

In relation to future works, it is recommended to con-

tinue the investigation into microservices and mono-

lithic architectures, with a particular focus on opti-

mizing development time and mitigating identiﬁed

challenges. Further research could explore strate-

gies and tools that facilitate the transition from mono-

liths to microservices, as well as practices that pro-

mote efﬁciency in the development and maintenance

of microservices-based architectures.

Another area of interest is the development of

frameworks that automate aspects of microservices

development, reducing operational complexity and

speeding up the development cycle. Moreover, de-

tailed case studies in different industry contexts could

provide practical data on how companies are address-

ing the challenges associated with each architecture

and which solutions are proving effective.

Finally, future research could focus on the educa-

tion and training of developers to work with microser-

vices, identifying essential skills and creating educa-

tional materials that better prepare professionals for

the challenges of this architectural paradigm.

ACKNOWLEDGEMENT

This study was partially supported by the Ministry

of Science, Technology, and Innovations from Brazil,

with resources from Law No. 8.248, dated October

23, 1991, within the scope of PPI-SOFTEX, coordi-

nated by Softex.

REFERENCES

Adams, R. D., Smart, P., and Huff, A. S. (2016). Shades of

grey: Guidelines for working with the grey literature

in systematic reviews for management and organiza-

tional studies. International Journal of Management

Reviews, 19:432–454.

Afanasev, M. Y., Fedosov, Y. V., Krylova, A. A., and

Shorokhov, S. A. (2017). An application of microser-

vices architecture pattern to create a modular com-

puter numerical control system. In 2017 20th Confer-

ence of Open Innovations Association, pages 10–19.

Akbulut, A. and Perros, H. G. (2019). Performance anal-

ysis of microservice design patterns. IEEE Internet

Computing, 23(6):19–27.

Balalaie, A., Heydarnoori, A., and Jamshidi, P. (2016). Mi-

croservices architecture enables devops: Migration to

a cloud-native architecture. IEEE Soft., 33(3):42–52.

Benavente, V., Yantas, L., Moscol, I., Rodriguez, C., In-

quilla, R., and Pomachagua, Y. (2022). Comparative

analysis of microservices and monolithic architecture.

In 2022 14th Int. Conf. on Computational Intelligence

and Communication Networks, pages 177–184.

Bernstein, D. (2014). Containers and cloud: From lxc

to docker to kubernetes. IEEE Cloud Computing,

1(3):81–84.

Bian, Y., Ma, D., Zou, Q., and Yue, W. (2022). A multi-way

access portal website construction scheme. In 2022

5th Int. Conf. on AI and Big Data, pages 589–592.

Blinowski, G., Ojdowska, A., and Przybyłek, A. (2022).

Monolithic vs. microservice architecture: A perfor-

mance and scalability evaluation. IEEE Access,

10:20357–20374.

Butzin, B., Golatowski, F., and Timmermann, D. (2016).

Microservices approach for the internet of things. In

2016 IEEE 21st Int. Conf. on Emerging Technologies

and Factory Automation, pages 1–6.

Christian, J., Steven, Kurniawan, A., and Anggreainy, M. S.

(2023). Analyzing microservices and monolithic sys-

tems: Key factors in architecture, development, and

operations. In 2023 6th Int. Conf. of Computer and

Informatics Engineering, pages 64–69.

Corbin, J. and Strauss, A. (2008). Qualitative research.

Techniques and procedures for developing grounded

theory, 3.

de Oliveira Rosa, T., Daniel, J. a. F. L., Guerra, E. M., and

Goldman, A. (2020). A method for architectural trade-

off analysis based on patterns: Evaluating microser-

vices structural attributes. In Proceedings of the Eu-

roPLoP 2020, pages 35:1–8. ACM.

Di Francesco, P., Lago, P., and Malavolta, I. (2018). Migrat-

ing towards microservice architectures: An industrial

survey. In 2018 IEEE Int. Conf. on Software Architec-

ture (ICSA), pages 29–2909.

Garousi, V., Felderer, M., and Mäntylä, M. V. (2019).

Guidelines for including grey literature and conduct-

ing multivocal literature reviews in software engineer-

ing. Info. and Software Technology, 106:101–121.

Gos, K. and Zabierowski, W. (2020). The comparison of

microservice and monolithic architecture. In 2020

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

262

IEEE XVIth International Conference on the Per-

spective Technologies and Methods in MEMS Design

(MEMSTECH), pages 150–153.

Gördesli, M. and Varol, A. (2022). Comparing interservice

communications of microservices for e-commerce in-

dustry. In 2022 10th International Symposium on Dig-

ital Forensics and Security (ISDFS), pages 1–4.

Hassan, S. and Bahsoon, R. (2016). Microservices and their

design trade-offs: A self-adaptive roadmap. In 2016

IEEE International Conference on Services Comput-

ing (SCC), pages 813–818.

Hove, S. and Anda, B. (2005). Experiences from conduct-

ing semi-structured interviews in empirical software

engineering research. In 11th IEEE METRICS), pages

10 pp.–23.

Jamshidi, P., Pahl, C., Mendonça, N. C., Lewis, J., and

Tilkov, S. (2018). Microservices: The journey so far

and challenges ahead. IEEE Software, 35(3):24–35.

Kamei, F. K. (2020). The use of grey literature review as ev-

idence for practitioners. SIGSOFT Softw. Eng. Notes,

44(3):23.

Karabey Aksakalli, I., Celik, T., Can, A. B., and Tekinerdo-

gan, B. (2021). Deployment and communication pat-

terns in microservice architectures: A systematic lit-

erature review. Journal of Sys. and Soft., 180:111014.

Kholy, M. E. and Fatatry, A. E. (2019). Framework for

interaction between databases and microservice archi-

tecture. IT Professional, 21(5):57–63.

Kumar, P. K., Agarwal, R., Shivaprasad, R., Sitaram, D.,

and Kalambur, S. (2021). Performance characteriza-

tion of communication protocols in microservice ap-

plications. In 2021 SmartNets, pages 1–5.

Kurpad, S., BT, S., Vijaykumar, S., Jain, S., and Kalambur,

S. (2023). Microarchitectural analysis and character-

ization of performance overheads in service meshes

with kubernetes. In 2023 3rd Asian Conference on

Innovation in Technology (ASIANCON), pages 1–6.

Kyryk, M., Tymchenko, O., Pleskanka, N., and Pleskanka,

M. (2022). Methods and process of service migra-

tion from monolithic architecture to microservices. In

2022 IEEE 16th Int. Conf. on Advanced Trends in

Radioelectronics, Telecommunications and Computer

Engineering (TCSET), pages 553–558.

Liu, G., Huang, B., Liang, Z., Qin, M., Zhou, H., and Li,

Z. (2020). Microservices: architecture, container, and

challenges. In 2020 IEEE 20th Int. Conf. on Software

Quality, Reliability and Security Companion (QRS-

C), pages 629–635.

Merson, P. and Yoder, J. (2020). Modeling microservices

with ddd. In 2020 IEEE Int. Conf. on Software Archi-

tecture Companion (ICSA-C), pages 7–8.

Ponce, F., Márquez, G., and Astudillo, H. (2019). Migrat-

ing from monolithic architecture to microservices: A

rapid review. In 2019 38th Int. Conf. of the Chilean

Computer Science Society (SCCC), pages 1–7.

Raharjo, A. B., Andyartha, P. K., Wijaya, W. H., Pur-

wananto, Y., Purwitasari, D., and Juniarta, N. (2022).

Reliability evaluation of microservices and monolithic

architectures. In Int. Conf. on Computer Engineering,

Network, and Intelligent Multimedia, pages 1–7.

Richardson, C. (2016). Pattern: Monolithic ar-

chitecture (2014). URL http://microservices.

io/patterns/monolithic. html.

Runeson, P. and Höst, M. (2009). Guidelines for conduct-

ing and reporting case study research in software en-

gineering. Empirical Soft. Eng., 14:131–164.

Salii, S., Ajdari, J., and Zenuni, X. (2023). Migrating to a

microservice architecture: beneﬁts and challenges. In

2023 46th MIPRO, pages 1670–1677.

Singer, J., Sim, S. E., and Lethbridge, T. C. (2008). Software

Engineering Data Collection for Field Studies, pages

9–34. Springer London, London.

Soldani, J. (2020). Grey literature: A safe bridge between

academy and industry? SIGSOFT Softw. Eng. Notes,

44(3):11–12.

Soldani, J., Tamburri, D. A., and Van Den Heuvel, W.-J.

(2018). The pains and gains of microservices: A sys-

tematic grey literature review. Journal of Systems and

Software, 146:215–232.

Stubbs, J., Moreira, W., and Dooley, R. (2015). Distributed

systems of microservices using docker and serfnode.

In 2015 7th International Workshop on Science Gate-

ways, pages 34–39.

Taibi, D., Lenarduzzi, V., Pahl, C., and Janes, A. (2017).

Microservices in agile software development: A

workshop-based study into issues, advantages, and

disadvantages. In Proceedings of the XP2017 Scien-

tiﬁc Workshops, XP ’17, New York, NY, USA. Asso-

ciation for Computing Machinery.

Taylor, G. R. (2005). Integrating quantitative and qualita-

tive methods in research. University press of America.

Velepucha, V. and Flores, P. (2023). A survey on microser-

vices architecture: Principles, patterns and migration

challenges. IEEE Access, 11:88339–88358.

Vidie

ccan, M. and Bobák, M. (2022). Container-based

video streaming service. In 2022 IEEE 22nd Inter-

national Symposium on Computational Intelligence

and Informatics and 8th IEEE International Confer-

ence on Recent Achievements in Mechatronics, Au-

tomation, Computer Science and Robotics (CINTI-

MACRo), pages 000191–000196.

Viennot, N., Lécuyer, M., Bell, J., Geambasu, R., and Nieh,

J. (2015). Synapse: A microservices architecture

for heterogeneous-database web applications. In Pro-

ceedings of the Tenth European Conference on Com-

puter Systems, EuroSys ’15, pages 21:1–16. ACM.

Wei, Y., Yu, Y., Pan, M., and Zhang, T. (2021). A feature ta-

ble approach to decomposing monolithic applications

into microservices. In Proc. of the 12th Asia-Paciﬁc

Symposium on Internetware, Internetware ’20, page

21–30, Singapore, Singapore.

Wohlin, C. (2014). Guidelines for snowballing in system-

atic literature studies and a replication in software en-

gineering. In EASE, pages 38:1–10, London, UK.

Yarygina, T. and Bagge, A. H. (2018). Overcoming secu-

rity challenges in microservice architectures. In 2018

IEEE SOSE, pages 11–20.

Exploring the Pros and Cons of Monolithic Applications versus Microservices

263