IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2018

The run-time impact of business functionality when decomposing and adopting the microservice architecture

RASTI FARADJ

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

The run-time impact of

business functionality when

decomposing and adopting

the microservice architecture

RASTI FARADJ

Master in Computer ScienceDate: September 26, 2018Supervisor: Hamid FaragardiExaminer: Elena TroubitsynaSchool of Computer Science and Communication

iii

Abstract

In line with the growth of software, code bases are getting bigger andmore complex. As a result of this, the architectural patterns, whichsystems rely upon, are becoming increasingly important. Recently, de-composed architectural styles have become a popular choice.

This thesis explores system behavior with respect to decomposingsystem granularity and external communication between the resultingdecomposed services. An e-commerce scenario was modeled and im-plemented at different granularity levels to measure the response time.In establishing the communication, both REST with HTTP and JSONand the gRPC framework were utilized.

The results showed that decomposition has impact on run-time be-haviour and external communication. The highest granularity levelimplemented with gRPC for communication establishment adds 10ms.In the context of how the web behaves today, it can be interpreted asfeasible but there is no discussion yet on whether it is theoretically de-sirable.

iv

Sammanfattning

I linje med de växande mjukvarusystemen blir kodbaserna större ochmer komplexa. Arkitekturerna som systemen bygger på får allt störrebetydelse.

Detta examensarbete utforskar hur upplösning av system som tilläm-par mikroservicearkitektur beter sig, och hur de påverkas av kommu-nikationsupprättande bland de upplösta och resulterande tjänsterna.Ett e-handelsscenario modelleras i olika granularitetsnivåer där RESTmed HTTP och JSON samt gRPC används för att upprätta kommuni-kationen.

Resultaten visar att upplösningen påverkar runtimebeteendet ochden externa kommunikationen blir långsammare. En möjlig slutsatsär att påverkan från den externa kommunikationen i förhållande tillhur webben beter sig idag är acceptabel. Men om man ska ligga inomteoretiskt optimala gränser kan påverkan ses som för stor.

Contents

1 Introduction 11.1 Problem description . . . . . . . . . . . . . . . . . . . . . 21.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Research contribution . . . . . . . . . . . . . . . . . . . . . 41.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 62.1 Software architecture . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Monolithic architecture . . . . . . . . . . . . . . . 72.1.2 Service-oriented architecture . . . . . . . . . . . . 82.1.3 Microservice architecture . . . . . . . . . . . . . . 9

2.2 Software decomposition . . . . . . . . . . . . . . . . . . . 102.3 External communication pattern . . . . . . . . . . . . . . 12

2.3.1 REST . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2 gRPC . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.3 Apache kafka . . . . . . . . . . . . . . . . . . . . . 14

2.4 Data Serialisation . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Protocol Buffers . . . . . . . . . . . . . . . . . . . . 16

3 Related work 17

4 Research method 214.1 Research objective . . . . . . . . . . . . . . . . . . . . . . . 214.2 Research challenges . . . . . . . . . . . . . . . . . . . . . . 214.3 Research question . . . . . . . . . . . . . . . . . . . . . . . 224.4 Scientific Perspective . . . . . . . . . . . . . . . . . . . . . 22

v

vi CONTENTS

4.5 Research methodology . . . . . . . . . . . . . . . . . . . . 234.6 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6.1 Construct validity . . . . . . . . . . . . . . . . . . 244.6.2 Internal validity . . . . . . . . . . . . . . . . . . . . 244.6.3 Conclusion validity . . . . . . . . . . . . . . . . . . 24

5 Implementation 265.1 Granularity and communication . . . . . . . . . . . . . . 265.2 Modelling of the architectural cases . . . . . . . . . . . . . 275.3 Implementation and realization . . . . . . . . . . . . . . . 295.4 Platform specification . . . . . . . . . . . . . . . . . . . . . 325.5 Measurement tool and parameters . . . . . . . . . . . . . 32

6 Results 336.1 Results from conducted experiments . . . . . . . . . . . . 33

7 Conclusion 367.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.2 Recommendation . . . . . . . . . . . . . . . . . . . . . . . 387.3 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . 397.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 41

List of Figures

2.1 Evolution of System Architecture [34] . . . . . . . . . . . 72.2 gRPC architectural overview [34] . . . . . . . . . . . . . . 142.3 Component orchestration in Apache Kafka [19] . . . . . . 15

4.1 Research methodology. . . . . . . . . . . . . . . . . . . . . 25

5.1 Chosen communication patterns . . . . . . . . . . . . . . 265.2 Chosen granularity levels to implement . . . . . . . . . . 265.3 Monolithic architecture of order-placement . . . . . . . . 275.4 Decomposed architecture consisting of two services . . . 285.5 Decomposed architecture consisting of eight services . . 295.6 Relations between services in figure 5.5 . . . . . . . . . . 295.7 Service communication with HTTP and JSON . . . . . . 315.8 Service communication with gRPC . . . . . . . . . . . . . 31

vii

List of Tables

2.1 Example of endpoints utilizing HTTP verbs . . . . . . . . 13

5.1 Format of data sent between services . . . . . . . . . . . . 305.2 Parameters for performance measurement . . . . . . . . . 32

6.1 Monolithic architecture - 10 Requests . . . . . . . . . . . . 336.2 Decomposed HTTP and JSON - 10 Requests . . . . . . . . 346.3 Decomposed with gRPC - 10 Requests . . . . . . . . . . . 346.4 Monolithic architecture - 1000 Requests . . . . . . . . . . 346.5 Decomposed HTTP and JSON - 1000 Requests . . . . . . 356.6 Decomposed with gRPC - 1000 Requests . . . . . . . . . . 35

viii

Chapter 1

Introduction

This thesis aims at exploring different software architectural styles.Furthermore, it investigates the relation between decomposition andrun-time behavior of business functionality in software systems. Nowa-days, we have reached the point where large software design and de-velopment are coming to an end. The increased complexity in big codestacks is making them unsustainable and unmaintainable. To dealwith this, new design approaches have emerged in recent years. Anexample of this is the MicroService Architecture (MSA).

In this thesis, a known e-commerce scenario is developed usingthe decomposition of different granularities. Together with distinctivecommunication patterns, the systems is implemented using the MSAstyle. The impact of decomposition, in particular, the run-time impact,is analyzed for the different granularity levels and communication pat-terns.

As systems grow, they become harder to maintain and develop be-cause of the internal dependencies and relations. The growth also hasan impact on the deployment phases because any change in the systemrequires rebuilding and redeploying the whole system. The emergenceof MSA has made it possible to decouple and decompose the systeminto more manageable components and services [16, 20, 1].

The MSA approach itself is relatively new and unexplored. Thereis no consensus regarding its formal definition [20, 36]. The first us-age of the term "microservices" dates back to early 2011. Until then,this new approach of building systems, which resembles the conceptsof Service-Oriented-Architecture (SOA), has existed under differentnames. Netflix, for instance, used a similar style called fine-grained

1

2 CHAPTER 1. INTRODUCTION

SOA. The main idea behind this innovation is to decompose largemonolithic systems, where the whole application runs as a single unit,into smaller independent and loosely coupled components that makeup the desired system.

There are several publications regarding MSA and its benefits. Forinstance, the scalability factor and the faster deployment cycles havebeen discussed in many journals and articles. This is due to the looselycoupled services, which result in more efficient development processes.On the other hand, there is still a gap in the knowledge regarding un-derstanding the granularity and complexity of decomposing systems.It is hard to interpret the actual impact of decomposition and benefitthat comes from further decomposition. Improving the understandingof the impact of different granularity levels and different messagingpatterns would indeed be of interest [41, 5, 36, 21].

When decomposing a system following the MSA principles, effortmust be put on the establishment of external communication betweenthe resulting services. There are several messaging patterns, the mostcommonly used is REST style with HTTP and JSON. There are otheralternatives one can make use of, for instance, Google’s gRPC or thedistributing streaming platform Apache Kafka.

1.1 Problem description

Despite novelty for this new architectural style of microservices, sev-eral big IT-companies have adopted the idea. Today, there is no stan-dardized approach to deciding on the granularity of decomposition,nor is there any theoretical support to analyze the system behavior af-ter the decomposition. One can only assume that the impact of theintroduction of external communications is felt on decomposed ser-vices, but to what extent? When decomposing a system, the run-timeimpact of business functionality should be analyzed, especially if thereare requirements regarding the response time to be fulfilled.

