Evaluating the Impact of Inter Process Communicationin Microservice ArchitecturesBenyamin Shafabakhsha, Robert Lagerströmb and Simon Hacksb

aSchool of Electrical Engineering and Computer Science,KTH Royal Institute of Technology,Stockholm, SwedenbDivision of Network and Systems Engineering,KTH Royal Institute of Technology,Stockholm, Sweden

AbstractWith the substantial growth of cloud computing over the past decade, microservice architectures have gained significantpopularity and have become a prevalent choice for designing cloud-based applications. Microservices based applications aredistributed and each service can run on a different machine. Due to its distributed nature, one of the key challenges whendesigning applications is the mechanism by which services communicate with each other. There are several approachesfor 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 compareand contrast the popular forms of IPC communications. Several load test scenarios have been executed to obtain quantitativedata 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 advantagesover its synchronous rival.

KeywordsMicroservices, Inter Process Communication, IPC, Inter-Service Communication, Distributed Systems, gRPC, RabbitMQ

1. IntroductionOver the past few years, microservices have earnedenormous attention and gained popularity from the in-dustry. They helped large organisation such as Ama-zon and Netflix to serve millions of requests per min-utes [1]. Microservice architecture is a style of devel-oping software as a collection of independent services.Each service is running on its own process that is in-dependent from other processes and can be deployedseparately from other services [2]. Designing a soft-ware based on microservices involves answering ques-tions and overcoming technical challenges that oftendo not exist in monolithic architecture, like inter pro-cess communication (IPC) [3], service discovery [4],decomposition strategy [5], or managing ACID trans-actions [6].

Despite the growth and importance of microser-vices in industry, there has not been sufficient researchon microservices, partly due to lacking a benchmarksystem that reflects the characteristics of industrial mi-

Woodstock’20: Symposium on the irreproducible science, June 01–05,2020, Woodstock, NYemail: bensha@kth.se (B. Shafabakhsh); robertl@kth.se (R.Lagerström); shacks@kth.se (S. Hacks)orcid: 0000-0003-3089-3885 (R. Lagerström); 0000-0003-0478-9347(S. Hacks)

© 2020 Copyright for this paper by its authors. Use permitted under CreativeCommons License Attribution 4.0 International (CC BY 4.0).

CEURWorkshopProceedings

http://ceur-ws.orgISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)

croservice systems [7]. IPC is one of the importantchallenges of microservice architectures [8]. In mono-lithic based systems, components can call each otherat the language-level while in microservices each com-ponent is running on its own process and possibly ona different machine than other services. The choiceof IPC mechanism is an important architectural deci-sion which can impact the software’s non-functionalrequirements [8].

As of today, there are no concrete explanations orany standardized approach that can help to decide theright IPC method when designing microservice basedapplications. Due to this reason, there is an abun-dant confusion around the question of when to usewhich method and what are the trade-offs for choos-ing that method. Deciding between a synchronous andasynchronous approach is an important decision totake in regards to how services collaborate with eachother [9].

There are two questions this paper is working to-wards answering:

1. From performance efficiency standpoint, whatare the implications for utilizing availablesynchronous and asynchronous methods for im-plementing IPC in microservice architectures?

2. How does the IPC method choice impact avail-ability of the system?

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

55

The motive behind selecting the performance effi-ciency, and availability as the two criteria for this re-search is that the choice of IPC method directly im-pacts these two non-functional requirements in a mi-croservices based system, while other non-functionalrequirements such as security [10] and maintainabil-ity [11] can span over few other areas and goes beyondIPC. Being able to measure these qualities in the sys-tem are critical in order to achieve an efficient manage-ment of any software system [12, 13]. Moreover, thechosen quality attributes are among the top prioritiesfor most modern applications [14, 15].

In this work, we describe a systematic approach forselecting IPC method when designing microservicesbased software. The remainder of this paper focuseson state of the art in identifying different IPC modelsin section 2. Next, in section 3, we discuss the develop-ment of the prototypes built for the purpose of discov-ering the relationship between each IPC method andits impact on performance efficiency and availability.We then run a test against each prototype to investi-gate its outcome and discuss previous work conductedin this domain. Finally, we draw a conclusion in sec-tion 6.

2. State of the ArtWhen designing IPC mechanism, there are two typeof interaction style to choose from: synchronous andasynchronous, which we will shortly introduce next.

