=Paper=
{{Paper
|id=Vol-2767/paper08
|storemode=property
|title=Evaluating the Impact of Inter Process Communication in Microservice Architectures
|pdfUrl=https://ceur-ws.org/Vol-2767/07-QuASoQ-2020.pdf
|volume=Vol-2767
|authors=Benyamin Shafabakhsh,Robert Lagerström,Simon Hacks
|dblpUrl=https://dblp.org/rec/conf/apsec/ShafabakhshLH20
}}
==Evaluating the Impact of Inter Process Communication in Microservice Architectures==
https://ceur-ws.org/Vol-2767/07-QuASoQ-2020.pdf
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
Evaluating the Impact of Inter Process Communication
in Microservice Architectures
Benyamin Shafabakhsha , Robert Lagerströmb and Simon Hacksb
a School of Electrical Engineering and Computer Science,
KTH Royal Institute of Technology,
Stockholm, Sweden
b Division of Network and Systems Engineering,
KTH Royal Institute of Technology,
Stockholm, Sweden
Abstract
With the substantial growth of cloud computing over the past decade, microservice architectures have gained significant
popularity and have become a prevalent choice for designing cloud-based applications. Microservices based applications are
distributed and each service can run on a different machine. Due to its distributed nature, one of the key challenges when
designing applications is the mechanism by which services communicate with each other. There are several approaches
for implementing inter process communication (IPC) in microservices; each comes with different advantages and trade-offs.
While theoretical and informal comparisons exist between them, this paper has taken an experimental approach to compare
and contrast the popular forms of IPC communications. Several load test scenarios have been executed to obtain quantitative
data related to performance efficiency, and availability of each method. The evaluation of the experiment indicates that,
although there is no universal IPC solution that can be applied in all cases, the asynchronous pattern offers various advantages
over its synchronous rival.
Keywords
Microservices, Inter Process Communication, IPC, Inter-Service Communication, Distributed Systems, gRPC, RabbitMQ
1. Introduction croservice systems [7]. IPC is one of the important
challenges of microservice architectures [8]. In mono-
Over the past few years, microservices have earned lithic based systems, components can call each other
enormous attention and gained popularity from the in- at the language-level while in microservices each com-
dustry. They helped large organisation such as Ama- ponent is running on its own process and possibly on
zon and Netflix to serve millions of requests per min- a different machine than other services. The choice
utes [1]. Microservice architecture is a style of devel- of IPC mechanism is an important architectural deci-
oping software as a collection of independent services. sion which can impact the software’s non-functional
Each service is running on its own process that is in- requirements [8].
dependent from other processes and can be deployed As of today, there are no concrete explanations or
separately from other services [2]. Designing a soft- any standardized approach that can help to decide the
ware based on microservices involves answering ques- right IPC method when designing microservice based
tions and overcoming technical challenges that often applications. Due to this reason, there is an abun-
do not exist in monolithic architecture, like inter pro- dant confusion around the question of when to use
cess communication (IPC) [3], service discovery [4], which method and what are the trade-offs for choos-
decomposition strategy [5], or managing ACID trans- ing that method. Deciding between a synchronous and
actions [6]. asynchronous approach is an important decision to
Despite the growth and importance of microser- take in regards to how services collaborate with each
vices in industry, there has not been sufficient research other [9].
on microservices, partly due to lacking a benchmark There are two questions this paper is working to-
system that reflects the characteristics of industrial mi- wards answering:
Woodstock’20: Symposium on the irreproducible science, June 01–05, 1. From performance efficiency standpoint, what
2020, Woodstock, NY are the implications for utilizing available
email: bensha@kth.se (B. Shafabakhsh); robertl@kth.se (R.
Lagerström); shacks@kth.se (S. Hacks) synchronous and asynchronous methods for im-
orcid: 0000-0003-3089-3885 (R. Lagerström); 0000-0003-0478-9347 plementing IPC in microservice architectures?
(S. Hacks) 2. How does the IPC method choice impact avail-
© 2020 Copyright for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0). ability of the system?
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
55
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
The motive behind selecting the performance effi- each service exposes a set of endpoints to enable
ciency, and availability as the two criteria for this re- the interactions with other microservices and
search is that the choice of IPC method directly im- exchange of information between them. The
pacts these two non-functional requirements in a mi- server interacts directly with client through its
croservices based system, while other non-functional interface also known as Web API.
requirements such as security [10] and maintainabil-
ity [11] can span over few other areas and goes beyond • gRPC: gRPC is an open source high perfor-
IPC. Being able to measure these qualities in the sys- mance RPC framework designed an developed
tem are critical in order to achieve an efficient manage- by Google. Remote procedure call (RPC) is a
ment of any software system [12, 13]. Moreover, the mechanism used in many distributed applica-
chosen quality attributes are among the top priorities tions to facilitate inter process communication.
for most modern applications [14, 15]. RPC was first implemented by Birrell and Nel-
In this work, we describe a systematic approach for son [18] and it has been regarded as a proto-
selecting IPC method when designing microservices col that enables a message exchange between
based software. The remainder of this paper focuses two process with characteristics of low over-
on state of the art in identifying different IPC models head, simplicity and transparency [19]. By de-
in section 2. Next, in section 3, we discuss the develop- fault, when a client sends a request to a server
ment of the prototypes built for the purpose of discov- it halt the process and waits for the results to be
ering the relationship between each IPC method and returned. RPC is therefore considered as synch-
its impact on performance efficiency and availability. ronous form of communication [20]. Figure 1
We then run a test against each prototype to investi- presents the operational process between client
gate its outcome and discuss previous work conducted and server in gRPC. In this model, the client im-
in this domain. Finally, we draw a conclusion in sec- plements the same method as its correspond-
tion 6. ing server through local objects also known as
stubs.
2. State of the Art 2.2. Asynchronous Communication
When designing IPC mechanism, there are two type The asynchronous form of communication can be im-
of interaction style to choose from: synchronous and plemented in microservices when services exchange
asynchronous, which we will shortly introduce next. messages with each other through a message broker.
In this form of interaction, the message broker acts as
2.1. Synchronous Communication an intermediary between services to coordinate the
request and responses [8]. One of the fundamental
Synchronous communication is often regarded as re- differences in asynchronous communication as com-
quest/response interaction style. One microservice pared to the synchronous mode is that in asynchro-
makes a request to another service and waits for the nous communication the client no longer makes a di-
services to process the result and send a response back. rect call to the server and expect an immediate answer.
In this style, it is common that the requester blocks its Instead, other services subscribe to the same broker to
operation while waiting for a response from the re- pick-up the available requests and process them fur-
mote server. Representational state transfer (REST) ther before placing them back to the message queue.
application programming interfaces (API) [16] and Figure 2 provides an example of the asynchronous
gRPC1 are the most common framework for imple- pattern. In this sample, when a new order is created,
menting Synchronous form of communication in mi- the customer service publishes a request to the bro-
croservices [8]. ker with some metadata such as customer id, customer
email address, etc. Other services such as loyalty, post,
• REST API: REST is an architectural style that is
and email service subscribe to that broker and take the
commonly used for designing APIs for modern
request from there without having to communicate
web services [17]. In a system that uses REST
with Customer service directly.
API for its IPC communication, each service
typically has its own web-server up and run-
ning on a specific port such as 8080 or 443, and
1 https://grpc.io
56
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
Figure 1: gRPC architecture [21].
associated with the requested product from its
database.
• Product Recommendation Service: This mi-
croservice is responsible for fetching the prod-
uct recommendations based on the requested
productId from its database.
• Product Shipping Service: This microservice
Figure 2: High-level architecture of Asynchronous pattern is responsible for fetching available shipment
[9].
options and the delivery estimates based on the
given product from its database.
3. Implementation • Customer Shopping Cart Service: This mi-
croservices is responsible for fetching the exist-
To identify the quality attributes of each IPC method, ing items in the customer’s shopping cart in or-
we have designed and developed a set of microservices der to display them to the customer.
for an e-commerce scenario. In this scenario, the goal
is to simulate fetching all the information required All the microservices have been developed using
to display a product page of an e-commerce website. NodeJS2 . A non-relational database system, Mon-
A client requests a product page to be displayed on goDB3 , has been used as the database solution for all
his/her device and behind the scenes the following mi- the microservices except for the service responsible for
croservices work together to serve that request: providing shipment information. Due to the nature
of data required by shipping service, the shipping ser-
• Product Information Service: This microser- vice uses MYSQL4 . Docker5 has been utilized to con-
vice is responsible for fetching the primary tainerize all the microservices. In order to run the test
metadata associated with the requested prod- system, the services have been deployed to Microsoft
uct. Information such as product name, price, Azure Kubernetes Cluster Service6 . Table 1 shows the
description, color, and image are stored in this 2 https://nodejs.org/en/
microservice database. 3 https://www.mongodb.com/
4 https://www.mysql.com/
• Product Review Service: This microservice is 5 https://www.docker.com/
responsible for fetching the customer reviews 6 https://azure.microsoft.com/sv-se/services/kubernetes-
service/
57
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
Table 1 to understand how each IPC method reacts differently
Kubernetes Cluster specification of the test system. when the concurrent requests and traffic to the system
Instance Type Azure DS2-v2 increase or decrease.
vCPU 2 Throughput is calculated by the total number of re-
Memory 7 GiB quests and responses the method managed to make
Storage 8 GiB, SSD, 6400 IOPS within the specified duration of 180 seconds; the
Kubernetes Version 1.14.8 higher the number, the higher the throughput and the
Node Count 3 better it is.
The results are presented in figure 3. The data in-
dicates that gRPC has outperformed REST API, and
hardware specification of the testing system used for RabbitMQ in the first case with 50 users by being
this research. able to process 43 requests higher than REST API, and
In the synchronous mode both REST API, and gRPC 147 requests more than RabbitMQ; this signifies that
have an identical architecture; in both methods, there synchronous form of communication can offer higher
is a direct communication between API Gateway7 and throughput than the asynchronous method in the sit-
each microservice. Each microservice acts as server, uation when the load to the system is relatively low.
and the API Gateway acts as a client of those server. Meanwhile, the result of the first case also reveals
The key difference between REST API and gRPC is the that synchronous form of communication can process
underlying communication protocol as well as the for- requests slightly faster than asynchronous form and,
mat of the messages they exchange. gRPC has adopted therefore, has lower latency when the number of con-
protocol buffer8 as its proprietary message format, current threads10 in the system is low.
while the REST API uses JSON [22] format to exchange The second case has double the number of virtual
data. users as compared to the first one. Increasing the num-
The asynchronous architecture uses RabbitMQ as ber of virtual users causes the number of concurrent
message broker. In this pattern, the communication threads in the system to grow and results in longer
between API gateway and other services does not take processing time. The same data imply that gRPC has
place directly, rather it goes through a mediator also the highest throughput by processing a higher num-
known as message queue. In both synchronous and ber of requests compared to RabbitMQ and REST API;
asynchronous methods, the API Gateway is the entry however, the gap between gRPC and RabbitMQ is now
point to the system, which receives a request with spe- more narrowed than in the first case. In this test, gRPC
cific product id from client’s device such mobile app or managed to score the best average response time than
web browser over HTTPS protocol. The gateway then REST API and RabbitMQ by 200 milliseconds. The
communicates back and forth with each microservice processing time between REST API and RabbitMQ are
depending on the IPC method the system uses. equal to each other; however, RabbitMQ managed to
process extra 25 requests than its synchronous rival.
The number of virtual users in the third case has
4. Results and Evaluation increased four times as compared to the first case.
The outcome of the third testing experiment im-
4.1. Performance Efficiency plies considerable difference between synchronous
Three test cases have been designed and executed us- versus asynchronous form of communication both in
ing Apache JMeter9 . All test cases aim to measure throughput and latency when the number of paral-
the throughput of each IPC method. Throughput is lel requests increases. In this test, asynchronous form
an essential attribute for calculating performance effi- of communication using RabbitMQ has outperformed
ciency. In all three test experiments, the test duration the other two methods by being able to process a
was 180 seconds, while the number of concurrent vir- total of 4480 requests within the given period while
tual users that continuously send requests to the sys- gRPC managed to process 132 requests lower than
tem and wait for response has been varied. The motive RabbitMQ, and REST API processed 146 less requests
behind having test duration as a constant variable and than its asynchronous rival. What makes the asynch-
number of virtual users as the controlled variable is ronous pattern to operate better in the third test case
is that, in asynchronous form the performance decline
7 https://microservices.io/patterns/apigateway.html take place more gradually while in the synchronous
8 https://developers.google.com/protocol-buffers
9 https://jmeter.apache.org/ 10 Each virtual user occupies one thread in the system.
58
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
Figure 3: Throughput comparison.
pattern the performance begins to drop radically as and the number of requests/responses were not been
soon as the load to the system intensifies. tracked since they do not contribute to determining
the availability of the method. The first case ran with
4.2. Availability 200 virtual users, the second with 300 virtual users,
and third with 400 virtual users. Without having a
There are variety of parameters that can affect avail- high number of parallel users measuring availability
ability of a system –even hardware components can becomes more challenging as the system remains op-
play a role in determining the availability rate of a sys- erational for a significantly longer duration.
tem. For this measurement, all the parameters out- Figure 4 provides a summary of the conducted tests.
side IPC has been ignored. The availability of each During the first test, it took about seven minutes for
IPC method has been calculated by using the following the services to become unavailable using RabbitMQ,
equation [23]: while gRPC went down after about five minutes, and
the REST API took approximately four and a half
𝑀𝑇 𝑇 𝐹
𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = , minutes. These numbers were then dropped in each
𝑀𝑇 𝑇 𝐹 + 𝑀𝑇 𝑇 𝑅 method in the subsequent tests as the number of par-
with MTTF standing for "Mean Time to Failure," and allel requests were doubled. After the services became
MTTR for "Mean Time to Recovery." MTTF represents unavailable, the Kubernetes cluster has been manu-
the duration that the system is expected to last in op- ally restarted. From that moment, both gRPC and
eration before failure occurs. In contrast, MTTR rep- REST API took about 20 seconds only to become avail-
resents the duration the system requires to return to able again, while RabbitMQ took ten extra seconds.
operation after a failure has occurred. The higher the The main reason behind RabbitMQ taking longer than
MTTR, the longer it takes for the system to recover synchronous form to return back to operation is the
from a failure, which consequently reduces the avail- fact that it has an extra component known as a mes-
ability of the system. sage broker that requires to be refreshed and establish
Based on this formula, three other tests were exe- a new connection with each service. From this exper-
cuted using Apache Jmeter against all the three differ- iment, it is possible to infer that an asynchronous ap-
ent IPC methods to discover which one offers higher proach offers higher availability than its synchronous
availability. Unlike the previous test cases that had a opponents.
fixed duration, these test cases had no specific dura- Consequently, if microservices use a synchronous
tion. They ran as long as the services became unavail- based communication both client and server must be
able due to the high number of requests coming to the responsive at all time, otherwise the request will fail
system. Further, in this test, the average response time, after a specific duration depending on the configura-
59
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
Figure 4: Availability comparison.
tion. In contrast, a temporary outage of the server in threats to validity. First, we performed our experi-
an asynchronous setting causes minimal to no impact ments just with single technologies as representatives
to the consumer, since the consumer is loosely coupled for certain principles (synchronous vs. asynchro-
with the server. The requests can stay in the message nous). Therefore, our results can just indicate certain
queue and be processed at the later timing when the advantages of these principles. Second, we simulated
server is back to operation. The asynchronous pattern no complete system but just a small part of a bigger
offers capabilities that can help the system to improve system, e.g., there is no communication between the
its availability and resiliency from outage. It allows microservices during our requests. However, this
continuous operation even if there is a failure in one ofensures that we are not testing other effects, but
the system’s components without compromising the only the interaction between the gateway and the
availability of the entire system. microservices. Third, we were using technologies that
are highly configurable, thus a completly different
4.3. Discussion and Threats to Validity configuration could lead to other results. However, as
we just changed configurations where necessary, we
In addition to the two non-functional requirements assume that others can reproduce our results, espe-
that have been evaluated throughout this work, it is cially as they are in accordance with our theoretical
important to take into account the functional require- expectations.
ments for which microservices are being developed
for. It is essential to distinguish whether the scenario
requires an immediate response back from services or 5. Related Work
not. To elaborate further on this, in the proof of con-
cept scenario that was built during this work, display- Sufficient work has been done to benchmark the per-
ing a product page for an e-commerce was simulated. formance of microservices, and compare and contrast
In this scenario, the client sends a request to load the it with other architectures such as service oriented ar-
product page and expects an immediate result back. chitecture (SOA) [24], or with the monolithic architec-
The result of the request can either be the product page ture [25, 26, 27, 28, 29].
or an error that indicating the request was failed. The Ueda et al. [30] conducted research at IBM that
key point in this scenario is that the client expects an aimed to design an infrastructure that is optimized for
immediate result. In such scenarios the synchronous running microservice architectures. The team built
form of communication can be more suitable as these two versions of the sample application. One based on
scenarios cannot take advantage of the features that monolithic and the other based on microservices. The
an asynchronous form can offer. team discovered a significant performance overhead
Furthermore, our research incorporates some and higher hardware resource consumption in the mi-
60
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
croservices version of the application as compared to Further, the authors argue that microservice archi-
monolithic one. The paper has marked poor design tectures lead to a higher availability as the new system
of process communication in microservice architec- is broken down into several components and decou-
tures as one of the significant performance degrada- pled from each other, which makes it possible to load-
tions, and, therefore, unleashed the potential for fur- balance individual services as needed. This was par-
ther research and improvements in this topic. The pa- ticularly not possible in the legacy monolithic based
per has also pointed out that network virtualization system. At the same time, the new architecture of-
techniques, which are often used in a microservice ar- fers higher reliability and can better cope with fail-
chitectures, is another non-negligible reason behind ures. This is due to the fact that in the new system the
the performance gap of monolithic versus microser- communication relies on a message-broker that can be
vice architecture. The paper, however, has not pre- configured to ensure all messages get delivered even-
scribed any specific solution or suggestion as to how tually.
to overcome these challenges but rather pointed out
the potential future work for it.
Fernandes et al. [31] compared REST API per- 6. Conclusion
formance versus advanced message queuing proto-
When developing a microservices based system, the
col (AMQP) [32], which is one of the protocols used
choice of IPC method is an important decision to
in message-based communication that falls under
make. In this paper, we compared synchronous and
asynchronous category. The study has been done by
asynchronous IPC methods with regards to perfor-
measuring the averaged exchanged messages for a pe-
mance efficiency and availability. The outcome of
riod of time using the REST API and AMQP. The au-
our evaluation indicates that on average asynchro-
thors performed the experiments by setting up two in-
nous approach provides better performance efficiency
dependent software instances that constantly received
and higher availability. We also discussed a scenario
messages for a 30 minutes period with an average 226
where synchronous methods are more suitable to be
request per second. Each instance processed the re-
utilized. Therefore, both synchronous and asynchro-
ceived input message and stored them into a persis-
nous type of communication has to be adopted accord-
tent database. After executing the experiments, the
ing to the functional and non-functional requirements
authors concluded that for scenarios where there is a
of the specific components.
need to receive and process-intensive amount of data,
AMQP performs far better than REST API as it has
a better mechanism for data loss prevention, better References
message organization, and utilize lower hardware re-
sources. [1] J. Thönes, Microservices, IEEE software 32 (2015)
In contrast to Fernandes et al., check we in our work 116–116.
the behavior of the systems with different loads. We [2] D. Namiot, M. Sneps-Sneppe, On micro-services
recognize that synchronous approaches perform good architecture, International Journal of Open In-
with low loads while asynchronous approaches scale formation Technologies 2 (2014) 24–27.
better at higher loads. [3] L. L. Peterson, N. C. Buchholz, R. D. Schlicht-
Meanwhile, Dragoni et al. [28] have conducted a ing, Preserving and using context information
migration for a real-world mission-critical case study in interprocess communication, ACM Trans.
in the banking industry by transforming a monolithic Comput. Syst. 7 (1989) 217–246. doi:10.1145/
software into a microservice architecture. They ob- 65000.65001.
served how availability and reliability of the system [4] S. Haselböck, R. Weinreich, G. Buchgeher, Deci-
changed as a result of the new architecture. The so- sion guidance models for microservices: service
lution consists of decomposing several large compo- discovery and fault tolerance, in: Proceedings of
nents to which some of them requires to communicate the Fifth European Conference on the Engineer-
with third-party services. The services in the new ar- ing of Computer-Based Systems, 2017, pp. 1–10.
chitecture use message-based asynchronous commu- [5] J. Fritzsch, J. Bogner, A. Zimmermann, S. Wag-
nication as its IPC model to exchange data with each ner, From monolith to microservices: A clas-
other. The authors believe that aiming to have a simple sification of refactoring approaches, in: J.-M.
and decouple integration between services and follow- Bruel, M. Mazzara, B. Meyer (Eds.), Software En-
ing principle to handler failure will eventually lead to gineering Aspects of Continuous Development
higher reliability in microservice architecture.
61
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
and New Paradigms of Software Production and Systems (TOCS) 2 (1984) 39–59.
Deployment, Springer International Publishing, [19] J.-K. Lee, A group management system anal-
Cham, 2019, pp. 128–141. ysis of grpc protocol for distributed network
[6] C. K. Rudrabhatla, Comparison of event choreog- management systems, in: SMC’98 Conference
raphy and orchestration techniques in microser- Proceedings. 1998 IEEE International Conference
vice architecture, Int J Adv Comput Sci Appl 9 on Systems, Man, and Cybernetics (Cat. No.
(2018) 18–22. 98CH36218), volume 3, IEEE, 1998, pp. 2507–
[7] X. Zhou, X. Peng, T. Xie, J. Sun, C. Xu, C. Ji, 2512.
W. Zhao, Poster: Benchmarking microservice [20] R. A. Olsson, A. W. Keen, Remote Procedure
systems for software engineering research, in: Call, Springer US, Boston, MA, 2004, pp. 91–105.
2018 IEEE/ACM 40th International Conference doi:10.1007/1-4020-8086-7_8.
on Software Engineering: Companion (ICSE- [21] S. G. Du, J. W. Lee, K. Kim, Proposal of grpc as
Companion), IEEE, 2018, pp. 323–324. a new northbound api for application layer com-
[8] C. Richardson, Microservices patterns: with ex- munication efficiency in sdn, in: Proceedings of
amples in Java, Manning Publications, 2019. the 12th International Conference on Ubiquitous
[9] S. Newman, Building microservices : designing Information Management and Communication,
fine-grained systems, first edition.. ed., 2015. 2018, pp. 1–6.
[10] P. Johnson, D. Gorton, R. Lagerström, M. Ekst- [22] C. Severance, Discovering javascript object no-
edt, Time between vulnerability disclosures: A tation, Computer 45 (2012) 6–8.
measure of software product vulnerability, Com- [23] P. Johnson, R. Lagerström, M. Ekstedt, M. Öster-
puters & Security 62 (2016) 278–295. lind, It management with enterprise architecture,
[11] R. Lagerström, P. Johnson, M. Ekstedt, Architec- KTH, Stockholm (2014).
ture analysis of enterprise systems modifiability: [24] T. Erl, Service-oriented architecture: concepts,
a metamodel for software change cost estima- technology, and design, Pearson Education India,
tion, Software quality journal 18 (2010) 437–468. 1900.
[12] P. Närman, P. Johnson, R. Lagerström, U. Franke, [25] T. Cerny, M. J. Donahoo, J. Pechanec, Dis-
M. Ekstedt, Data collection prioritization for sys- ambiguation and comparison of soa, microser-
tem quality analysis, Electronic Notes in Theo- vices and self-contained systems, in: Proceed-
retical Computer Science 233 (2009) 29–42. ings of the International Conference on Research
[13] M. Ekstedt, U. Franke, P. Johnson, R. Lagerström, in Adaptive and Convergent Systems, RACS
T. Sommestad, J. Ullberg, M. Buschle, A tool ’17, Association for Computing Machinery, New
for enterprise architecture analysis of maintain- York, NY, USA, 2017, p. 228–235. doi:10.1145/
ability, in: 2009 13th European Conference on 3129676.3129682.
Software Maintenance and Reengineering, IEEE, [26] D. Taibi, V. Lenarduzzi, C. Pahl, Processes, mo-
2009, pp. 327–328. tivations, and issues for migrating to microser-
[14] U. Franke, M. Ekstedt, R. Lagerström, J. Saat, vices architectures: An empirical investigation,
R. Winter, Trends in enterprise architecture IEEE Cloud Computing 4 (2017) 22–32.
practice–a survey, in: International Workshop [27] R. Chen, S. Li, Z. Li, From monolith to microser-
on Trends in Enterprise Architecture Research, vices: A dataflow-driven approach, in: 2017
Springer, 2010, pp. 16–29. 24th Asia-Pacific Software Engineering Confer-
[15] P. Johnson, R. Lagerström, P. Närman, M. Simon- ence (APSEC), 2017, pp. 466–475.
sson, Extended influence diagrams for system [28] N. Dragoni, S. Dustdar, S. T. Larsen, M. Mazzara,
quality analysis, Journal of Software 2 (2007) 30– Microservices: Migration of a mission critical
42. system, arXiv preprint arXiv:1704.04173 (2017).
[16] R. T. Fielding, R. N. Taylor, Architectural styles [29] Z. Kozhirbayev, R. O. Sinnott, A performance
and the design of network-based software ar- comparison of container-based technologies for
chitectures, volume 7, University of California, the cloud, Future Generation Computer Systems
Irvine Irvine, 2000. 68 (2017) 175 – 182. doi:10.1016/j.future.
[17] M. Masse, REST API Design Rulebook: Design- 2016.08.025.
ing Consistent RESTful Web Service Interfaces, " [30] T. Ueda, T. Nakaike, M. Ohara, Workload char-
O’Reilly Media, Inc.", 2011. acterization for microservices, in: 2016 IEEE in-
[18] A. D. Birrell, B. J. Nelson, Implementing remote ternational symposium on workload characteri-
procedure calls, ACM Transactions on Computer zation (IISWC), IEEE, 2016, pp. 1–10.
62
8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)
[31] J. L. Fernandes, I. C. Lopes, J. J. Rodrigues, S. Ul-
lah, Performance evaluation of restful web ser-
vices and amqp protocol, in: 2013 Fifth Interna-
tional Conference on Ubiquitous and Future Net-
works (ICUFN), IEEE, 2013, pp. 810–815.
[32] S. Vinoski, Advanced message queuing protocol,
IEEE Internet Computing 10 (2006) 87–89.
63