1.2 Objective

The primary goal of this thesis project is to investigate the run-timeimpact of decomposing a monolithic architecture and to analyze itseffects on the system behavior, especially regarding the run-time of

CHAPTER 1. INTRODUCTION 3

business functionality. Furthermore, it is necessary to identify com-mon methods which are effective in establishing external communica-tion between services in a microservice architecture.

An architectural example will be presented and implemented atdifferent granularity levels along with the use of different patterns ofestablishing communications. Regarding the external communicationbetween the implemented services, the approaches that will be of useis REST style with HTTP and JSON, as well as Google’s gRPC. Theformer will be in a textual format while the later will be in binary, to geta comprehensive idea of the possibilities and their resulting outcome.

The ultimate objective of this project is to gain an understanding ofthe impact of the decomposition process on system behavior to be usedas basis in the decision-making process regarding granularity levels.

1.3 Delimitation

The thesis only covers a limited number of granularity levels, whichare enough to give a broad indication. They all concern a single busi-ness functionality. However, the result could be used to understandthe impact on a system as a whole.

The choice of communication patterns selected is an outcome of apre-study. The chosen ones have either gained momentum lately orare already commonly used.

The cases covered in this thesis are relevant to different environ-ments. Placement of the server and individual services can vary geo-graphically. For consistency and reproducibility, this thesis only per-forms local tests. Testing on different hosting alternatives could havebeen carried out, but for now, only local tests have been performed.Therefore, the measured overhead from the decomposition is mainlyserialization/deserialization, not the network latency. Consequently,the environment specific parameters such as CPU, RAM, and the net-work are neglected.

1.4 Methodology

This thesis adopts the empirical approach where quantitative data aregathered. Furthermore, a qualitative method is applied to derive con-clusions and recommendations. The practical part consists of tests

4 CHAPTER 1. INTRODUCTION

which are executed in an iterative manner to allow for continuous im-provements.

The first phase of the thesis consists of a state-of-the-art overview,which is meant to take advantage of the current research within thesoftware architectural style area as well as the communication pat-terns.

1.5 Results

The obtained results demonstrate the impact of different granularitylevels on run-time behavior. The highest tested granularity level ofeight services gives a penalty of 10ms in comparison to a monolithic ar-chitecture and usage of gRPC within the 90th percentile increase. Withthe usage of REST, the measured penalty was 46ms.

Therefore, it can be concluded that among the examined commu-nications styles: REST with HTTP and JSON, and gRPC, the latter per-formed better and is preferable because it serializes/deserializes fasterand hence, results in better response times.

These numbers may, at first glance, have significant impact, butlooking at how the web behaves today they can be acceptable depend-ing on the use-case.

1.6 Research contribution

The thesis is valuable for those adopting the MSA architectural stylesince it would benefit in giving guidance on the relationship betweengranularity and its effect on run-time.

The deepened understanding of the behavior will contribute to to-day’s research and the development of systems. The target audiencecan be both system architects and developers with the interest in de-veloping sustainable systems.

CHAPTER 1. INTRODUCTION 5

1.7 Outline

The structure of the thesis is as follows:

Chapter 2, Background This chapter provides the theoretical back-ground and technologies used to conduct the study.

Chapter 3, Related work This chapter reviews related work in thescope of this study.

Chapter 4, Research method This chapter describes the implementa-tion and how the results are obtained.

Chapter 5, Implementation This chapter describes the method as wellas the methodology. This chapter also includes reasoning about thevalidity of this thesis.

Chapter 6, Results This chapter includes the obtained results as wellas a discussion about the results.

Chapter 7, Conclusion This chapter consists of the conclusions anddiscussion. This chapter also includes possibilities for future work inthe scope of this thesis.

Chapter 2

Background

In this chapter, there is an overview background information neededto understand the problem that this thesis is aiming to explore. Asa result of this, different architectural styles of software development,techniques involved in decomposing large code bases as well as differ-ent messaging technologies for communication between services arediscussed.

2.1 Software architecture

Software architectures consist of several different components depend-ing on the intended functionality. When a client-server architecturalstyle is used there are three recurring parts: a client-side user inter-face, a server-side service - comprising the core logic, and a databaseused in storing all the data.

The architectural style for the server-side has changed over theyears to accommodate possible challenges that may arise. The historymap given in figure 2.1 shows the overview of how the patterns haveevolved and resulted in today’s microservice architectural style.

6

CHAPTER 2. BACKGROUND 7

Figure 2.1: Evolution of System Architecture [34]

The following subsections show some of the architectural styles neededto understand the background and origin of the microservice architec-ture. Different patterns as well as in-depth knowledge of microservicearchitecture will be looked into.

2.1.1 Monolithic architecture

As mentioned in the previous section, software architectural stylesusually have a server-side service that holds all the logic and func-tionality. A monolithic architecture is characterized by one cohesivetightly coupled unit of code as illustrated in figure 2.1. It is devel-oped to work together sharing same resources and memory space. Itcan run processes simultaneously across multiple CPUs that share thesame hardware and operating system. It is important to note that thisapproach has its advantages as well as disadvantages [43].

The major advantage of a monolithic architecture is that the in-process invocations are carried out through language-level calls. Ina decomposed system, external communication must be established,which introduces an overhead that does not exist in a monolithic ar-chitecture.

One could argue that when having one code base, the complexityregarding deployment, testing and monitoring is less complicated be-cause it is one-unit indifferent to a decomposed architecture. Whenexamining a decomposed architecture, one has to deal with hoppingacross machines and network boundaries, whereas each of them mayintroduce new variables and faults into the system.

8 CHAPTER 2. BACKGROUND

Advantage. Scaling a monolithic architecture can be done in twoways. One way is through the duplication of the whole server-side,which is called horizontally scaling. Multiple instances are placed be-hind a load balancer to distribute the incoming requests. However,this is costly due to duplication of the whole code and not the intendedfunctionality. The other approach is through vertically scaling, thisincludes adding more computational power in the form of CPU andRAM. However, this is limited by the size of the server due to the factthat the system cannot be scaled infinitely. For a decomposed architec-ture, one can horizontally scale a specific service instead of the wholearchitecture. This approach is cost-effective and requires less effort.Nevertheless, if stateful workload is considered – memory consumedby temporary storage and processing of state data - then scaling will bea difficult task. More discussion about this will be presented in section2.2. [22]

Disadvantage.With a monolithic architecture, modification withinthe system is complicated. Adding new features or actions to an exist-ing system requires rebuilding and redeployment, in some cases evencorrection of other parts of the system, for it to work as a whole. Devel-opment cycles get longer and additional time is spent coordinating thedevelopment teams. Another drawback is the limitations that comeswith the tools involved, by definition a monolithic structure is imple-mented using a single development stack, which can limit the abilityto choose the right tool for the task.

2.1.2 Service-oriented architecture

The OASIS Reference model for Service-Oriented-Architecture (SOA)describes the term as follows:

"a paradigm for organizing and utilizing distributed capabilities that may

be under the control of different ownership domains." [31]

In other words, it can be defined as the services that encapsulatebusiness functionality that is independent of the state or context ofother services and which can be accessed through well-defined inter-faces. This new pattern gained much momentum in the mid-2000s andvarious companies adopted this new architectural style to bring betterbusiness functionality reuse into their organization. [31, 37, 40, 46]

CHAPTER 2. BACKGROUND 9

SOA provides a flexible architecture by decomposing large server-sides into smaller services. It delivers agility by enabling rapid de-velopment and modification of software and services that only con-cerns a specific business functionality. Although the term SOA hasbeen discussed over the last few years, no convincing answer has beenreached regarding the granularity of its services. There are both ad-vantages and disadvantages of fine- and coarse-grained services. Themore coarse-grained the services are, the more the disadvantage of po-tential reuse and redundancy. The more coarse-grained they are, thebigger is the encapsulation the less is reusability. In contrast, the morefine-grained the services are, the higher the number of services neededto realize a function. This requires more effort to compose. [31, 29, 45,37]

Adoption of SOA requires a highly distributed communication andintegration backbone. It is often utilized with an Enterprise ServiceBus (ESB) [37, 40, 45]. The functionality provided by the ESB is anintegration platform that supports a variety of communications overmultiple transport protocols and delivers capabilities for the SOA [37,45]. In other words, it provides a connectivity layer between differentservices. It is pertinent to point out that ESB does not include anybusiness logic, it only constitutes infrastructure for inter-connectingservices. Figure 2.1 above depicts an illustration of an SOA with anESB utilization.