2.1. Synchronous CommunicationSynchronous communication is often regarded as re-quest/response interaction style. One microservicemakes a request to another service and waits for theservices to process the result and send a response back.In this style, it is common that the requester blocks itsoperation while waiting for a response from the re-mote server. Representational state transfer (REST)application programming interfaces (API) [16] andgRPC1 are the most common framework for imple-menting Synchronous form of communication in mi-croservices [8].

• REST API: REST is an architectural style that iscommonly used for designing APIs for modernweb services [17]. In a system that uses RESTAPI for its IPC communication, each servicetypically has its own web-server up and run-ning on a specific port such as 8080 or 443, and

1https://grpc.io

each service exposes a set of endpoints to enablethe interactions with other microservices andexchange of information between them. Theserver interacts directly with client through itsinterface also known as Web API.

• gRPC: gRPC is an open source high perfor-mance RPC framework designed an developedby Google. Remote procedure call (RPC) is amechanism used in many distributed applica-tions to facilitate inter process communication.RPC was first implemented by Birrell and Nel-son [18] and it has been regarded as a proto-col that enables a message exchange betweentwo process with characteristics of low over-head, simplicity and transparency [19]. By de-fault, when a client sends a request to a serverit halt the process and waits for the results to bereturned. RPC is therefore considered as synch-ronous form of communication [20]. Figure 1presents the operational process between clientand server in gRPC. In this model, the client im-plements the same method as its correspond-ing server through local objects also known asstubs.

2.2. Asynchronous CommunicationThe asynchronous form of communication can be im-plemented in microservices when services exchangemessages with each other through a message broker.In this form of interaction, the message broker acts asan intermediary between services to coordinate therequest and responses [8]. One of the fundamentaldifferences in asynchronous communication as com-pared to the synchronous mode is that in asynchro-nous communication the client no longer makes a di-rect call to the server and expect an immediate answer.Instead, other services subscribe to the same broker topick-up the available requests and process them fur-ther before placing them back to the message queue.

Figure 2 provides an example of the asynchronouspattern. In this sample, when a new order is created,the customer service publishes a request to the bro-ker with some metadata such as customer id, customeremail address, etc. Other services such as loyalty, post,and email service subscribe to that broker and take therequest from there without having to communicatewith Customer service directly.

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

56

Figure 1: gRPC architecture [21].

Figure 2: High-level architecture of Asynchronous pattern[9].

3. ImplementationTo identify the quality attributes of each IPC method,we have designed and developed a set of microservicesfor an e-commerce scenario. In this scenario, the goalis to simulate fetching all the information requiredto display a product page of an e-commerce website.A client requests a product page to be displayed onhis/her device and behind the scenes the following mi-croservices work together to serve that request:

• Product Information Service: This microser-vice is responsible for fetching the primarymetadata associated with the requested prod-uct. Information such as product name, price,description, color, and image are stored in thismicroservice database.

• Product Review Service: This microservice isresponsible for fetching the customer reviews

associated with the requested product from itsdatabase.

• Product Recommendation Service: This mi-croservice is responsible for fetching the prod-uct recommendations based on the requestedproductId from its database.

• Product Shipping Service: This microserviceis responsible for fetching available shipmentoptions and the delivery estimates based on thegiven product from its database.

• Customer Shopping Cart Service: This mi-croservices is responsible for fetching the exist-ing items in the customer’s shopping cart in or-der to display them to the customer.

All the microservices have been developed usingNodeJS2. A non-relational database system, Mon-goDB3, has been used as the database solution for allthe microservices except for the service responsible forproviding shipment information. Due to the natureof data required by shipping service, the shipping ser-vice uses MYSQL4. Docker5 has been utilized to con-tainerize all the microservices. In order to run the testsystem, the services have been deployed to MicrosoftAzure Kubernetes Cluster Service6. Table 1 shows the

2https://nodejs.org/en/3https://www.mongodb.com/4https://www.mysql.com/5https://www.docker.com/6https://azure.microsoft.com/sv-se/services/kubernetes-

service/

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

57

Table 1Kubernetes Cluster specification of the test system.

Instance Type Azure DS2-v2vCPU 2Memory 7 GiBStorage 8 GiB, SSD, 6400 IOPSKubernetes Version 1.14.8Node Count 3

hardware specification of the testing system used forthis research.

