Architectural Patterns for Microservices: A Systematic Mapping Study

Davide Taibi

, Valentina Lenarduzzi

and Claus Pahl

Tampere University of Technology, Tampere, Finland

Free University of Bozen-Bolzano, Bozen-Bolzano, Italy

Keywords:

Microservices, Architectural Style, Architecture Pattern, Cloud Native, Cloud Migration, DevOps.

Abstract:

Microservices is an architectural style increasing in popularity. However, there is still a lack of understanding

how to adopt a microservice-based architectural style. We aim at characterizing different microservice archi-

tectural style patterns and the principles that guide their deﬁnition. We conducted a systematic mapping study

in order to identify reported usage of microservices and based on these use cases extract common patterns and

principles. We present two key contributions. Firstly, we identiﬁed several agreed microservice architecture

patterns that seem widely adopted and reported in the case studies identiﬁed. Secondly, we presented these as

a catalogue in a common template format including a summary of the advantages, disadvantages, and lessons

learned for each pattern from the case studies. We can conclude that different architecture patterns emerge for

different migration, orchestration, storage and deployment settings for a set of agreed principles.

1 INTRODUCTION

Microservices are increasing their popularity in in-

dustry, being adopted by several big players such as

Netﬂix, Spotify, Amazon and many others and sev-

eral companies are now following the trend, migrating

their systems to microservices. However companies

still have the issues of selecting the most appropriate

architectural patterns, mainly because of the lack of

knowledge about the available patterns (Taibi et al.,

2017).

Microservices are small autonomous services de-

ployed independently, with a single and clearly de-

ﬁned purpose (Lewis and Fowler, 2014). Their in-

dependent deployability is advantageous for contin-

uous delivery. They can scale independently from

other services, and they can be deployed on the hard-

ware that best suits their needs. Moreover, because of

their size, they are easier to maintain and more fault-

tolerant since the failure of one service will not break

the whole system, which could happen in a mono-

lithic system (Lewis and Fowler, 2014). Microser-

vices have emerged as a variant of service-oriented

architecture (SOA). Their aim is to structure software

systems as sets of small services that are deployable

on a different platform and running in their own pro-

cess while communicating with each other through

lightweight mechanisms without a need for central-

ized control (Pahl et al., 2018). We consider an archi-

tectural style here as a set of principles and coarse-

grained patterns that provide an abstract framework

for a family of systems. An architectural style con-

sists of a set of architectural principles and patterns

that are aligned with each other to make designs rec-

ognizable and design activities repeatable: principles

express architectural design intent; patterns adhere to

the principles and are commonly occurring (proven)

in practice (Zimmermann, 2009).

Microservices enable continuous development

and delivery (Pahl et al., 2018). DevOps is the inte-

gration of Development and Operations that include a

set of continuous delivery practices aimed at decrease

the delivery time, increasing the delivery efﬁciency

and reducing time among releases while maintaining

software quality. It combines software development,

quality assurance, and operations (Bass et al., 2015).

Despite both microservices and DevOps being

widely used, there are still challenges in understand-

ing how to construct such kinds of architectures (Bal-

alaie et al., 2016), (Taibi and Lenarduzzi, 2018) and

developers often adopt the patterns where they can

ﬁnd more documentation online (Taibi et al., 2017),

even if they are not the most appropriate ones. In

order to help developers to identify the most appro-

priate patterns, we aim here to identify and charac-

terize different microservice architecture patterns re-

ported in the literature, be that as proposals and or

as case studies with implementations. The identiﬁ-

Taibi, D., Lenarduzzi, V. and Pahl, C.

Architectural Patterns for Microservices: A Systematic Mapping Study.

DOI: 10.5220/0006798302210232

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 221-232

ISBN: 978-989-758-295-0

221

cation process is supported by a systematic mapping

study (Petersen et al., 2008). A previous systematic

mapping (Pahl and Jamshidi, 2016) has aimed at clas-

sifying and comparing the existing research body on

microservices including non peer-reviewed content,

while a recent work with a similar goal has been pub-

lished by (Malavolta and Lago, 2017). Our study dif-

fers in the following ways:

• Focus: We focus on suggested architectural style

deﬁnitions, emerging patterns, while (Pahl and

Jamshidi, 2016) initially characterized the body of

research and (Malavolta and Lago, 2017) focused

on the potential for industrial adoption. The cen-

tral new aspect here is on an exploration of archi-

tecture patterns for a set of agreed principles.

• Systematic Approach and Comprehensiveness:

We conducted a systematic mapping study imple-

menting the protocol (Petersen et al., 2008), fol-

lowed by a systematic snowballing process, in-

cluding all references found in the papers. We

included results from 8 bibliographic sources.

The contribution of our study is as follows: We iden-

tify and describe microservice architecture patterns

as a pattern catalogue, thus analysing advantages and

disadvantages of the different patterns based on their

implementations. These patterns aim to support de-

velopers in ﬁnding suitable solution templates for ar-

chitecting microservices-based software. As this is a

still developing domain, we also discuss our ﬁndings

in the context of wider research gaps and trends. Fur-

thermore, we speciﬁcally address cloud computing as

the key application environment.

The paper is structured as follows. Section 2 de-

scribes our pattern identiﬁcation methodology. Sec-

tion 3 shows the pattern catalogue, which is discussed

in Section 4. Section 5 contains our conclusions.

2 PATTERN IDENTIFICATION

PROCESS

We used a literature review protocol (Petersen et al.,

2008) in combination with a systematic snowballing

process to detemine the patterns from the published

literature (Wohlin, 2014). We deﬁne our research

goal as follows: Analyze the architectural style pro-

posals for the purpose of comparing them and related

implementations with respect to their advantages and

disadvantages in the context of cloud-native software

implementation. We derived two research questions:

• RQ1: Which are the different microservices-

based architecture patterns?

• RQ2: Which advantages and disadvantages have

been highlighted for these patterns?

We used eight bibliographic sources: ACM Dig-