2.1.3 Microservice architecture

In recent years, this new architectural style, the MicroService Archi-tecture (MSA), has advanced and gained a lot of attention, [16, 50, 20].The approach itself is still relatively new and unexplored, and thereis yet no academic consensus regarding the formal definition of MSA[20, 36]. However, it can be characterized by small, independent andloosely coupled components that encapsulate business functionalityand through their interaction composes the desired systems [20, 15,50, 21].

The usage of the MSA term was noted, for the first time, at an archi-tectural workshop in 2011. Until then, this new approach of buildingsystems, which resembles the concepts of SOA, has been observed un-der different names. Netflix, for instance, used a similar approach butcalled it fine-grained SOA [23].

10 CHAPTER 2. BACKGROUND

As indicated, this is an approach that emerged from the previousSOA style. These two architectural styles have similar advantages aswell as disadvantages. They are both different to a monolithic archi-tecture composed through services that handle different functionality.

Distinguishing these two architectural styles is a difficult task mainlydue to the lack of formal definition for MSA. However, MSA has beendiscovered to be mainly different in server size as well as scope whencompared with SOA, and as a result of this, the services in MSA tendsto be significantly smaller. Some people also claim that the differenceis in the way they handle data storage. SOA tends to have shared stor-age while MSA can have independent storages for respective service.Others claim that there is difference in their means of communicationbecause services in SOA often utilize an ESB, which could be a sin-gle point of failure, while services in MSA are less elaborate and usesimple messaging systems. [33, 6, 8, 39]

In MSA, communication is established through lightweight message-based communication, which can rely on synchronous and asynchronousmessaging. The Representational State Transfer (REST) architecturehas become one of the most common alternatives mainly due to theusage of JSON which is a completely independent platform. GooglesgRPC is another approach - a framework for cross-platform commu-nication that uses protocol buffers for data serialization. The workingprinciples of these aforementioned communication patterns are clari-fied later in this chapter followed by the discussion of differences be-tween them.

2.2 Software decomposition

Some of the main issues with decomposed architectural style such asMSA and SOA have to do with choosing the level of granularity andcomposition of services. In other words, the question of ‘how are thedecomposed services structured?’ must be answered. Many factorshave to be taken into consideration when decomposing a system toobtain a good result. The problem of decomposition itself identify-ing modules, components, and services is not new, the literatures re-viewed have already addressed this challenge [7].

One of the first steps regarding the decomposition of a monolithicarchitecture is the identification of components. Components needed

CHAPTER 2. BACKGROUND 11

for reconstruction of the system represent independent services. Themost challenging part is the identification of the overall functionalityand splitting them into smaller components. During this phase oneshould consider the coordination and composition of components inorder to avoid extra complexity in the form of communication estab-lishment [21].

The concepts of coupling and cohesion are of importance when itcomes to reducing external communications. Coupling is the degree ofinterdependence between modules. In the context of this thesis, it willbe seen as the degree of interdependence between the decoupled ser-vices. Highly coupled systems have service units that are dependenton each other while loosely coupled services are made up of highly in-dependent units. Cohesion is the measure of how well modules withinservices fit together. When it comes to building evolutionary architec-ture for software systems that are able to evolve rapidly and safely, theproperties of both coupling and cohesion must be considered.

One way to decompose is with respect to the organizations busi-ness capabilities [42]. Business capability can be seen as a uniquebuilding block of a business [28]. This approach requires an under-standing of the business, organizations’ structure and processes so thatthe system will be structured according to the organization.

Another approach is to decompose with respect to domains [9].Domain Driven Design (DDD) [17] provides methodologies to analyzethe underlying domain, guiding the design by information flow andprocesses. DDD strategic patterns guide the creation of a Context Map- showing all bounded contexts and their relation to each other andcontracts between them - which can lay foundation for decompositionof the service. The advantage of this approach is that it gives room forthe acquisition of a system that effectively reflects the reality [47].

Decomposition is not always a trivial task. If the examined sys-tem includes a stateful workload then some consistency mechanismor orchestration between the services must be utilized. ‘Statefulness’shows dependencies on conditions and entities at an instant in time.In other words, data consistency is required in decomposition, there-fore, stateful services are dependent on these moments and have tobehave accordingly. Even though the desired characteristics for MSAis statelessness, there are scenarios where it is not achievable. Thereare different solutions to this, for instance, the Saga pattern. The ideabehind the Saga pattern is that there are transactions that span over

12 CHAPTER 2. BACKGROUND

multiple services, i.e., transactions that update the concerned valueand publish/trigger the next transaction. If a violation occurs, a seriesof compensatory transactions are triggered to undo the initial transac-tion [4, 44]. Stateful systems will not be covered in this thesis, but itsimportance in system decomposition is vital and therefore mentioned.

2.3 External communication pattern

Software systems can make use of different types of communicationpatterns between services within a system. One can, among otherthings, make use of the REST style with HTTP and JSON, and anotheroption is the use of Google’s gRPC. It is difficult to point out whichone is preferable because their usage depends on the context and theintended outcome. The following section will give an insight aboutthe two different communication patterns.

2.3.1 REST

Representational State Transfer, REST, is an architectural style that de-fines a set of constraints, which as a whole, describes how resourcesare defined and addressed. Roy Fielding describes the style as:

”. . . a set of architectural constraints that, when applied as a whole, em-

phasizes scalability of component interactions, generality of interfaces, inde-

pendent deployment of components, and intermediary components to reduce

interaction latency, enforce security, and encapsulate legacy systems.” [18]

REST itself does not specify the underlying protocols, transporta-tion protocol, and the serialization method to use. However, due to theacknowledged advantages such as the simplicity of HTTP, direct sup-port of request/response-style communication and no requirement onthe intermediate broker, HTTP protocol combined with JSON has be-come the most widely used alternative.

When utilizing HTTP as a transfer protocol one can make use ofthe capabilities that work well with the REST style. For example,the HTTP verbs (e.g., GET, POST and PUT) all have well-understoodmeanings as to how they work with resources; GET retrieves and POSTcreates resources. This facilitates the creation of different endpoints,

CHAPTER 2. BACKGROUND 13

for instance, only one endpoint is necessary for the methods create-Order and editOrder, where the operations are merged into the HTTPprotocol. Table 2.1 below illustrates this use-case.

Table 2.1: Example of endpoints utilizing HTTP verbsMethod URLPOST /orderPUT /order

The style works in such a way that when a resource is requestedbased on the endpoint and the HTTP verb, the data is processed andthe results are returned. The reason REST has become a widely usedalternative for communication establishment is mainly due to the in-dependency of the platform.

2.3.2 gRPC

gRPC is a Remote Procedure Call framework developed by Google.The gRPC framework can be used in a cross-platform environmentthus supporting a variety of languages. gRPC is based on definitionsof services that specify methods that can be called remotely with corre-sponding parameters and return types. The usage is, in short, carriedout through the implementation of the interface on the server side, tohandle client calls and implementation of the local object known asstubs on the client side which implements the same methods as theserver. Figure 2.2 depicts an overview of the system as well as thecorrelation between the services. [13]

14 CHAPTER 2. BACKGROUND

Figure 2.2: gRPC architectural overview [34]

When it comes to data serialization, gRPC uses protocol buffersper default - Google’s developed mechanism for serializing structureddata. This will be presented in details later in this chapter.

The gRPC framework follows the HTTP semantics over HTTP/2that use binary rather than text to keep the payload compact and ef-ficient. This framework has several advantages that can be utilized.There is, among other things, support for both synchronous and asyn-chronous communication. With gRPC, one can also make use of thestreaming capabilitie, gRPC even allows one establish client, serverand bidirectional streaming between services. [13]

2.3.3 Apache kafka

Apache Kafka is a publish-subscribe distributed messaging systemthat logs messages as they arrive. The main components in ApacheKafka are the producers, brokers, consumers, and topics. These com-ponents cooperate in such a way that the producer writes messages toa topic, which is a category that stores messages. The broker, whichis a Kafka cluster in charge of maintaining topics (in scenarios withlarge sets of data, they are partitioned) takes care of the messages be-tween the producers and consumers. The messages are later receivedby consumers that subscribe to one or more topics. It is important tomention that Apache Kafka is not self-sufficient, it depends on an ex-