In the synchronous mode both REST API, and gRPChave an identical architecture; in both methods, thereis a direct communication between API Gateway7 andeach microservice. Each microservice acts as server,and the API Gateway acts as a client of those server.The key difference between REST API and gRPC is theunderlying communication protocol as well as the for-mat of the messages they exchange. gRPC has adoptedprotocol buffer8 as its proprietary message format,while the REST API uses JSON [22] format to exchangedata.

The asynchronous architecture uses RabbitMQ asmessage broker. In this pattern, the communicationbetween API gateway and other services does not takeplace directly, rather it goes through a mediator alsoknown as message queue. In both synchronous andasynchronous methods, the API Gateway is the entrypoint to the system, which receives a request with spe-cific product id from client’s device such mobile app orweb browser over HTTPS protocol. The gateway thencommunicates back and forth with each microservicedepending on the IPC method the system uses.

4. Results and Evaluation

4.1. Performance EfficiencyThree test cases have been designed and executed us-ing Apache JMeter9. All test cases aim to measurethe throughput of each IPC method. Throughput isan essential attribute for calculating performance effi-ciency. In all three test experiments, the test durationwas 180 seconds, while the number of concurrent vir-tual users that continuously send requests to the sys-tem and wait for response has been varied. The motivebehind having test duration as a constant variable andnumber of virtual users as the controlled variable is

7https://microservices.io/patterns/apigateway.html8https://developers.google.com/protocol-buffers9https://jmeter.apache.org/

to understand how each IPC method reacts differentlywhen the concurrent requests and traffic to the systemincrease or decrease.

Throughput is calculated by the total number of re-quests and responses the method managed to makewithin the specified duration of 180 seconds; thehigher the number, the higher the throughput and thebetter it is.

The results are presented in figure 3. The data in-dicates that gRPC has outperformed REST API, andRabbitMQ in the first case with 50 users by beingable to process 43 requests higher than REST API, and147 requests more than RabbitMQ; this signifies thatsynchronous form of communication can offer higherthroughput than the asynchronous method in the sit-uation when the load to the system is relatively low.Meanwhile, the result of the first case also revealsthat synchronous form of communication can processrequests slightly faster than asynchronous form and,therefore, has lower latency when the number of con-current threads10 in the system is low.

The second case has double the number of virtualusers as compared to the first one. Increasing the num-ber of virtual users causes the number of concurrentthreads in the system to grow and results in longerprocessing time. The same data imply that gRPC hasthe highest throughput by processing a higher num-ber of requests compared to RabbitMQ and REST API;however, the gap between gRPC and RabbitMQ is nowmore narrowed than in the first case. In this test, gRPCmanaged to score the best average response time thanREST API and RabbitMQ by 200 milliseconds. Theprocessing time between REST API and RabbitMQ areequal to each other; however, RabbitMQ managed toprocess extra 25 requests than its synchronous rival.

The number of virtual users in the third case hasincreased four times as compared to the first case.The outcome of the third testing experiment im-plies considerable difference between synchronousversus asynchronous form of communication both inthroughput and latency when the number of paral-lel requests increases. In this test, asynchronous formof communication using RabbitMQ has outperformedthe other two methods by being able to process atotal of 4480 requests within the given period whilegRPC managed to process 132 requests lower thanRabbitMQ, and REST API processed 146 less requeststhan its asynchronous rival. What makes the asynch-ronous pattern to operate better in the third test caseis that, in asynchronous form the performance declinetake place more gradually while in the synchronous

10Each virtual user occupies one thread in the system.

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

58

Figure 3: Throughput comparison.

pattern the performance begins to drop radically assoon as the load to the system intensifies.

4.2. AvailabilityThere are variety of parameters that can affect avail-ability of a system –even hardware components canplay a role in determining the availability rate of a sys-tem. For this measurement, all the parameters out-side IPC has been ignored. The availability of eachIPC method has been calculated by using the followingequation [23]:

𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 =𝑀𝑇 𝑇𝐹

𝑀𝑇 𝑇𝐹 +𝑀𝑇 𝑇𝑅,

with MTTF standing for "Mean Time to Failure," andMTTR for "Mean Time to Recovery." MTTF representsthe duration that the system is expected to last in op-eration before failure occurs. In contrast, MTTR rep-resents the duration the system requires to return tooperation after a failure has occurred. The higher theMTTR, the longer it takes for the system to recoverfrom a failure, which consequently reduces the avail-ability of the system.