ital Library, IEEE Xplore Digital Library, Science Di-

rect, Scopus, Google Scholar, Citeeser library, Inspec

and Springer Link. We deﬁned the search strings

based on the PICO terms of our questions (Kitchen-

ham and Charters, 2007) using only the terms Popula-

tion and Intervention. We applied the following query

for the discovery of pattern descriptions:

(microservice* OR micro-service*) AND (architect*

OR migrat* OR modern* OR reengineer* OR

re-engineer* OR refactor* OR re-factor* OR

rearchitect* OR re-architect* OR evol*)

The symbol * allow capturing possible variations in

search terms such as plural and verb conjugation.

We selected considering the following criteria:

• General Criteria: We only included papers in En-

glish. However, we also considered non peer-

reviewed contributions if their number of citations

was higher than those of average peer-reviewed

papers.

• Selection by Title and Abstract: We removed all

papers that do not contain any references to mi-

croservices or that use the term microservices for

different purposes or in different domains.

• Selection by full papers: We excluded papers that

do not present any evidence related to our research

questions or papers using microservices without

any clear reference to the adopted architectural

style, and microservices-based implementations

that do not report any advantages and disadvan-

tages of using microservices. We considered pro-

posals of microservices-based architectural styles,

implementations of microservices-based cloud

systems, migrations of monolithic systems into

cloud-native microservices-based systems, papers

reporting their advantages and disadvantages.

We retrieved a total of 2754 unique papers ap-

plying the two queries to any ﬁelds. Based on the

inclusion and exclusion criteria applied to title and

abstract, we selected 85 papers. In order to vali-

date the process, each author randomly and separately

applied the inclusion and exclusion criteria to a set

of 10 retrieved papers. Pairwise inter-rater reliabil-

ity was measured across the three decision sets in

order to get a fair/good agreement in the ﬁrst pro-

cess iteration. This process was carried out to clar-

ify, where necessary, any incongruity among the au-

thors. At this stage, we conducted a forward and

backward systematic snowballing process among all

papers referenced in the 85 papers elicited, so as to

obtain a more comprehensive set of papers, as sug-

gested by Wohlin (Wohlin, 2014). As for backward

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

222

snowballing, we included all the references in the pa-

pers retrieved from bibliographic sources while for

the forward snowballing we included all the papers

that reference the retrieved papers, thereby obtaining

858 adidtional papers. After sifting these 858 papers

based on title and abstract, we included resulting in 12

additional papers, obtaining a total of 97 papers. After

reading the 97 papers, the process resulted in 40 peer-

reviewed papers and 2 non peer-reviewed ones. The

two works by Lewis and Fowler ([S1] and Richard-

son [S2]) added from the gray literature have a dra-

matically high number of citations compared to the

remaining works. Note that the patterns presented at

http://microservices.io/patterns/index.html are com-

piled by Richardson and were considered based on

his comments in [S2] and selected study [S2].

The selection resulted in 42 accepted papers pub-

lished up to end of 2016. 27 of these papers were pub-

lished at conferences, while another 10 papers were

accepted at workshops. Only 3 papers were published

as journal articles, and 2 papers are non peer-reviewed

websites (gray literature).

Figure 1: The chronological overview of the selected pa-

pers.

Figure 2: The publication types of the selected papers.

3 THE PATTERN CATALOGUE

A key role in the microservices architectural style

play the architecture patterns. Thus, we determine

key patterns with their advantages and disadvantages.

Three commonly used patterns emerge. In this classi-

ﬁcation, we attribute to the different patterns both the

papers explicitly reporting the usage of a speciﬁc style

and those where the adopted patterns can be clearly

deduced from the description. Please note that we re-

port on patterns in three subsections that categorize

the emerging architecture patterns:

• Orchestration and Coordination-oriented archi-

tecture patterns that capture communication and

coordination from a logical perspective.

• Patterns reﬂecting physical Deployment strategies

for microservices on hosts through containers or

virtual machines.

• Patterns that reﬂect on data management, specif-

ically Data Storage options in addition to the or-

chestration and coordination patterns oriented at

inter-component communication.

We will use a Concept, Origin, Goal, Properties, Evo-

lution, Reported Usage and Advantages, Disadvan-

tages template to discuss these microservices archi-

tecture patterns.

3.1 Orchestration and Coordination

Architecture Patterns

3.1.1 Service Composition - The API-Gateway

Pattern

Concept: Microservices can provide their functions

to other services through an API. However, the cre-

ation of end-user applications based on the composi-

tion of different microservices requires a server-side

aggregation mechanism. In the selected works, the

API-Gateway emerged as a commonly recommended

approach (Figure 3).

API Gateway is the entry point of the system

that routes the requests to the appropriate microser-

vices, also invoking multiple microservices and ag-

gregating results. It provides a tailored API to each

client to route requests, transform protocols, and im-

plement shared logic like authentication and rate-

limiters. Moreover, it can be responsible for different

tasks such as authentication, monitoring, and static re-

sponse handling. In some cases, the API Gateway can

also serve as load balancer since it knows the location

and the addresses of all services.

Origin: The API-Gateway is a pattern that resem-

bles more SOA principles than REST ones, without

an Enterprise Service Bus (ESB).

Goal: The main goal is to increase system per-

formance and simplify interactions, thus reducing the

number of requests per client. It acts as an entry point