CHAPTER 2. BACKGROUND 15

ternal service called Apache ZooKeeper. This is an infrastructure thatacts as a scheduler and a shared database in which all the componentsconnected get messages, e.g., producers will pull an instance, get theaddress of the broker for a topic and consumers will store the offset ofthe last message they have read. The relation between the mentionedcomponents can be seen in figure 2.2. [19]

Figure 2.3: Component orchestration in Apache Kafka [19]

To be able to handle more data than what could be managed byone machine, partitions are created and spread out on a cluster of ma-chines. The partitioning, which enables handling of larger sets of data,makes Apache Kafka scalable as regards total data size. [19]

2.4 Data Serialisation

In a connected system, such as a microservice architecture, servers andclients are dependent on data exchange to accomplish tasks. Serializa-tion is the process of converting data into a format that can be trans-mitted over a network and then be deconstructed and reconstructed ina different environment.

The data serialization formats that will be covered in this section isthe textual JavaScript Object Notation (JSON) and the binary ProtocolBuffers.

2.4.1 JSON

JavaScript Object Notation (JSON) is a syntax for serialization of struc-tured data. It uses human-readable text to transmit data objects con-

16 CHAPTER 2. BACKGROUND

taining pairs of names and values. The names, consisting of stringsand values, can be any of the supported primitives or an array. AJSON object is represented by curly brackets encapsulating an arbi-trary number of pairs of names and values. [14]

2.4.2 Protocol Buffers

Protocol Buffers is an automated mechanism for serializing structureddata. This is done by defining the structure of data through speciallygenerated source code that can later access the structured data.

The process is carried out through specification of how the data isto be serialized. This is done by defining message types through whatis known as the ".proto" files. Each message has one or more uniquelydefined field (at least one), where each field has a pair of names andvalues. Once the messages are defined, one can run the protocol buffercompiler for the desired language over the ".proto" file. This generatesdata access classes which provide the accessors specified fields as wellas methods to serialize and parse the whole structure to and from rawbytes. [11]

Message serialized in a binary format is much lighter than any tex-tual format. This makes them faster to parse. On the other hand, themessages encoded in a binary protocol format is not in a textual for-mat, which is a more convenient and human-readable representationthat is easy for debugging and editing. [11]

Chapter 3

Related work

This chapter gives an overview of effect on the research on MSA andits related fields such as decomposition effect on the system, and theprior MSA styles. The related research is presented in a chronologicalorder based on their publication date. This is done to give a historicaloverview of the progress of research within the topic of this thesis.

In [37], the technologies and approaches that consolidate the princi-ples of SOA are reviewed. The authors conclude that a highly dis-tributed communication and integrated backbone is required, whichis provided by an ESB. The research focuses on ESB and the range offunctionality it offers. The authors propose different approaches to getessential ESB requirements such as orchestration, integrity, security ofmessages among other things.

In [29](2011) Krammer et al. discuss the choice of service granularityand, from an economic perspective, present a decision model. The au-thors explain how granularity affects development and maintenancewhich, for non-optimal solutions, contribute to higher costs. Theyshow that the finer the granularity, the higher the number of servicesand the more effort directed towards composition. In contrast, coarse-grained have higher implementation cost and lower reusability.

In [49], comparisons are conducted for different data serialization for-mats with emphasis being placed on serialization speed, data size, andusability. The serialization formats examined are XML, JSON, Thriftand Protocol Buffers. The two first formats are well known text-based

17

18 CHAPTER 3. RELATED WORK

formats while the latter two are relatively new binary formats. The re-search work concludes that Protocol Buffer is more efficient regardingboth speed and size in comparison to JSON. The author also concludesthat textual format JSON is more beneficial than the binary format be-cause it is parsable on any platform.

In [30], there is a discussion about techniques used in identifying mi-croservices in a system by considering business areas. Creating a de-pendency graph based on functionality and storage has been concludedhelps decomposition. The author concludes that there are scenariosthat require additional efforts with respect to migration to a set of mi-croservices and they are:

• Subsystems that share the same database table.

• Microservice that represents an operation that is always in themiddle of another operation.

• Business operations that involve more than one business subsys-tem on a transaction scope.

In [40], the author compares different architectural characteristics specif-ically between MSA and SOA. The author differentiates the styles basedon the fact that MSA is built on a share-as-little-as-possible pattern,whereas SOA is a share-as-much-as-possible pattern. Furthermore, theauthor discusses that SOA with its integrated ESB runs the risk of a po-tential single point of failure when compared to MSA and API-layeredcommunication establishment.

In [25], Hassan and Bahsoon emphasize that there is a lack of aca-demic consensus regarding the definition as well as the properties ofthe paradigm of microservices. The authors further argue that there isa lack of design patterns for the microservices.

Problems of finalizing the level of granularity of microservice arediscussed in [25]. The trade-off in size versus the number of microser-vices shows that optimal level depends on the scenario in which thesystem is operating. Trade-offs are presented as indicators of design-ing level of granularity and a road-map to be used when extractingmicroservices.

CHAPTER 3. RELATED WORK 19

In [38], the authors discuss communication between services, espe-cially in the scope of the Internet of Things. They discuss the recog-nition of JSON as the most efficient way to transfer data. Furthermore,Google’s Protocol Buffer is introduced as a good method in a standard-ized communication between services. They stress the benefits of Pro-tocol Buffer. For instance, they discuss the effect of reduced networkload and reduced size in sent messages on the reduced overhead.

In [32], the authors use a case-study of a service-based system devel-oped on the Domain Object (DO) approach. The case study demon-strates DO to be suitable for service-based components and also rec-ommend that its applicability to MSA should be examined.

In [16], the authors give an academic point of view on MSA, with at-tention placed on some practical issues and potential solutions. Theauthors also discuss how the interaction between small independentservices can lead to complex network activity and how the complexitycould be exploited and lead to external attacks. They look at MSA inan evolutionary perspective rather than from the revolutionary angle.

In [24], the authors stress that there is still lack of a general and system-atic approach to design decisions when modeling microservices, opti-mal boundaries and optimal granularity levels are yet unknown. Theyformulate the research as a potential run-time decision problem, sincemost uncertainties relate to the behavior of the system, the run-timecontext is more suitable for consideration. They introduce granularityadaption aspect which helps run-time triggers and which can be usedduring monitoring microservices under run-time.

In [35], Mustafa and Marx Gomez conduct an empirical experiment toobserve the response time and CPU utilization for a specific scenariowith a particular workload. They test functionality in the granular-ity level of two and three services. The results show that more fine-grained is preferable in term of response time and CPU utilization.The work does not conclude anything rather than that the work needsto be implemented in a broader perspective, concerning more metrics,and in larges scales to strengthen the outcome.

20 CHAPTER 3. RELATED WORK

In [6], an automated process of identifying microservices is presented.This is done through semantic analysis of the concepts in the inputspecification concerning a reference vocabulary. The identification pro-cess consists of decomposition by matching the terms used in the Ope-nAPI specification as input against a reference vocabulary. The idea isthat the operations that share the same reference concepts are highlycohesive and should, therefore, be together. Future work would com-promise additional non-functional aspects, such as response time, mem-ory allocation and all other aspects that could affect the decompositionprocess.

In [15], Dragoni et al. state the basic building principles of MSA. Theyshow that scalability is one of the key features provided by this newparadigm. They further argue that scalability is required for perfor-mance reasons, to cope with the high load. They also discuss scalabil-ity of MSA in comparison to a monolithic architecture and highlightthe problem of how well the paradigm will integrate with the emerg-ing platforms such as IoT and the cloud, which will, according to them,most likely dominate in the near future.

In [26], the author explores the service granularity aspect of MSA be-cause it may have a considerable impact on latency. This is becausemessage passing increases as the services become finer-grained, conse-quently also affecting the response time. This is why the optimal levelof granularity is of interest. The work also focuses on identification offactors affecting latency and response time. The author also discusseshow finer-grained services increase the number of in-process invoca-tions and if it is tolerated within same host or container. However,when requests are made to external services, additional vulnerabili-ties are introduced, i.e., by the network connection and the load on theservice. The author concludes that services co-existing within the samehost have better performance in comparison to service invocations toother hosts through network links.

Chapter 4

Research method