Based on this formula, three other tests were exe-cuted using Apache Jmeter against all the three differ-ent IPC methods to discover which one offers higheravailability. Unlike the previous test cases that had afixed duration, these test cases had no specific dura-tion. They ran as long as the services became unavail-able due to the high number of requests coming to thesystem. Further, in this test, the average response time,

and the number of requests/responses were not beentracked since they do not contribute to determiningthe availability of the method. The first case ran with200 virtual users, the second with 300 virtual users,and third with 400 virtual users. Without having ahigh number of parallel users measuring availabilitybecomes more challenging as the system remains op-erational for a significantly longer duration.

Figure 4 provides a summary of the conducted tests.During the first test, it took about seven minutes forthe services to become unavailable using RabbitMQ,while gRPC went down after about five minutes, andthe REST API took approximately four and a halfminutes. These numbers were then dropped in eachmethod in the subsequent tests as the number of par-allel requests were doubled. After the services becameunavailable, the Kubernetes cluster has been manu-ally restarted. From that moment, both gRPC andREST API took about 20 seconds only to become avail-able again, while RabbitMQ took ten extra seconds.The main reason behind RabbitMQ taking longer thansynchronous form to return back to operation is thefact that it has an extra component known as a mes-sage broker that requires to be refreshed and establisha new connection with each service. From this exper-iment, it is possible to infer that an asynchronous ap-proach offers higher availability than its synchronousopponents.

Consequently, if microservices use a synchronousbased communication both client and server must beresponsive at all time, otherwise the request will failafter a specific duration depending on the configura-

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

59

Figure 4: Availability comparison.

tion. In contrast, a temporary outage of the server inan asynchronous setting causes minimal to no impactto the consumer, since the consumer is loosely coupledwith the server. The requests can stay in the messagequeue and be processed at the later timing when theserver is back to operation. The asynchronous patternoffers capabilities that can help the system to improveits availability and resiliency from outage. It allowscontinuous operation even if there is a failure in one ofthe system’s components without compromising theavailability of the entire system.

4.3. Discussion and Threats to ValidityIn addition to the two non-functional requirementsthat have been evaluated throughout this work, it isimportant to take into account the functional require-ments for which microservices are being developedfor. It is essential to distinguish whether the scenariorequires an immediate response back from services ornot. To elaborate further on this, in the proof of con-cept scenario that was built during this work, display-ing a product page for an e-commerce was simulated.In this scenario, the client sends a request to load theproduct page and expects an immediate result back.The result of the request can either be the product pageor an error that indicating the request was failed. Thekey point in this scenario is that the client expects animmediate result. In such scenarios the synchronousform of communication can be more suitable as thesescenarios cannot take advantage of the features thatan asynchronous form can offer.

Furthermore, our research incorporates some

threats to validity. First, we performed our experi-ments just with single technologies as representativesfor certain principles (synchronous vs. asynchro-nous). Therefore, our results can just indicate certainadvantages of these principles. Second, we simulatedno complete system but just a small part of a biggersystem, e.g., there is no communication between themicroservices during our requests. However, thisensures that we are not testing other effects, butonly the interaction between the gateway and themicroservices. Third, we were using technologies thatare highly configurable, thus a completly differentconfiguration could lead to other results. However, aswe just changed configurations where necessary, weassume that others can reproduce our results, espe-cially as they are in accordance with our theoreticalexpectations.

5. Related WorkSufficient work has been done to benchmark the per-formance of microservices, and compare and contrastit with other architectures such as service oriented ar-chitecture (SOA) [24], or with the monolithic architec-ture [25, 26, 27, 28, 29].

Ueda et al. [30] conducted research at IBM thataimed to design an infrastructure that is optimized forrunning microservice architectures. The team builttwo versions of the sample application. One based onmonolithic and the other based on microservices. Theteam discovered a significant performance overheadand higher hardware resource consumption in the mi-

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

60

croservices version of the application as compared tomonolithic one. The paper has marked poor designof process communication in microservice architec-tures as one of the significant performance degrada-tions, and, therefore, unleashed the potential for fur-ther research and improvements in this topic. The pa-per has also pointed out that network virtualizationtechniques, which are often used in a microservice ar-chitectures, is another non-negligible reason behindthe performance gap of monolithic versus microser-vice architecture. The paper, however, has not pre-scribed any specific solution or suggestion as to howto overcome these challenges but rather pointed outthe potential future work for it.