Shopping(

Cart

Product(

Catalog

Recommender(

System

API

Gatweay

Client-

Specific(

APIs

Protocol(

Transla tion

Figure 3: The API-Gateway Architecture Pattern.

Architectural Patterns for Microservices: A Systematic Mapping Study

223

Table 1: The Papers Selection Process.

Selection Process #considered

papers

#rejected

papers

Validation

Paper extracted from the bibli-

ographic sources

2754 10 random papers independently classiﬁed

by three researchers

Sift based on title and abstract 2669 Good inter-rater agreement on ﬁrst sift (K-

statistic test)

Primary papers identiﬁed 85

Secondary papers inclusion 858 855 Systematic snowballing (Wohlin, 2014) in-

cluding all the citations reported in the 85

primary papers and sifting them based on

title and abstract

Full papers considered for re-

view

88 Each paper has been read completely by

two researchers and 858 secondary papers

were identiﬁed from references

Sift based on full reading 46 Papers rejected based on inclusion and ex-

clusion criteria

Relevant papers included 42

for the clients, routing their requests to the connected

services, aggregating the required contents, and serv-

ing them to the clients [S2].

Properties: The API-Gateway does not provide

support for publishing, promoting, or administering

services at any signiﬁcant level. However, it is re-

sponsible for the generation of customized APIs for

each platform and for optimizing communications be-

tween the clients and the application, encapsulating

the microservices details. It allows microservices to

evolve without inﬂuencing the clients. As an exam-

ple, merging or partitioning two or more microser-

vices only requires updating the API-Gateway to re-

ﬂect the changes to any connected client. In Figure

3, the API-Gateway is responsible for communicat-

ing with the different front-ends, creating a custom

API for each client for them to see only the features

they need, which simpliﬁes the creation of end-user

applications without adding the complexity of expos-

ing and parsing useless information.

Evolution and Reported Usage: This is the ﬁrst ar-

chitectural pattern reported in the considered works,

and was named API-Gateway by Richardson [S2].

Ten works implemented cloud-native applications

based on the pattern [S2], [S3], [S11], [S12], [S14],

[S21], [S31], [S34], [S37] and [S39] reporting several

API-Gateway speciﬁc advantages:

• Ease of Extension. Because the pattern can pro-

vide custom APIs, implementing new features is

easier compared to other architectures [S14],[S3].

• Market-centric Architecture. Services can be eas-

ily modiﬁed, based on market needs, without the

need to modify the whole system [S14].

• Backward Compatibility. The gateway guarantees

for evolving services that existing clients are not

hampered by interface endpoint changes [S34].

However, disadvantages have also been observed:

• Potential Bottleneck. The gateway layer is a sin-

gle entry point for all requests. If not designed

correctly, it could be a bottleneck [S14], [S39].

• Implementation complexity. The gateway layer

increases the complexity since it requires imple-

mentation of several interfaces for each service

[S14], [S34].

• API reuse must be considered carefully. Since

each client can have a custom API, we must keep

track of cases where different types of clients use

the same API and modify both of them accord-

ingly for changes to the API [S34].

• Scalability. When the number of microservices in

a system explodes, a more efﬁcient and scalable

routing mechanism to route the trafﬁc through

the services APIs, and better conﬁguration man-

agement to dynamically conﬁgurate and apply

changes to the system will be needed [S37].

3.1.2 Service Discovery Patterns

Multiple instances of the same microservice usually

run in different virtualized containers/VMs. The

communication among them must be dynamically

deﬁned and the clients must be able to efﬁciently

communicate to the appropriate microservice that

dynamically change instances. For this purpose, the

service discovery dynamically supports the resolu-

tion of DNS address into IP addresses. Richardson

proposes to differentiate between client-side and

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

224

server-side patterns [S2].

The Client-side Discovery Pattern. Concept: Here,

clients query the Service Registry, select an available

instance, and make a request directly (Fig. 4).

Shop.&Cart

Instance(1

Service&1

REST&

API

Registry&

Client

REST&

API

Registry&

Client

REST&

API

Registry&

Client

Shop.&Cart

Instance(2

Shop.&Cart

Instance(3

Service(

Registry

Registry-

aware&

client

Figure 4: The Client-side Service Registry Pattern.

Goal: With the client-side service discovery, the

client is responsible for picking one of the available

services instances to their network locations loca-

tions. Moreover, the service discovery can also serve

as load balancer of the requests. The client queries a

service registry, which is a database of available ser-

vice instances. The client then uses a load-balancing

algorithm to select one of the available service in-

stances and makes a request.

Evolution and Reported Usage: According to

Richardson, the main advantage of this pattern is

connected to the ease of development. The clients are

aware of the service instance locations and therefore

can connect directly to them without adding the

development complexity of the server-side discovery.

The main reported disadvantage is the high coupling

between the client and the service registry.

The Server-side Discovery Pattern.

In this pattern, clients make requests via a load

balancer, which queries the registry and forwards the

request to an available instance.

Goal: Unlike the API-Gateway pattern, this pat-

tern allows clients and microservices to talk to each

other directly. It relies on a Service Registry, see Fig-

ure 5, acting in a similar manner as a DNS server.

Properties: The Service Registry knows the dy-

namic location of each microservice instance. When

a client requests access to a speciﬁc service, it ﬁrst

asks the registry for the service location; the reg-

istry contacts the microservice to ensure its availabil-

ity and forwards the location (usually IP address or

DNS name and port) to the calling client. Finally,

unlike in the API-Gateway, clients communicate di-

rectly with the required services and access all avail-

able APIs exposed by the service, without any ﬁlter

or service interface translation.

Evolution and Reported Usage: Eleven papers im-

plemented this pattern. Ten fully use it [S25], [S13],

[S9], [S10], [S24], [S26], [S16], [S30] and [S38]

while [S23] proposes a variant, implementing the reg-

istry through a NoSQL database. [S36] report a par-

tial migration where a legacy SOA system provided

some services in connection with new microservices.

In this case, the legacy system was accessed like any

other microservice. The Service Registry contained

the addresses of all microservices and services pro-

vided by the legacy system.

This architectural pattern has several advantages:

• Increased Maintainability. All papers reported an

increased maintainability.

• Ease of Communication. Services can communi-

cate with each others directly, without interpreta-

tion [S25], [S36].

• Health Management. Resilience and scalability

mechanisms provide ”health management” and an

out-scaling for atomic/composed service [S7].

• Failure Safety. In the case of failure, microser-

vices can be easily restarted, due to their stateless

properties [S7].

• Software Understandability. Better under-

standibility through small services is reported

[S1], [S2].

• Ease of Development. Equally, easier develop-

ment results from smaller services [S1], [S2].

• Ease of Migration. Existing services can be re-

implemented with microservices, replacing the

legacy service by changing its location in the Ser-

vice Registry that will start to dynamically serve

all microservices instances instead of statically

pointing to the legacy system [S36], (Jamshidi et

al., 2017).

Several papers also identiﬁed pattern disadvantages:

• Interface Design Must be Fixed. During mainte-

nance, individual services may change internally,

Shop.&Cart

Instance(1

Service&1

Load&

Balancer

REST&

API

Registry&

Client

REST&

API

Registry&

Client

REST&

API

Registry&

Client

Shop.&Cart

Instance(2

Shop.&Cart

Instance(3

Service(

Registry

Load&Balance

Query

Request

Figure 5: The Server-side Service Discovery Pattern.

Architectural Patterns for Microservices: A Systematic Mapping Study

225

but there could be a need to also update the in-

terface, requiring adaptation of all connected ser-

vices. Keeping the interface deﬁnition stable min-

imizes the impact of changes [S38].

• Service Registry Complexity. The registry layer

increases the complexity as it requires the imple-

mentation of several interfaces per service [S16].

• Reuse. If not designed correctly, the registry could

be the main bottleneck of the system [S25].

• Distributed System Complexity. Direct com-

munication among services increases several as-

pects: Communication among Services [S2], Dis-

tributed Transaction Complexity [S2], Testing of

distributed systems, including shared services

among different teams can be tricky [S2].

3.1.3 Hyrbid Patterns

The Hybrid Pattern. Concept and Origin: This pat-

tern combines Service Registry and API-Gateway, re-

placing the API-gateway with a message bus.

Goal and Properties: Clients communicate with

the message bus, which acts as a registry and routes

requests to the requested microservices. Microser-

vices communicate with each other through a mes-

sage bus, similar to an Enterprise Service Bus used in

SOA architectures.

Evolution and Reported Usage: Six works imple-

mented this pattern [S27], [S33], [S32], [S35], [S4]

and [S3] reporting the following advantages:

• Ease of Migration. This pattern eases the migra-

tion of existing SOA applications, since the ESB

can be used a communication layer for the mi-

croservices that gradually replace legacy services.

• Learning Curve. Those familiar with SOA can

easily implement this pattern with little training.

and a disadvantage:

• SOA Issues. The pattern does beneﬁt from

the IDEAL properties of microservices (isolated

state, distribution, elasticity, automated manage-

ment, loose coupling) and from the possibility to

independently develop different services with dif-

ferent teams. However it still communicate thru

the ESB as other SOA services.

3.2 Deployment Strategies & Patterns

We now look at architecture patterns from a microser-

vice deployment strategy perspective (deployment

pattern) that emerged from our mapping study.

The Multiple Service per Host Pattern. Principle:

Multiple services run on the same host (node).

Reported Usage: Four of the selected works

implemented this approach [S19], [S7], [S30], and

[S33], without specifying whether they deployed the

services into containers or VMs. Fifteen works

adopted the pattern by deploying each service into

a container [S25], [S10], [S35], [S8], [S9], [S11],

[S32], [S34], [S36], [S37], [S38], [S40], [S41], [S16]

and [S22]. Richardson refers to this sub-pattern as

”service instance per container pattern” [S2]. Two

works implemented this pattern deploying each mi-

croservice into a dedicated virtual machine [S27],

[S31], called ”service instance per virtual machine”

by Richardson.

Despite adoption reports, only a few discuss their

advantages:

• Scalability. Systems can easily scale to deploy

multiple service instances at the same or in host.

• Performance. Multiple containers allow rapid

deployment of new services compared to VMs

[S40], [S34], [S10].

In principle, a Single Service per Host Pattern could

be identiﬁed. Here [S2] mentions that every service is

deployed in its own host. The main advantage of this

approach is the complete isolation of services, reduc-

ing the possibility of conﬂicting resources. However,

this dramatically reduces performance and scalability.

In practice, dedicating a single node for a microser-

vice is counterproductive, violating the basic idea of

microservices.

3.3 Data Storage Patterns

Like any service, microservices need to store data.

Sixteen implementations reported on the data storage

pattern that they adopted. Among these papers, we

identiﬁed three different data storage patterns that are

also described by [S1], [S3] and [S24]. Although it

is recommended to adopt Object Relational Mapping

approaches with NoSQL databases [S1], the patterns

identiﬁed are also applicable for relational databases.

The Database-per-Service Pattern. Principle and

Properties: In this pattern, each microservice ac-

cesses its private database. This is the easiest ap-

proach for implementing microservices-based sys-

tems, and is often used to migrate existing monoliths

with existing databases.

Reported Usage: In the selected works, six

adopted this pattern [S12], [S23], [S36], [S11], [S24]

and [S26]. This pattern has several advantages:

• Scalability. The database can be easily scaled in

a database cluster within a second moment [S24],

in case the service need to be scaled.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

226

• Independent Development. Teams can work in-

dependently on a service, without inﬂuencing the

work of others in case of DB schema changes.

• Security Mechanism. Other microservices access-

ing and corrupting data not needed is avoided

since only one microservice can access a schema.

The Database Cluster Pattern. Principle and Prop-

erties: The second storage pattern, described by

Richardson [S2], proposes storing data on a database

cluster. This improves scalability, allowing to move

the databases to dedicated hardware. In order to pre-

serve data consistency, microservices have a sub-set

of database tables that can be accessed only from a

single microservice; in other cases, each microser-

vice may have a private database schema. From the

microservices point of view, this pattern is identi-

cal to the ”Shared Database Server” pattern since it

in both cases the database is accessed in the same

way. The only difference is internally in the adopted

database. In both cases the database is seen from the

microservice-side as a single database.

Reported Usage: The pattern was implemented

by [S27], [S6], and [S15] by using a separated DB

schema for each service. [S15] also proposed it for

replicating the data across the DBs of each service.

This pattern has the advantage of improving scal-

ability. It is recommended for implementations with

huge data trafﬁc. Disadvantages include:

• Increased Complexity due to cluster architecture.

• Risk of Failure increases because of the intro-

duction of another component and the distributed

mechanism.

The Shared Database Server Pattern. Principle

and Properties: This pattern is similar to the Database

Cluster Pattern, but, instead of using a database clus-

ter, all microservices access a single shared database.

Reported Usage: Six implementations adopted

this pattern [S13], [S39], [S25], [S18], [S30], and

[S16]. All these implementations access to data con-

currently, without any data isolation approach.

The main advantage reported is the simplicity of

the migration from monolithic applications since ex-

isting schema can be reused without any changes.

Moreover, the existing code base can be migrated

without the need to make important changes (e.g., the

data access layer remains identical).

3.4 Guiding Principles of a

Microservices Architectural Style

In order to answer to RQ2, we report on microser-

vices principles not related to a speciﬁc pattern, but

mentioned in the papers as being important and serve

as overarching principles that guide the pattern deﬁ-

nition. A summary of generic and pattern-related ad-

vantages and disadvantages is reported in Table 2.

The most common reported advantages of mi-

croservice architectures are:

• Increased maintainability This is the key charac-

teristic of microservices-based implementations

reported by all the papers.

• Possibility to write code in different languages.

Highlights the beneﬁt of using different lan-

guages, in contrast to monolithic applications

[S13], [S34], [S11].

• Flexibility. Every team can choose their own tech-

nology based on their needs [S30], [S14], [S38]

• Reuse. The maintenance of a single microservice

will reﬂect on any connected project, reducing

the effort overhead by applying the same changes

to the same component used in different projects

[S34], [S12].

• Ease of Deployment. Each microservice can

be deployed independently, without the need to

recompile and redeploy the whole application

[S14], [S30]

• Physical Isolation. This is the key for scal-

ing, thanks to the microservices architectural style

[S3] and [S38].

• Self-Healing. Failed services can be easily

restarted or replaced by previous safer versions

[S7], [S30].

• Application Complexity. Since the application is

decomposed into several components, these are

less complex and easier to manage [S30].

• Design for Failure. Better support for continuous

delivery of many small changes can help develop-

ers in changing one thing at a time [S37].

• Observability. A microservices architecture helps

to visualize the ”health status” of every services in

the system in order to quickly locate and respond

to any problem that occurs [S37].

• Unlimited Application size. In monolithic appli-

cations the application size is limited by the hard-

ware and by web container speciﬁcations, while

with microservices we could build a system with,

in theory, no size limits. [S13].

As agreed advantages, these can be considered to

form the principles of the architectural style.

However, several papers identiﬁed potential dis-

advantages that need to be taken into account:

Architectural Patterns for Microservices: A Systematic Mapping Study

227

• Testing Complexity. More components and col-

laborations among them increases testing com-

plexity [S37], [S21], [S31], [S24], [S26], [S28].

• Implementation Effort. It is reported that imple-

menting microservices requires more effort than

monolithic systems [S30], [S38], [S28]

• Network related issues. Since endpoints are con-

nected via a network, the network should be re-

liable [S14], [S41]. Latency: network latency

can increase the communication time among mi-

croservices [S14], [S11], [S9]. Bandwidth: as

service communication often relies on a network,

bandwidth during normal and high peak opera-

tion needs to be considered. In cloud environ-

ments and other distributed systems settings, un-

reliability is given and failure is always possible.

Microservices can also fail independently of each

other, rather than together on a single node.

• User Authorization. The API exposed by the mi-

croservices need to be protected with a shared

user-authentication mechanism, which is often

much more complex to implement than mono-

lithic solutions [S14].

• Complexity. In the case of applications with a rel-

atively small number of users (hundreds or thou-

sands), the monolith could be a faster approach

to start and could possibly be refactored into a

microservices-based architectural style once the

user-base grows [S11].

• Automation Requirement. The explosion of the

number of services and relationships among them

requires a way to automate things. DevOps could

be a good solution for this issue [S37].

• Increased Dependence. Microservices are meant

to be decoupled, making it critical to preserve in-

dependence and independent deployability.

• Development Complexity. The learning curve is

not very steep, but requires an experienced devel-

oper, at least for setting-up the basic architecture

when compared to monolithic systems [S30].

4 PATTERN CATALOGUE

DISCUSSION

Most of the implementations reported relate to re-

search prototypes, with the goal of validating the

proposed approaches (Table 3). Only six papers re-

port on implementations in an industrial context. Re-

garding the size of the systems implemented, all the

implementations are related to small-sized applica-

tions, except [S38]. Only four implementations re-

port on the development language used ([S11], [S32]

Java/NodeJS, [S34] php/NodeJS/Python, [S13] php).

4.1 Architecture and Deployment

Pattern Applications

Several patterns for microservice-based systems have

emerged from existing implementations (Table 2).

We can associate some patterns with speciﬁc appli-

cation settings such as a monolith-to-microservice or

SOA-to-microservice migration.

Migration: Several implementations report the us-

age of hybrid systems, aimed at migrating existing

SOA-based applications to microservices. Mainte-

nance, and specially independent deployment and the

possibility to develop different services with differ-

ent non-interacting teams, are considered to be the

main reasons for migrating monoliths to microser-

vices. The ﬂexibility to write in different languages

and to deploy the services on the most suitable hard-

ware is also considered a very important reason for

the migration.

Reported migrations from monolithic systems

tend to be architected with an API-Gateway archi-

tecture, probably due to the fact that, since the sys-

tems need to be completely re-developed and re-

architected, this was done directly with this approach.

Migrations from SOA-based systems, on the other

hand, tend to have a hybrid pattern, keeping the Enter-

prise Service Bus as a communication layer between

microservices and existing SOA services. Based on

this, the Enterprise Service Bus could re-emerge in

future evolutions of microservices.

Deployment: Another interesting outcome is that

deployment of microservices is still not clear. As re-

ported for some implementations, microservices are

deployed in a private VM, requiring complete startup

of the whole machine during the deployment, thus de-

feating the possibility of quick deployment and de-

creasing system maintainability due to the need for

maintaining a dedicated operating system, service

container, and all VM-related tasks.

4.2 Trends and Open Issues

We have compiled a catalogue of microservices ar-

chitectural patterns, that together with the principles

we identiﬁed form an architectural style (Malavolta

and Lago, 2017). Some researchers also propose a

new variant of such a microservice architectural style

([S24] and [S26]), applying a database approach for

microservice orchestration. However, because they

have just been published, no implementations have

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

228

Table 2: Classiﬁcation of Advantages and Disadvantages of the Identiﬁed Patterns.

Pattern Advantages Disadvantages

Orchestration

& Coordination

General -Increased maintainability -Development/testing complexity

-Can use different languages -Implementation effort

-Flexibility -Network-related issue

-Reuse

-Physical isolation

-Self-healing

API -Extension easiness -Potential bottleneck

Gateway -Market-centric Architecture -Development complexity

-Backward compatibility -Scalability

Service -Increased maintainability -Interface design must be ﬁxed

Registry -Communic., developm., migration -Service registry complexity

-Software understandability -Reuse

-Failure safety -Distributed system complexity

Hybrid -Migration easiness -SOA/ESB integration issues

-Learning curve

Deploy-

ment

Multiple service -Scalability

per host -Performance

Single service -Service isolation -Scalability

per host -Performance

Data Storage

DB per -Scalability -Data needs to be splitted

Service -Independent development -Data consistency

-Security mechanism

DB -Scalability -Increase complexity

Cluster -Implementation easiness -Failure risks

Shared DB server -Migration easiness -Lack of data isolation

-Data consistency -Scalability

Table 3: The Implementations Reported in the Selected Works.

Research Prototype / System Validation-speciﬁc Implementations Industrial Implementations

Websites [S11], [S39] [S15], [S24], [S26], [S31] [S13], [S32]

Services & APIs IOT Integration [S33] [S9], [S10], [S14], [S16], [S23], [S37], [S36] [S21], [S34]

Others Enterprise Measurement [S4] Benchmark/Test [S35], [S41], [S42] Mobile Dev Platform [S38]

IP Multimedia [S25] Business Process Modeling [S12] Deployment Platform [S30]

adopted these practices yet. Also in this case, we be-

lieve that an empirical validation and a set of bench-

marks (Aderaldo et al., 2017) comparing this new

style with existing one could be highly beneﬁcial for

researchers and practitioners.

Microservices move us towards continuous devel-

opment and delivery (Pahl et al., 2018). DevOps is the

integration of Development and Operations. An im-

portant observation is that microservices require full

application stacks. That means that their infrastruc-

ture resources like data stores and networks have to be

managed properly. DevOps in this way connects soft-

ware development with concerns of technology oper-

ations and quality management. In this context, con-

tainer technology and cloud-native services can pro-

vide the required cloud-based virtualization and im-

plementation support for microservices (Pahl et al.,

2018).

Resulting from our study, but also discussions in

(Malavolta and Lago, 2017) or (Pahl et al., 2018), we

can identify the following emerging issues:

• Comparison of SOA and Microservices. The dif-

ferences have not been thoroughly investigated.

There is a lack of comparison from different

points of view (e.g., performance, development

effort, maintenance).

• Microservices Explosion. What happens once a

growing system has thousands, or millions of mi-

croservices is still not clear. Will all the men-

tioned microservices qualities degrade (Kratzke

and Quint,2017)?

• Negative Results. In which contexts do microser-

vices turn out to be counterproductive? Are there

anti-patterns (Kratzke and Quint,2017)?

All require more experience reports and empirical in-

vestigations.

5 CONCLUSION

We presented principles and a catalogue of patterns

of a microservices-based architectural style. We have

determined these patterns and principles by conduct-

ing a systematic mapping study.

We have used the concept of architecture pat-

terns to extract some common structural properties

Architectural Patterns for Microservices: A Systematic Mapping Study

229

of microservice architectures. Three orchestration

and data-storage patterns emerged that appear to be

widely adopted when implementing microservices-

based systems. Although some patterns were clearly

used for migrating existing monolithic applications

(using service registry pattern) and others for migrat-

ing existing SOA applications (using hybrid pattern),

adopting the API-Gateway pattern in the orchestra-

tion layer in order to beneﬁt from microservice ar-

chitectures without needing to refactor a second time

emerges as a key recommendation. Overall, a 3-

layered catalogue of patterns emerges with patterns

• for orchestration/coordination and storage as

classical structure-oriented architectural pattern

groups that address component-level interaction

and data management concerns, resp., as tradi-

tional software architecture concerns,

• for deployment alternatives that link microser-

vices to their deployment in the form of containers

or VMs, linking microservices inherently to their

deployment strategies in host environments.

We have embedded these in a discussion of principle

beneﬁts and disadvantages of a microservices style

overall.

Independent deployability, being based on strong

isolation, and easing the deployment and self-

management activities such as scaling and self-

healing, and also maintainability and reuse as classi-

cal architecture concerns are the most widely agreed

beneﬁcial principles. The emergence of deployment

patterns here is a ﬁrst step towards a deeper coverage

of continuous development, integration and deploy-

ment in a DevOps style framework. The patterns con-

ﬁrm the need to address microservices in conjunction

with their deployment through containers or VMs.

A further observation concerns the notion of an

architecture style itself in the presence of continuous

architecting. The latter becomes an integral element

of software architecture these days. Correspondingly,

an architectural style needs to cover continuous archi-

tecting activities as well in addition to purely devel-

opment stage concerns such as system design usually

focused on in architectural styles.

REFERENCES

Aderaldo, C.M., Mendonca, N.C., Pahl, C. and Jamshidi,

P. (2017). Benchmark requirements for microservices

architecture research. Proceedings of the 1st Inter-

national Workshop on Establishing the Community-

Wide Infrastructure for Architecture-Based Software

Engineering.

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

croservices Architecture Enables DevOps: Migration

to a Cloud-Native Architecture. IEEE Software. Vol-

ume: 33, Issue: 3, May-June

Bass, L., Weber, I. and Zhu, L. (2015). DevOps: A Software

Architects Perspective. (1st ed.). Addison-Wesley

Professional. ISBN 0134049845 9780134049847.

Di Cosmo, R., Eiche, A., Mauro, J., Zacchiroli, S., Za-

vattaro, G. and Zwolakowski, J. (2015). Automatic

Deployment of Services in the Cloud with Aeolus

Blender. 13th International Conference on Service-

Oriented Computing, ICSOC.

Jamshidi, P., Pahl, C. and Mendonca, N.C. (2017). Pattern-

based multicloud architecture migration. Software:

Practice and Experience 47 (9), 1159-1184.

Kitchenham, B. and Charters, S. (2007). Guidelines for per-

forming Systematic Literature Reviews in Software

Engineering.

Kratzke, K. and Quint, P.C. (2017). Understanding Cloud-

Native Applications after 10 Years of Cloud Comput-

ing - A systematic mapping study. Journal of Systems

and Software, 1-16.

Lewis, J. and Fowler, M. (2014). MicroServices.

www.martinfowler.com/articles/microservices.html.

Malavolta, P.D., Lago, P. 2017. Research on Architecting

Microservices: Trends, Focus, and Potential for In-

dustrial Adoption. In ICSA 2017.

Pahl, C. and Jamshidi, P. (2016). Microservices: A System-

atic Mapping Study. In International Conference on

Cloud Computing and Services Science.

Pahl, C., Brogi, A., Soldani, J. and Jamshidi, P. (2017).

Cloud container technologies: a state-of-the-art re-

view. IEEE Transactions on Cloud Computing.

Pahl, C., Jamshidi, P. and Zimmermann, O. (2018). Archi-

tectural principles for cloud software. ACM Transac-

tion on Internet Technology.

Petersen, K., Feldt, R., Mujtaba, S. and Mattsson, M.

(2008). Systematic Mapping Studies in Software En-

gineering. In EASE 2008.

Richardson, C. (2014). Microservices: Decomposing Ap-

plications for Deployability and Scalability. (2014)

https://www.infoq.com/articles/microservices-intro.

Taibi, D. and Lenarduzzi, V. (2018). On the Deﬁnition of

Microservices Bad Architectural Smells. IEEE Soft-

ware. In press.

Taibi, D., Lenarduzzi, V., and Pahl, C. (2017). Pro-

cesses, Motivations, and Issues for Migrating to Mi-

croservices Architectures: An Empirical Investiga-

tion. IEEE Cloud Computing, vol 4, issue 5, pp.22-32.

Wohlin, C. (2014). Guidelines for Snowballing in System-

atic Literature Studies and a Replication in Software

Engineering. In EASE

Zimmermann, O. (2009). An architectural decision mod-

eling framework for service oriented architecture de-

sign. Ph.D. Dissertation. University of Stuttgart.

A THE SELECTED STUDIES

[S1] Lewis, J. and Fowler, M. 2014. Microservices”.

http://martinfowler.com/articles/microservices.html.

[S2] Richardson, C. 2014. Microservice Architecture”

http://microservices.io.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

230

[S3] Namiot, D. and Sneps-Sneppe, M. 2014. On micro-

services architecture. International Journal of Open In-

formation Technologies V.2(9).

[S4] Vianden, M., Lichter, H. and Steffens, A. 2014. Expe-

rience on a Microservice-Based Reference Architecture

for Measurement Systems. Asia-Paciﬁc Software Engi-

neering Conference.

[S5] Anwar, A., Sailer, A., Kochut, A., Butt, A. 2015.

Anatomy of Cloud Monitoring and Metering: A Case

Study and Open Problems. Asia-Paciﬁc Workshop on

Systems.

[S6] Patanjali, S., Truninger, B., Harsh, P. and Bohnert, T.

M. 2015. CYCLOPS: A micro service based approach

for dynamic rating, charging & billing for cloud. Con-

ference on Telecommunications.

[S7] Toffetti, G., Brunner, S., Bl

ochlinger, M., Dudouet,

F. and Edmonds. A. 2015. Architecture for Self-

managing Microservices. Int. Workshop on Automated

Incident Mgmt in Cloud.

[S8] Chen, H.M., Kazman, R., Haziyev, S.,Kropov, V. and

Chtchourov, D. 2015. Architectural Support for De-

vOps in a Neo-Metropolis BDaaS Platform. Sympo-

sium on Reliable Distr Syst Workshop.

[S9] Stubbs, J., Moreira, W. and Dooley, R. 2015. Dis-

tributed Systems of Microservices Using Docker and

Serfnode. Int. Workshop on Science Gateways.

[S10] Abdelbaky, M., Diaz-Montes, J., Parashar, M., Unuvar,

M. and Steinder, M. 2015. Docker containers across

multiple clouds and data center. Utility and Cloud

Computing Conference.

[S11] Villamizar, M., Garcas, O., Castro, H. et al. 2015. Eval-

uating the monolithic and the microservice architecture

pattern to deploy web applications in the cloud. Com-

puting Colombian Conference

[S12] Alpers, S., Becker, C., Oberweis, A. and Schuster,

T. 2015. Microservice Based Tool Support for Busi-

ness Process Modelling. Enterprise Distributed Object

Computing Workshop.

[S13] Le, V.D., Neff, M.M., Stewart,R.V., Kelley, R.,

Fritzinger, E., Dascalu, S.M. and Harris, F.C. 2015.

Microservice-based architecture for the NRDC. Indus-

trial Informatics Conference.

[S14] Malavalli, D. and Sathappan, S. 2015. Scalable Mi-

croservice Based Architecture for Enabling DMTF Pro-

ﬁles. Int. Conf. on Network and Service Management.

[S15] Viennot, N., Mathias, M. L

ecuyer, Bell, J., Geambasu,

R. and Nieh, J. 2015. Synapse: A Microservices Archi-

tecture for Heterogeneous-database Web Applications.

European Conf. on Computer Systems.

[S16] Versteden, A., Pauwels, E. and Papantoniou, A. 2015.

An ecosystem of user-facing microservices supported

by semantic models. International USEWOD Work-

shop.

[S17] Rahman, M. and Gao, J. 2015. A Reusable Automated

Acceptance Testing Architecture for Microservices in

Behavior-Driven Development. Service-Oriented Sys-

tem Engineering Symposium.

[S18] Rahman, M., Chen, Z. and Gao, J. 2015. A Ser-

vice Framework for Parallel Test Execution on a De-

veloper’s Local Development Workstation. Service-

Oriented System Engineering Symposium.

[S19] Rajagopalan, S. and Jamjoom, H. 2015. App-Bisect:

Autonomous Healing for Microservice-based Apps.

USENIX Conference on Hot Topics in Cloud Comput-

ing.

[S20] Meink, K. and Nycander, P. 2015. Learning-based test-

ing of distributed microservice architectures: Correct-

ness and fault injection”. Software Engineering and

Formal Methods workshop.

[S21] Bak, P., Melamed, R., Moshkovich, D., Nardi, Y., Ship,

H., Yaeli, A. 2015. Location and Context-Based Mi-

croservices for Mobile and Internet of Things Work-

loads. Conference Mobile Services.

[S22] Savchenko, D. and Rodchenko, G. 2015. Microservices

validation: Methodology and implementation”. Ural

Workshop on Parallel, Distributed, and Cloud Comput-

ing for Young Scientists.

[S23] Gadea, C., Trifan, M., Ionescu, D., Ionescu, B. 2016.

A Reference Architecture for Real-time Microservice

API Consumption. Workshop on CrossCloud Infras-

tructures & Platforms.

[S24] Messina, A., Rizzo, R., Storniolo, P., Urso, A. 2016. A

Simpliﬁed Database Pattern for the Microservice Ar-

chitecture. Advances in Databases, Knowledge, and

Data Applications conference.

[S25] Potvin, P., Nabaee, M., Labeau, F., Nguyen, K. and

Cheriet, M. 2016. Micro service cloud computing pat-

tern for next generation networks. EAI International

Summit.

[S26] Messina, A., Rizzo, R., Storniolo, P., Tripiciano, M. and

Urso, A. 2016. The database-is-the-service pattern for

microservice architectures. Information Technologies

in Bio-and Medical Informatics conference.

[S27] Leymann, F., Fehling, C., Wagner, S., Wettinger, J.

2016. Native cloud applications why virtual machines,

images and containers miss the point. Cloud Comp and

Service Science conference.

[S28] Killalea, T. 2016. The Hidden Dividends of Microser-

vices. Communications of the ACM. V.59(8), pp. 42-

45.

[S29] M. Gysel, L. K

olbener, W. Giersche, O. Zimmer-

mann. ”Service cutter: A systematic approach to ser-

vice decomposition”. European Confeence on Service-

Oriented and Cloud Computing.

[S30] Guo, D., Wang, W., Zeng,G. and Wei, Z. 2016.

Microservices architecture based cloudware deploy-

ment platform for service computing. Symposyum on

Service-Oriented System Engineering. 2016.

[S31] Gabbrielli, M., Giallorenzo, S., Guidi, C., Mauro, J. and

Montesi, F. 2016. Self-Reconﬁguring Microservices”.

Theory and Practice of Formal Methods.

[S32] Gadea, M., Trifan, D. Ionescu, et al. 2016. A microser-

vices architecture for collaborative document editing

enhanced with face recognition. Symposyum on Ap-

plied Computing.

Architectural Patterns for Microservices: A Systematic Mapping Study

231

[S33] Vresk, T. and Cavrak, I. 2016. Architecture of an in-

teroperable IoT platform based on microservices. In-

formation and Communication Technology, Electronics

and Microelectronics Conference.

[S34] Scarborough, W., Arnold, C. and Dahan, M. 2016. Case

Study: Microservice Evolution and Software Lifecycle

of the XSEDE User Portal API. Conference on Diver-

sity, Big Data & Science at Scale.

[S35] Kewley, R., Keste, N. and McDonnell, J. 2016. DEVS

Distributed Modeling Framework: A Parallel DEVS

Implementation via Microservices. Symposium on

Theory of Modeling & Simulation.

[S36] O’Connor, R., Elger, P., Clarke, P., Paul, M. 2016. Ex-

ploring the impact of situational context - A case study

of a software development process for a microservices

architecture. International Conference on Software and

System Processes.

[S37] Jaramillo, D., Nguyen, D. V. and Smart, R. 2016.

Leveraging microservices architecture by using Docker

technology SoutheastCon.

[S38] Balalaie, A., Heydarnoori, A. and Jamshidi, P. 2015.

Migrating to Cloud-Native architectures using mi-

croservices: An experience report. European Confer-

ence on Service-Oriented and Cloud Computing.

[S39] Lin, J. Lin, L.C. and Huang, S. 2016. Migrating web

applications to clouds with microservice architectures.

International Conference on Applied System Innova-

tion.

[S40] Xu,C., Zhu, H., Bayley, I., Lightfoot, D., Green, M. and

Marshall P. 2016. CAOPLE: A programming language

for microservices SaaS. Symp. on Service-Oriented

System Engineering.

[S41] Amaral, M., Polo, J., Carrera, D., et al. 2015. Per-

formance evaluation of microservices architectures us-

ing containers. Internatinoal Symposium on Network

Computing and Applications.

[S42] Heorhiadi, V., Rajagopalan, S., Jamjoom, H., Reiter,

M.K., and Sekar, V. 2016. Gremlin: Systematic Re-

silience Testing of Microservices. International Con-

ference on Distributed Computing Systems.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

232