This chapter gives a comprehensive and scientific perspective of the re-search conducted. The chapter includes a description of the objective,the challenges, and the research question. The chapter also covers themethodology as well as the validity of the thesis.

4.1 Research objective

The overall objective of this thesis is to analyze the run-time impactwhen decomposing a monolithic architecture and adopting a decom-posed architectural style such as the MSA. To achieve this objective,numerous aspects and challenges must be considered, for instance, thesystem decomposition and the communication establishment betweenthe resulting services. Consideration of these factors should result in afair and comprehensive report.

4.2 Research challenges

One of the major challenges that were faced in this research has todo with decomposing an architecture and establishing communicationbetween resulting services

Targeting the challenges of system decomposition required inves-tigation of, among other things, components and how they are coor-dinated. Because the possibilities to decompose are numerous, espe-cially when it comes to component granularity, this thesis will onlyfocus on single business functionality. The selected functionality was

21

22 CHAPTER 4. RESEARCH METHOD

decomposed and tested at different granularity levels. The outcomeshould be applicable to a system as a whole since no constraints havebeen considered and because granularity levels and run-time impactswere the aspects focused.

The communication establishment was another significant challenge.As in the case of several loosely coupled services, the communicationestablishment plays a major role. There were many different protocolsand frameworks available for the communication. In this thesis, bothbinary and textual formats have been investigated. Another aspectconsidered regarding communication establishment is the location ofservices. They could be placed in different geographical places which,depending on the distance between them, would introduce latency. Itis an important aspect and cannot be forgotten. However, this thesishas been narrowed down and only considered local simulations.

4.3 Research question

Based on the challenges and previously conducted research, and tonarrow down the research to be conducted, the research question wasspecified.

• What is the impact on the system run-time behavior when de-composing a business functionality and adopting an architec-tural pattern such as MSA?

4.4 Scientific Perspective

The field of system architectural patterns and communications stylesis a broadly researched area, thereby, a large number of publicationsand research articles were evaluated. The previous evaluations con-sisted of statistical data, which required to make comparison amongthe alternating outcomes.

To answer the research question, a qualitative research techniquewas adopted as the most appropriate method. This is a form of re-search technique defined as being exploratory and with the ability toanswer the questions on why and how [10]. This approach has beendiscovered to be the most appropriate when it comes to interpretationof the information within the field of this study. However, because

CHAPTER 4. RESEARCH METHOD 23

a qualitative approach is not effective in analyzing statistical data, aquantitative research method was utilized. This method makes useof empirical study through the use of statistical means to investigateobservable phenomena [3]. Therefore, a combination of the two wasrequired to conduct this research.

4.5 Research methodology

The research methodology that was used to fulfill the objective of thisthesis is outlined in figure 4.1.

The research started with a project conducted together with an in-dustrial partner, IBM. The project was related to system complexityand identification of factors that has impact on the response time whenadopting decomposed architectural styles such as the MSA. By study-ing different literatures about different architectural styles and the adop-tion of decomposed architectural styles challenges were identified anda research question was formulated.

The literature review investigated the current state-of-the-art meth-ods, trends and their corresponding challenges. The research lookedat different architectural styles, decomposition patterns and differentways to establish communication. The limitations in research resourcesresulted in this thesis. To narrow down the scope of the thesis the deci-sion was made to only look at a sub-problem; the relationship betweengranularity level and system impact in terms of response time.

With the research question and its challenges specified, the nextphase was to propose a solution. Once again, major related workswere needed to be thoroughly studied in order to be able to implementand analyze their results.

The actual implementation and simulation were made as what canbe described as an iterative process. Drawbacks were found and ad-justments and refinement were made before re-implementation.

4.6 Validity

This section focuses on the test for validity of this research work andthe three different types of validity that were covered are constructvalidity, internal validity and conclusion validity.

24 CHAPTER 4. RESEARCH METHOD

4.6.1 Construct validity

Construct validity is achieved by an accurate representation of real-world scenarios through theoretical constructs. It is an indication ofhow well an experiment measures what it claims to do [52].

Construct validity is an important aspect to consider when vali-dating the developed environments. In this thesis, this validity wasused to examine different parameters along with their correspondingoutput to see if they follow expectations according to theory.

4.6.2 Internal validity

Internal validity is related to the presence of confounding variables - avariable that has not been taken into account and that has an effect ondependent variables. This validity affects the outcome by introducingbias and increasing variance [48].

This thesis conducted experiments through simulation of environ-ments with the ability to limit and change the number of parameters.This enabled experimenting with the parameters such as the numberof requests, parallel users and different communication protocols andmeasures their specific effect. Further actions could have been takensuch as investigating hardware specific parameters. However, that isa suggestion for future work. The actions that have been taken intoconsideration include capturing the effect of different parameters toreduce the chance of confounding variables and obtain high internalvalidity.

4.6.3 Conclusion validity

Conclusion validity is a measurement of the extent to which conclu-sions about relationships of variables are reasonable. This is stronglyrelated to the data collected and the analysis that was carried out onthem [51].

In the end, there are essentially two possible outcomes from thedata, one can either conclude a relationship or not. In the thesis, thishas been reflected through detailed measurement of different vari-ables, both dependent and independent, to reduce the chances of in-correct conclusions to be drawn. For this thesis, comments from re-searchers and engineers, with both academic and industrial background,have been taken into account in drawing the conclusions.

CHAPTER 4. RESEARCH METHOD 25

Figure 4.1: Research methodology.

Chapter 5

Implementation

This chapter gives an overview of how the implementation was car-ried out along with the frameworks used. The different phases andthe decision making within them are also clarified.

5.1 Granularity and communication

The selection of both communication patterns, and granularity levels(see figure 5.1 and 5.2) was a result of a pre-study. These choices had tofacilitate the analysis and conclusions necessary to fulfill the objectiveof the thesis.

Figure 5.1: Chosen communication patterns

Figure 5.2: Chosen granularity levels to implement

26

CHAPTER 5. IMPLEMENTATION 27

5.2 Modelling of the architectural cases

To achieve the objective of the thesis - investigating the run-time im-pact when decomposing an architecture into loosely coupled services- a scenario was modeled at different granularity levels. We modelleda business functionality within an e-commerce scenario, order place-ment to be specific. The functionality was not the essential aspect,the decomposition and communication patterns between the serviceswere subjects of consideration. The analysis and outcome should ap-ply to any business functionality regardless of the scenario. This is dueto the fact that no constraints or component-specific executions havebeen performed. We were only interested in the granularity level andthe communication establishment.

Modeling an e-commerce scenario is explained by the fact that thearchitectural components should be recognizable and self-explanatory,the same applied to the relations between the decomposed compo-nents.

The modeled architecture in figure 5.3 constitutes the base case - amonolithic architecture used as a reference point for comparisons withthe other decomposed architectures. As seen in figure 5.3, it consists ofa single service containing all of the core-logic, all of the functionalityis within the service and there is no external communication.

Figure 5.3: Monolithic architecture of order-placement

The second modeled architecture, as shown in figure 5.4, is a de-composed structure derived from the base case in figure 5.3. As seen

28 CHAPTER 5. IMPLEMENTATION

in the figure the inner functionality is divided into two cohesive ser-vices. To fulfill the initial order placement functionality, coordinationand communication among the loose services are required.

As visualized in both figure 5.4 and 5.5, the decomposed archi-tects consisting of more than one service utilize an API gateway. Thepurpose was to have a single unified entry point for the external con-sumers. It also creates an abstraction level and is independent of thenumber of internal services.

Figure 5.4: Decomposed architecture consisting of two services

The modeled architecture in figure 5.5 constitutes the most fine-grained case. All of the extracted services were required to place anorder, the difference, in comparison to previous examples, is that eachservice is accountable for less computation and its responsibility is nar-rowed down.

Modeling of architectures with granularity levels between the firstdepicted architecture in figure 5.4 and the second, figure 5.5, has beendone. The modeled granularity levels are two, four, six and eight.They all followed the logic of decomposing the previous architectureinto smaller cohesive services concerning business capabilities.

Relations between the services in figure 5.5 is depicted in figure5.6, it shows how the services coordinate internally and the flow ofmessages to execute the intended functionality.

CHAPTER 5. IMPLEMENTATION 29

Figure 5.5: Decomposed architecture consisting of eight services

Figure 5.6: Relations between services in figure 5.5

5.3 Implementation and realization