Fernandes et al. [31] compared REST API per-formance versus advanced message queuing proto-col (AMQP) [32], which is one of the protocols usedin message-based communication that falls underasynchronous category. The study has been done bymeasuring the averaged exchanged messages for a pe-riod of time using the REST API and AMQP. The au-thors performed the experiments by setting up two in-dependent software instances that constantly receivedmessages for a 30 minutes period with an average 226request per second. Each instance processed the re-ceived input message and stored them into a persis-tent database. After executing the experiments, theauthors concluded that for scenarios where there is aneed to receive and process-intensive amount of data,AMQP performs far better than REST API as it hasa better mechanism for data loss prevention, bettermessage organization, and utilize lower hardware re-sources.

In contrast to Fernandes et al., check we in our workthe behavior of the systems with different loads. Werecognize that synchronous approaches perform goodwith low loads while asynchronous approaches scalebetter at higher loads.

Meanwhile, Dragoni et al. [28] have conducted amigration for a real-world mission-critical case studyin the banking industry by transforming a monolithicsoftware into a microservice architecture. They ob-served how availability and reliability of the systemchanged as a result of the new architecture. The so-lution consists of decomposing several large compo-nents to which some of them requires to communicatewith third-party services. The services in the new ar-chitecture use message-based asynchronous commu-nication as its IPC model to exchange data with eachother. The authors believe that aiming to have a simpleand decouple integration between services and follow-ing principle to handler failure will eventually lead tohigher reliability in microservice architecture.

Further, the authors argue that microservice archi-tectures lead to a higher availability as the new systemis broken down into several components and decou-pled from each other, which makes it possible to load-balance individual services as needed. This was par-ticularly not possible in the legacy monolithic basedsystem. At the same time, the new architecture of-fers higher reliability and can better cope with fail-ures. This is due to the fact that in the new system thecommunication relies on a message-broker that can beconfigured to ensure all messages get delivered even-tually.

6. ConclusionWhen developing a microservices based system, thechoice of IPC method is an important decision tomake. In this paper, we compared synchronous andasynchronous IPC methods with regards to perfor-mance efficiency and availability. The outcome ofour evaluation indicates that on average asynchro-nous approach provides better performance efficiencyand higher availability. We also discussed a scenariowhere synchronous methods are more suitable to beutilized. Therefore, both synchronous and asynchro-nous type of communication has to be adopted accord-ing to the functional and non-functional requirementsof the specific components.

References[1] J. Thönes, Microservices, IEEE software 32 (2015)

116–116.[2] D. Namiot, M. Sneps-Sneppe, On micro-services

architecture, International Journal of Open In-formation Technologies 2 (2014) 24–27.

[3] L. L. Peterson, N. C. Buchholz, R. D. Schlicht-ing, Preserving and using context informationin interprocess communication, ACM Trans.Comput. Syst. 7 (1989) 217–246. doi:10.1145/65000.65001.

[4] S. Haselböck, R. Weinreich, G. Buchgeher, Deci-sion guidance models for microservices: servicediscovery and fault tolerance, in: Proceedings ofthe Fifth European Conference on the Engineer-ing of Computer-Based Systems, 2017, pp. 1–10.

[5] J. Fritzsch, J. Bogner, A. Zimmermann, S. Wag-ner, From monolith to microservices: A clas-sification of refactoring approaches, in: J.-M.Bruel, M. Mazzara, B. Meyer (Eds.), Software En-gineering Aspects of Continuous Development

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

61

and New Paradigms of Software Production andDeployment, Springer International Publishing,Cham, 2019, pp. 128–141.

[6] C. K. Rudrabhatla, Comparison of event choreog-raphy and orchestration techniques in microser-vice architecture, Int J Adv Comput Sci Appl 9(2018) 18–22.

[7] X. Zhou, X. Peng, T. Xie, J. Sun, C. Xu, C. Ji,W. Zhao, Poster: Benchmarking microservicesystems for software engineering research, in:2018 IEEE/ACM 40th International Conferenceon Software Engineering: Companion (ICSE-Companion), IEEE, 2018, pp. 323–324.

[8] C. Richardson, Microservices patterns: with ex-amples in Java, Manning Publications, 2019.

[9] S. Newman, Building microservices : designingfine-grained systems, first edition.. ed., 2015.

[10] P. Johnson, D. Gorton, R. Lagerström, M. Ekst-edt, Time between vulnerability disclosures: Ameasure of software product vulnerability, Com-puters & Security 62 (2016) 278–295.