The various architectures that have been implemented were all mod-eled in section 5.2, all of which consisted of a varied number of ser-vices. The architectures and its corresponding services were all hostedthrough the Spring Boot framework - a Java-based framework for build-ing web and enterprise applications - using Java serverlets. To sumthings up, Java serverlets are a server-side program that runs inside aJava-capable server such as Apache Tomcat Server. Tomcat is essen-tially an open-source Java servlet container developed by the ApacheSoftware Foundation. The services were all implemented in Java, andas mentioned the utilized communication patterns were REST style

30 CHAPTER 5. IMPLEMENTATION

with HTTP and JSON, and Googles gRPC. The reason why other pat-terns such as Apache Kafka were not implemented was because theyare not suitable for the modeled case. The main scope of ApacheKafka is publish/subscribe systems, which is the opposite of the re-quest/response system that the modeled case was built upon.

The primary interest when decomposing a system lies in the run-time impact, an aspect that is hard to quantify since it is dependenton the functionality range as well as the size. The computation withina service could hypothetically be seen as a constant time, in this case,the computation time was neglected. Therefore, only communicationestablishment is considered which gave a more general result that ap-plies to other scenarios. Thereby, the implemented services only con-sisted of message passing logic.

The messages sent between the services consisted of an object inthe magnitude of five characters. Different size of the transmitted datamay be of interest. It could affect the serialization time, but previousresearch has already explored serialization/deserialization of differentsizes [49, 38]. Therefore, no consideration was made for the sending ofdifferent sizes of data. The choice of a consistent size of data providedreproducible observations. The format of a message sent between ser-vices is depicted in table 5.1.

Table 5.1: Format of data sent between servicesData

Name ( char(5) ) Msg ( char(5) )

In theory, a client could access each service directly through the re-spective endpoint. However, this option has its limitations, one of themain problems is the imbalance between the needs of the client and theenabled services. For instance, if a client wants to place an order, giventhat the system is constructed as the model in figure 5.3, the client hasto make eight separate requests to obtain the intended result. In morecomplex scenarios, for instance, when rendering a page that requiresseveral functionalities with each consisting multiple services, it wouldresult in a high number of requests. Over a LAN it is conceivable, butover the public Internet or a mobile network, it would be impractical.

Internally, the communication is established through a point-to-point style. The services will communicate directly without a gate-way mediator. This is due to the presence of the API gateway which

CHAPTER 5. IMPLEMENTATION 31

purpose is to handle external traffic. As mentioned, the two messag-ing patterns that were examined are REST style with HTTP and JSON,and also gRPC. Regardless of the internally established communica-tion, the functionality is accessed through an HTTP request returninga JSON object.

The communication established between the services using HTTPis depicted in figure 5.5. The communication is carried out throughinitialization of a TCP channel between the dedicated services. Thecalling service, also known as the client, sends an HTTP GET requestto the targeted service, the targeted service sends a response and closesthe TCP connection.

Worth mentioning is that the services are all hosted locally, thereby,the latency factor is neglected. However, it is possible to locate serviceson geographically distinct location. Hypothetically this would affectthe overall impact, in line with increasing granularity, the responsetime would increase. A distributed version of the implementation isplanned as future work.

Figure 5.7: Service communication with HTTP and JSON

The life cycle of a gRPC communication establishment is depictedin figure 5.6. There are different types of communication patternswhen using gRPC, in this case, the unary stream was implemented- the client sends a single request and gets back a single response.

Figure 5.8: Service communication with gRPC

32 CHAPTER 5. IMPLEMENTATION

5.4 Platform specification

The experiments were performed locally on a machine with an IntelDual-Core i5 running at 2.3 GHz and 8GB RAM. The machine ran onmacOS High Sierra version 10.13.4 operating system.

5.5 Measurement tool and parameters

The testing and gathering of results were performed with the use ofApache JMeter framework - an open source software for load testingfunctional behavior and measurement of performance. Jmeter enablesmeasurement of many different server/protocol types but for this spe-cific case, the HTTP protocol was used.

To fulfill the objective of the thesis - investigating the run-time im-pact when decomposing an architecture into loosely coupled services.Parameters to be tested were chosen and presented in the table below:

Table 5.2: Parameters for performance measurementParameter DescriptionSamples Total number of executions.

Internal requests Number of internal requests between thedecomposed services.

Average Average elapsed time.Min Minimum elapsed time.Max Maximum elapsed time.

90% Line 90% Percentile, is the value belowwhich 90% of the samples fall.

Standard Deviation A measure of how spread out numbers are.

Chapter 6

Results

This chapter presents the performance results from the experimentsconducted. The modeled and implemented architectures along withthe different communication patterns have been tested, and the resultsobtained are presented in tables.

6.1 Results from conducted experiments

The outputs for the different scenarios are all presented in tables 6.1-6.6 below. The first three tables, 6.1-6.3 display the behavior whenthe business functionality was tested with a load of ten requests. Thethree following tables, 6.4-6.6, shows the behavior of a load with onethousand requests.

The tables consist of output from both monolithic and decomposedarchitecture whereas the two communication styles REST and gRPChave been utilized.

Table 6.1: Monolithic architecture - 10 Requests

Services Samples 90% Line Avg(ms)

Min(ms)

Max(ms) Std. Dev.

1 10 5 3 2 7 1.57

33

34 CHAPTER 6. RESULTS

Table 6.2: Decomposed HTTP and JSON - 10 Requests

Services Samples Internalrequest

90%Line

Avg(ms)

Min(ms)

Max(ms)

Std.Dev.

2 10 1 10 9 7 20 3.554 10 3 16 16 11 39 9.346 10 5 28 26 22 72 9.218 10 7 51 48 44 102 17.59

Table 6.3: Decomposed with gRPC - 10 Requests

Services Samples Internalrequest

90%Line

Avg(ms)

Min(ms)

Max(ms)

Std.Dev.

2 10 1 5 4 2 7 1.034 10 3 8 6 5 17 2.966 10 5 15 12 9 24 5.218 10 7 15 14 11 41 5.41

As displayed in tables 6.1-6.3, the decomposition and the highergranularity affect the response time. With the use of eight serviceswithin the 90th percentile and using gRPC, the penalty compared to themonolithic scenario was measured to be 10ms. With the use of REST,the penalty was recorded to be 46ms. The most interesting change inbehavior is when the services were further decomposed from four tosix and with three to five internal requests, the run-time almost dou-bled. This major difference can be seen for both gRPC and REST.

Table 6.4: Monolithic architecture - 1000 Requests

Services Samples 90% Line Avg(ms)

Min(ms)

Max(ms) Std. Dev.

1 1000 2 1 <1 11 0.79

CHAPTER 6. RESULTS 35

Table 6.5: Decomposed HTTP and JSON - 1000 Requests

Services Samples Internalrequest

90%Line

Avg(ms)

Min(ms)

Max(ms)

Std.Dev.

2 1000 1 8 6 4 40 1.704 1000 3 13 10 7 80 3.546 1000 5 46 35 16 158 11.698 1000 7 58 64 39 364 22.19

Table 6.6: Decomposed with gRPC - 1000 Requests

Services Samples Internalrequest

90%Line

Avg(ms)

Min(ms)

Max(ms)

Std.Dev.

2 1000 1 4 2 1 18 1.224 1000 3 6 3 2 37 1.796 1000 5 14 10 4 74 7.828 1000 7 15 9 5 129 6.03

Tables 6.4-6.6 show that the penalty within the 90th percentile forthe different granularity levels are similar to the scenario of a load withten requests. Once again, it can be seen that, when going from fourto six services, and three to five internal requests, there is a biggerdifference in run-time in-comparison to between the other levels.

However, one can also interpret higher maximum and lower mini-mum response-time. This could most likely have been improved withsome form of scaling, that is replication of services and distribution ofload.

By looking at the two tested scenarios, loads of ten and a thousandrequests, it can be deduced that usage of gRPC, in comparison to REST,performed more than three times better. It can be seen that more thanfour services and three internal requests have an impact on the out-come greater than among the other steps. It is also important to clarifythat these numbers only display the impact of response-time, whichis a negative impact. However, it must be noted that higher granu-larity improves other non-functional parameters, more about this isdiscussed in the conclusions at chapter 7.

Chapter 7

Conclusion

7.1 Discussion

This thesis empirically shows that the decomposition of a businessfunctionality indeed does impact the run-time negatively - an impactthat increases in line with the granularity level. However, using thisas a basis for not using a decomposed architecture is misleading.

First of all, to what extent does decomposition of business func-tionality impact the run-time? In the tables at section 6.1, the impactoutlined for different granularity levels can be seen. It is possible toconfirm that Google’s gRPC performs better than the REST-style withHTTP and JSON, this has been confirmed by previous works as statedin chapter 3.

The result shows that the gRPC performed better in-comparison toREST with HTTP and JSON. Therefore, it can be argued that amongthe examined communication patterns and with the use of run-time asthe deciding aspect, gRPC is preferable.

Comparing the run-time between the monolithic and the decom-posed architecture displays differences that can be seen as relativelysmall, of course, the magnitude is relative, and it depends on the con-text. However, it is possible to reckon that the penalty with the usageof gRPC, within the 90th percentile and with a granularity of eight ser-vices, is 10ms. Simultaneously, usage of REST gives a penalty of 46ms.To make sense of these numbers, they can be related to how the webbehaves today. The HTTP Archive - an archive storing data crawlingfrom the most popular sites - shows that the time for onLoad - load-ing resources and its dependent resources - within the 90th percentile

36

CHAPTER 7. CONCLUSION 37

is measured to be 16.3 seconds on a desktop and 42.3 seconds on mo-bile. Therefore, the observed delay with the use of gRPC is 0.06% onmobile and 0.02% on desktop, and with the usage of REST the delay is0.02% on mobile 0.01% on desktop. In non time critical scenarios thisis acceptable. That these numbers are exclusively from monolithic ar-chitectures cannot be concluded. However, they give a fair indicationof how the web behaves and enables putting the generated result in acontext. [2, 12, 27]

Based on the results obtained, it can be concluded that when goingfrom four to six services, and three to five internal requests, the run-time impact almost doubled. Which is not the case between the othergranularity levels. This behavior turns out to be true for both of theconducted load tests, both ten and a thousand requests gave a specialrun-time impact. From this, we can interpret that there seems to besome kind of threshold that impacts the run-time more severely. Pos-sibly due to the communication establishment, the initially requestedservice calls other services and has to await response, and this showsthat there seems to be a more negative impact when there is a line ofmore than four services.

As highlighted, the time penalty is relatively small, however, if asystem constitutes of multiple functionalities where all of them are de-composed into high granularity levels, then the accumulated impactcould indeed be of concern. It is also important to acknowledge thatin some cases one might have performance requirements to consider,depending on how they are devised, and if the run-time is to be be-low some strict limit then decomposition might not be possible. Onceagain, this observation is solely dependent on the context. In scenarioswhere the business functionality cannot be decomposed into such highgranularity levels and the system does not consist of so many function-alities, the overall run-time impact will be relatively small and possiblyaccepted in exchange for the benefits that a decomposed architectureentail.

As mentioned, the choice of applying decomposed architecture likeMSA may not solely lie upon run-time impact. There are cases wherethe effect is accepted in exchange for, for example, faster developmentcycles and better re-usability. Consider working with a monolithic ar-chitecture where the team is divided based upon business functional-ity, if a new feature or a fix was to be released they must rebuild andredeploy the whole system. This means that time must be spent on co-

38 CHAPTER 7. CONCLUSION

ordination among all teams and in some cases correction of other partsthat are necessary for the system to perform. When utilizing MSA andits loosely coupled services, this is not the case. Services can be re-built and redeployed independently, the only coordination required isensuring that endpoints and data consumed by other services are notdeprecated. Another essential difference between decomposed andmonolithic architecture is the ability to scale. Scaling a monolithic ar-chitecture is done through vertical scaling where more computationalpower is added. When compared to a decomposed architecture wherethere can be scaling of some specific components and placing thembehind a load balancer, it would be discovered that the decomposedarchitecture is better. With this being said, the run-time impact is in-deed of interest, but there are other aspects that must be considered.

7.2 Recommendation

With respect to the discussion above and the support of run-time be-havior for the different granularity levels, the outcome is that decom-posed architectural style is recommended. As concluded, decomposedarchitecture does affect the run-time negatively, but as discussed, themagnitude is small relative to its context and to how the web behaves.Furthermore, based upon the results obtained, a business functional-ity should not be decomposed into higher granularity level than fourservices, this is due to the fact that it seems to be a threshold, furtherdecomposition impacts the run-time more severely. A decomposedsystem will most likely results in far more than four services, but asingle business functionality could give unwanted impact on the run-time when further decomposed.

As long as the use case does not have any strict requirements re-garding the run-time, making it an exclusive decision making factor,then decomposed styles have advantages that make it preferable suchas better scaling capabilities and more maintainable code bases.

As also mentioned in the discussion, decomposed architecture withloosely coupled services gives development teams the the ability to in-dependently rebuild and redeploy features and fixes. If this is not al-lowed, the time needed in coordinating would be very time-consuming.

However, it is important to point out that the choice taken is alwaysa trade-off which is dependent on the use case. Many of the mentioned

CHAPTER 7. CONCLUSION 39

advantages may be preferable, but the system impact should not beforgotten. In any case, this thesis provides a basis for predicting therun-time impact in correlation to the granularity level.

7.3 Sustainability

The whole idea of adopting the microservice architectural style is toimprove software architecture. We can all agree on the fact that mono-lithic architectural styles are not sustainable. As it is today, our systemgrows, resulting in the need for scaling. In the case of a monolithic ar-chitectural style, the scaling is carried out either through vertical scal-ing where more computational power is added or through duplicationof the whole system, which is later placed behind a load-balancer todistribute the load.

None of these approaches scales the parts that really need it. Themicroservice architecture can drastically improve on this when scalingis needed, one will be able to scale a specific service. As a result of this,an approach that is both cost-effective and minimizes energy demandis needed.

Implementation of the microservice architectural style results in in-dependent and sustainable services. Considering the case when newregulations arise and require reconstruction of current systems. If amonolithic architectural style has been adopted then the reconstruc-tion may be, if even possible, a tedious task. In the worst case, largeportions must be rebuilt from scratch because of all the interdepen-dencies. However, in the case of a microservice architectural style, oneonly need to rework the parts concerned, independently from the restof the system. Therefore, the microservice architectural style indeedresults in a more sustainable and scalable architectural style.

7.4 Future work

Decomposed architectural styles such as the MSA is very promisingand likely to be a favorable choice when developing new systems. Inmy opinion after completing this thesis, in line with the growing IT-sector and the increasingly digitized world, architectural styles will beof more vital importance.

40 CHAPTER 7. CONCLUSION

However, before we see a more extensive usage of MSA in specific,I believe that more research within the field must be performed. Asmentioned earlier, there is no formal definition of the term MSA yet[20, 36], it is imperative to come up with a standardized and gener-ally accepted definition for the term. While this thesis has contributedby giving support of the behavior of decomposition and adoption ofhigher granularity levels, the tests could have also examined otherenvironments including services located in geographically differentplaces. Future studies could, for instance, examine different hostingalternatives and cloud services providers. Other hosting alternativescould be utilized and give comprehensive support to the behaviorwhich may be different from the support provided by the local host.

Bibliography

[1] S. J. Andriole. “The Death of Big Software”. In: ACM Journal of

Data and Information Quality 60.12 (2017).

[2] HTTP Archive. Loading Speed. 2018. URL: https://httparchive.org/reports/loading-speed.

[3] E. Babbie. “The Practice of Social Research.” In: (2012). URL: https://books.google.se/books?hl=sv&lr=&id=bS9BBAAAQBAJ&oi=fnd&pg=PR5&ots=Pwp6cKwrK3&sig=tjsH9udnSJOGM226oLYqRPwWZhE&redir_esc=y#v=onepage&q&f=false.

[4] W. Bai, S. Liu, and Z. Yao. “Research of stateful Web Services im-plementation based on workflow”. In: The 2nd International Con-

ference on Information Science and Engineering. Dec. 2010, pp. 1–4.

[5] A. Balalaie, A. Heydarnoori, and P. Jamshidi. “Microservices Ar-chitecture Enables DevOps: Migration to a Cloud-Native Archi-tecture”. In: IEEE Software 33.3 (2016), pp. 42–52.

[6] L. Baresi, M. Garriga, and A. De Renzis. “Microservices Iden-tification Through Interface Analysis”. In: Service-Oriented and