[11] R. Lagerström, P. Johnson, M. Ekstedt, Architec-ture analysis of enterprise systems modifiability:a metamodel for software change cost estima-tion, Software quality journal 18 (2010) 437–468.

[12] P. Närman, P. Johnson, R. Lagerström, U. Franke,M. Ekstedt, Data collection prioritization for sys-tem quality analysis, Electronic Notes in Theo-retical Computer Science 233 (2009) 29–42.

[13] M. Ekstedt, U. Franke, P. Johnson, R. Lagerström,T. Sommestad, J. Ullberg, M. Buschle, A toolfor enterprise architecture analysis of maintain-ability, in: 2009 13th European Conference onSoftware Maintenance and Reengineering, IEEE,2009, pp. 327–328.

[14] U. Franke, M. Ekstedt, R. Lagerström, J. Saat,R. Winter, Trends in enterprise architecturepractice–a survey, in: International Workshopon Trends in Enterprise Architecture Research,Springer, 2010, pp. 16–29.

[15] P. Johnson, R. Lagerström, P. Närman, M. Simon-sson, Extended influence diagrams for systemquality analysis, Journal of Software 2 (2007) 30–42.

[16] R. T. Fielding, R. N. Taylor, Architectural stylesand the design of network-based software ar-chitectures, volume 7, University of California,Irvine Irvine, 2000.

[17] M. Masse, REST API Design Rulebook: Design-ing Consistent RESTful Web Service Interfaces, "O’Reilly Media, Inc.", 2011.

[18] A. D. Birrell, B. J. Nelson, Implementing remoteprocedure calls, ACM Transactions on Computer

Systems (TOCS) 2 (1984) 39–59.[19] J.-K. Lee, A group management system anal-

ysis of grpc protocol for distributed networkmanagement systems, in: SMC’98 ConferenceProceedings. 1998 IEEE International Conferenceon Systems, Man, and Cybernetics (Cat. No.98CH36218), volume 3, IEEE, 1998, pp. 2507–2512.

[20] R. A. Olsson, A. W. Keen, Remote ProcedureCall, Springer US, Boston, MA, 2004, pp. 91–105.doi:10.1007/1-4020-8086-7_8.

[21] S. G. Du, J. W. Lee, K. Kim, Proposal of grpc asa new northbound api for application layer com-munication efficiency in sdn, in: Proceedings ofthe 12th International Conference on UbiquitousInformation Management and Communication,2018, pp. 1–6.

[22] C. Severance, Discovering javascript object no-tation, Computer 45 (2012) 6–8.

[23] P. Johnson, R. Lagerström, M. Ekstedt, M. Öster-lind, It management with enterprise architecture,KTH, Stockholm (2014).

[24] T. Erl, Service-oriented architecture: concepts,technology, and design, Pearson Education India,1900.

[25] T. Cerny, M. J. Donahoo, J. Pechanec, Dis-ambiguation and comparison of soa, microser-vices and self-contained systems, in: Proceed-ings of the International Conference on Researchin Adaptive and Convergent Systems, RACS’17, Association for Computing Machinery, NewYork, NY, USA, 2017, p. 228–235. doi:10.1145/3129676.3129682.

[26] D. Taibi, V. Lenarduzzi, C. Pahl, Processes, mo-tivations, and issues for migrating to microser-vices architectures: An empirical investigation,IEEE Cloud Computing 4 (2017) 22–32.

[27] R. Chen, S. Li, Z. Li, From monolith to microser-vices: A dataflow-driven approach, in: 201724th Asia-Pacific Software Engineering Confer-ence (APSEC), 2017, pp. 466–475.

[28] N. Dragoni, S. Dustdar, S. T. Larsen, M. Mazzara,Microservices: Migration of a mission criticalsystem, arXiv preprint arXiv:1704.04173 (2017).

[29] Z. Kozhirbayev, R. O. Sinnott, A performancecomparison of container-based technologies forthe cloud, Future Generation Computer Systems68 (2017) 175 – 182. doi:10.1016/j.future.2016.08.025.

[30] T. Ueda, T. Nakaike, M. Ohara, Workload char-acterization for microservices, in: 2016 IEEE in-ternational symposium on workload characteri-zation (IISWC), IEEE, 2016, pp. 1–10.

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

62

[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.

8th International Workshop on Quantitative Approaches to Software Quality (QuASoQ 2020)

63