Cloud Computing. Springer International Publishing, 2017, pp. 19–33.

[7] T. R. Browning. “Applying the design structure matrix to systemdecomposition and integration problems: a review and new di-rections”. In: IEEE Transactions on Engineering Management 48.3(Aug. 2001), pp. 292–306.

[8] K. J. Clark. Microservices, SOA, and APIs: Friends or enemies? 2016.URL: https://www.ibm.com/developerworks/websphere/library/techarticles/1601_clark-trs/1601_clark.html.

41

42 BIBLIOGRAPHY

[9] C. De la Torre et al. Designing a DDD-oriented microservice. 2017.URL: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice.

[10] N. Denzin and Y. Lincoln. “The Sage handbook of qualitativeresearch”. In: (2005). URL: https://books.google.se/books?hl=sv&lr=&id=AIRpMHgBYqIC&oi=fnd&pg=PP1&dq=The+Sage+handbook+of+qualitative+re-+search.&ots=koBRDDiuod&sig=8p_1HrtUieL0jQE9N8pkLqa_fj4&redir_esc=y#v=onepage&q=The%5C%20Sage%5C%20handbook%5C%20of%5C%20qualitative%5C%20re-%5C%20search.&f=false.

[11] Google Developers. Developer Guide - Protocol Buffers. URL: https://developers.google.com/protocol-buffers/docs/overview.

[12] MDN web docs. load. 2018. URL: https://developer.mozilla.org/en-US/docs/Web/Events/load.

[13] gRPC Documentation. What is gRPC? 2017. URL: https : / /grpc.io/docs/guides/.

[14] JSON Documentation. Introducing JSON. URL: https://json.org/.

[15] N. Dragoni et al. “Microservices: How To Make Your Applica-tion Scale”. In: A.P. Ershov Informatics Conferenc (2017).

[16] N. Dragoni et al. “Microservices: yesterday, today, and tomor-row”. In: Present And Ulterior Software Engineering (2016).

[17] E. Evans. Domain-driven design. Addison-Wesley, 2014.

[18] Roy T. Fielding and Richard N. Taylor. “Principled Design of theModern Web Architecture”. In: ACM Trans. Internet Technol. 2.2(May 2002), pp. 115–150.

[19] Apache Software Foundation. Intro. 2017. URL: https://kafka.apache.org/intro.

[20] M. Fowler and J. Lewis. Microservices: a definition of this new ar-

chitectural term. 2014. URL: http : / / martinfowler . com /articles/microservices.html.

[21] S. Fowler. Production-ready Microservices. O’Reilly Media, 2016.Chap. 4.

BIBLIOGRAPHY 43

[22] Benjamin Götz et al. “Challenges of Production Microservices”.In: Procedia CIRP 67 (2018), pp. 167–172. ISSN: 2212-8271. DOI:https : / / doi . org / 10 . 1016 / j . procir . 2017 . 12 .194. URL: http://www.sciencedirect.com/science/article/pii/S2212827117311381.

[23] D. Harris. Talking microservices with the man who made Netflix’s

cloud famous. 2015. URL: https://medium.com/s-c-a-l-e/talking-microservices-with-the-man-who-made-netflix-s-cloud-famous-1032689afed3.

[24] S. Hassan, N. Ali, and R. Bahsoon. “Microservice Ambients: AnArchitectural Meta-Modelling Approach for Microservice Gran-ularity”. In: 2017 IEEE International Conference on Software Archi-

tecture (ICSA). Apr. 2017, pp. 1–10.

[25] S. Hassan and R. Bahsoon. “Microservices and Their Design Trade-Offs: A Self-Adaptive Roadmap”. In: 2016 IEEE International Con-

ference on Services Computing (SCC). June 2016, pp. 813–818.

[26] D. Shadija M. Rezai Hill, R. Microservices: Granularity vs. Perfor-

mance. 2017.

[27] Alexa Internet. The top sites on the web. 2018. URL: https://www.alexa.com/topsites.

[28] U. Kalex. Business Capability Management: Your Key to the Busi-

ness Board Room. 2011. URL: http://www.opengroup.org/johannesburg2011/Ulrich%5C%20Kalex%5C%20-%5C%20Business%5C%20Capability%5C%20Management.pdf.

[29] A. Krammer et al. “Granularity of Services”. In: Business & In-

formation Systems Engineering 3.6 (Dec. 2011), pp. 345–358. URL:https://doi.org/10.1007/s12599-011-0189-x.

[30] A. Levcovitz, R. Terra, and M. Tulio Valente. “Towards a Tech-nique for Extracting Microservices from Monolithic EnterpriseSystems”. In: CoRR (2016).

[31] C. Matthew MacKenzie et al. Reference Model for Service Oriented

Architecture 1.0. OASIS, 2006.

[32] K. Mikhail et al. “Domain Objects and Microservices for Sys-tems Development: A Roadmap”. In: Proceedings of 5th Interna-

tional Conference in Software Engineering for Defence Applications.Springer International Publishing, 2017, pp. 97–107.

44 BIBLIOGRAPHY

[33] I. Miri. Microservices vs. SOA. 2017. URL: https://dzone.com/articles/microservices-vs-soa-2.

[34] A. Morrison. Moving away from the monolith. 2015. URL: http://usblogs.pwc.com/emerging-technology/agile-coding-in-enterprise-it-code-small-and-local/.

[35] O. Mustafa and J. Marx Gomez. Optimizing economics of microser-

vices by planning for granularity leve. Apr. 2017.

[36] S. Newman. Building microservices. O’Reilly Media, 2015.

[37] M. P. Papazoglou and W-J. van den Heuvel. “Service orientedarchitectures: approaches, technologies and research issues”. In:Springer-Verlag (2007).

[38] S. Popic et al. “Performance evaluation of using Protocol Buffersin the Internet of Things communication”. In: 2016 International

Conference on Smart Systems and Technologies (SST). Oct. 2016, pp. 261–265.

[39] F. Rademacher, S. Sachweh, and A. Zündorf. “Differences be-tween Model-Driven Development of Service-Oriented and Mi-croservice Architecture”. In: 2017 IEEE International Conference on

Software Architecture Workshops (ICSAW). Apr. 2017, pp. 38–45.

[40] M. Richards. Microservices vs. Service- Oriented Architecture. O’ReillyMedia, 2016.

[41] C. Richardson. Microservices: Decomposing Applications for Deploy-

ability and Scalability. 2014. URL: https://www.infoq.com/articles/microservices-intro.

[42] C. Richardson. Pattern: Decompose by business capability Context.2017. URL: http://microservices.io/patterns/decomposition/decompose-by-business-capability.html.

[43] C. Richardson. Pattern: Monolithic Architecture Context. 2017. URL:http://microservices.io/patterns/monolithic.html.

[44] Chris Richardson. Pattern: Saga. 2017. URL: https://grpc.io/docs/guides/.

[45] M.-T. Schmidt, B. Hutchison, and R. P. Lambros P.and Phippen.“The Enterprise Service Bus: Making service-oriented architec-ture real”. In: IBM SYSTEMS 44.2 (2005).

BIBLIOGRAPHY 45

[46] D. Sprott and L. Wilkes. Understanding Service-Oriented Architec-

ture. 2004. URL: https://msdn.microsoft.com/en-us/library/aa480021.aspx.

[47] J. Stenberg. Using Domain-Driven Design When Creating Microser-

vices. 2016. URL: https://www.infoq.com/news/2016/02/ddd-microservices.

[48] G. Stephanie. “What is Internal Validity?” In: (2014). URL: http://www.statisticshowto.com/internal-validity/.

[49] Audie Sumaray and S. Kami Makki. “A Comparison of DataSerialization Formats for Optimal Efficiency on a Mobile Plat-form”. In: Proceedings of the 6th International Conference on Ubiq-

uitous Information Management and Communication. ICUIMC ’12.ACM, 2012, 48:1–48:6. URL: http : / / doi . acm . org / 10 .1145/2184751.2184810.

[50] J. Thones. “Microservices”. In: IEEE SOFTWARE (2015).

[51] William M.K. Trochim. “Conclusion Validity”. In: (2006). URL:https://socialresearchmethods.net/kb/concval.php.

[52] William M.K. Trochim. Construct Validity. 2002. URL: http://www.indiana.edu/~educy520/sec5982/week_3/construct_validity_trochim.pdf.

TRITA EECS-EX-2018:636

www.kth.se