Journal of Computer Information Systems

ISSN: 0887-4417 (Print) 2380-2057 (Online) Journal homepage: http://www.tandfonline.com/loi/ucis20

Architecting Microservices: Practical Opportunities

and Challenges

Saša Baškarada, Vivian Nguyen & Andy Koronios

To cite this article: Saša Baškarada, Vivian Nguyen & Andy Koronios (2018): Architecting
Microservices: Practical Opportunities and Challenges, Journal of Computer Information Systems

To link to this article: https://doi.org/10.1080/08874417.2018.1520056

Published online: 26 Sep 2018.

Submit your article to this journal

View Crossmark data

Full Terms & Conditions of access and use can be found at

http://www.tandfonline.com/action/journalInformation?journalCode=ucis20
JOURNAL OF COMPUTER INFORMATION SYSTEMS
https://doi.org/10.1080/08874417.2018.1520056

Architecting Microservices: Practical Opportunities and Challenges

Saša Baškaradaa, Vivian Nguyenb, and Andy Koroniosa
a
University of South Australia, Adelaide, Australia; bDefence Science and Technology Group, Fishermans Bend, Australia

ABSTRACT KEYWORDS
Contemporary highly dynamic technology and business environments, coupled with digitally savvy Microservices; service
customers, are forcing both private and public organizations to continuously innovate and update oriented architecture (SOA);
their Information and Communication Technology (ICT) service offerings. In order to decrease the DevOps; orchestration;
development cycles and ensure continuous delivery, many organizations are adopting new practices choreography
aimed at unifying software development and operations (i.e., DevOps). However, monolithic architec-
tures of many large systems underpinning ICT services are severely restricting the effectiveness of such
efforts. Although the latest architectural trend, microservices, is promising to solve many of the
problems associated with monolithic software architectures, there is significant disagreement on
when microservice architecture should be adopted, as well as how it may be best implemented.
Given the limited empirical research on the topic, this paper identifies and discusses a range of
opportunities and challenges associated with the adoption and implementation of microservices. The
findings presented in the paper have been derived from in-depth interviews with 19 ICT architects with
significant experience in large corporate systems, middleware, service oriented architectures, and, to a
somewhat more limited extent, microservices.

Introduction deployed, scaled, and tested.9 They support agility since they can
be independently developed and modified using different pro-
Organizational agility, the capacity to flexibly respond to
gramming languages and product stacks.10 Some of the more
changes in the environment by quickly adjusting product
popular technologies used for implementing and deploying
and service offerings, is increasingly becoming critical to
microservice include Docker, Node.js, MySQL, PostgreSQL,
achieving sustained competitive advantage. 1 Information
Java, MongoDB, and PHP.11 A microservice architecture has
and Communication Technologies (ICT) are a key enabler
been described as a “distributed application where all its modules
of organizational agility, not just in the technology sector, but
are microservices”.2
more broadly (e.g., Uber and Airbnb). Many organizational
While each individual microservice is relatively simple com-
capabilities and functions are underpinned by large mono-
pared to a large monolithic application, such a comparison is
lithic software systems, including Enterprise Resource
misleading since the complexity resides in the whole system
Planning (ERP) and Customer Relationship Management
composed of microservices. Due to their distributed nature,
(CRM); where a monolith has been defined as “a software
such systems may be even more complex than monolithic
application whose modules cannot be executed
applications.8 Furthermore, since each microservice may have a
independently”.2 As such systems grow and become more
separate back-end, and be developed by a different team on a
complex, they also become more difficult to change. As a
different technology stack, the resulting complexity may not be
result, large monolithic software systems may slow organiza-
manageable without a DevOps capability.12
tional ability to quickly respond to changes in the environ-
DevOps is a set of practices aimed at unifying software devel-
ment; e.g., changes in customer and competitor behaviors. In
opment (Dev) and IT operations (Ops) that make heavy use of
other words, rather than enabling, large monolithic software
automation and monitoring to decrease the development cycles
systems may hinder organizational agility. 3
while ensuring high software quality.13 Continuous delivery is a
One of the most recent architectural trends, microservices (see
DevOps practice aimed at automating the process of software
Table 1), has been proposed as a potential solution to the above-
testing and deployment into production environments, while
mentioned problem.5–7 The term “microservices” was reportedly
continuous monitoring is a DevOps practice aimed at providing
first discussed at a workshop of software architects near Venice in
developers with real-time performance data.5
May 2011.8 While there is arguably still no precise definition, in
A major difference between microservices and traditional
contrast to monolithic software architectures, microservices are
Service-Oriented Architecture (SOA) is that microservices
small applications (generally less than a couple of thousand lines
do not make use of an Enterprise Service Bus (ESB), a
of code) with a single responsibility (a functional, non-functional,
defining feature of SOA.9 Instead, they generally
or cross-functional requirement) that can be independently

CONTACT Saša Baškarada [email protected] University of South Australia, North Terrace, Adelaide, SA 5000 Australia
Color versions of one or more of the figures in the article can be found online at www.tandfonline.com/ucis.
© 2018 International Association for Computer Information Systems
2 S. BAŠKARADA ET AL.

Table 1. Monolithic vs. microservice architecture; developed from 2,4

.
Monolithic Architecture Microservices
Due to their large size and complexity, they are difficult to debug, maintain, Due to their small size and low complexity, they are relatively easy to debug,
and evolve. maintain, and evolve.
Development and testing is slowed-down as, due to the dependencies between Accelerated development and testing enabling continuous delivery as, due to
modules, making changes to one module may require restarting the whole their independence, each microservice can be separately changed and deployed.
application.
Since various modules may have different resource requirements, deploying Individual microservices may be deployed and optimized in separate
monolithic applications in a single environment generally leads to sub-optimal environments.
performance.
Scalability is limited since it is not possible to scale only a subset of modules. Each microservice can be independently scaled leading to improved resource
utilization.
Since they are built on the same technology stack, development flexibility is Each microservice may be developed using a different technology stack, leading
limited. to greater flexibility.

communicate directly with each other through standards ● componentization via services—the application is bro-
like HTTP, REST, and JSON. 12 Another key difference ken-down into independent services that run in differ-
between SOA and microservices is that SOA generally ent processes, share no resources, and communicate via
exposes services from existing monolithic applications. lightweight messaging;
Since such services are tightly integrated with the mono- ● being organized around business capabilities—built by
lithic applications, they cannot be independently changed, cross-functional teams;
scaled, and deployed. ● focus on products rather than projects—cross-functional
Although Amazon, Netflix, and the Guardian are fre- teams are responsible for the whole lifecycle of a
quently highlighted as early adopters of microservices, microservice;
most of the academic research on microservices is still in ● smart endpoints and dumb pipes—microservices com-
a formative stage, 2,14,15 and at a relatively low technology municate via RESTful interfaces and avoid any complex
readiness level (formulated, validated, or at most demon- orchestration and choreography busses;
strated in a lab).16 Furthermore, empirical research on ● decentralized governance and data management—
microservices is limited.11 As a result, this paper answers microservices may be developed using different technol-
calls for qualitative studies with practitioners aimed at ogy stacks with no common data model;
better understanding the state of the practice on ● infrastructure automation—microservice architecture
microservices.14,16 generally presupposes extensive experience with contin-
While prior studies have explored a range of technical uous integration and delivery;
issues associated with the implementation of microser- ● design for failure—given that services can fail at any
vices, including communication/integration, service dis- time, quickly detecting failures and automatically restor-
covery, performance, fault tolerance, security, tracing and ing services becomes important; and
logging, application performance monitoring, and deploy- ● evolutionary design—microservices can be easily substi-
ment operations,15 this paper aims to contribute to the tuted. 8
literature by also exploring organizational, cultural, and
institutional factors. Specifically, this study aims to answer As a result of their independence, each microservice runs in a
the following research question: different process (frequently deployed on different virtual
What are the practical opportunities and challenges associated machines), and has an independent back-end database.3 It is
with the adoption and implementation of microservice architecture? important to clarify that separate data stores do not necessa-
The rest of the paper is organized as follows. Section two provides rily imply separate database servers. In other words, different
an overview of related research, and section three describes the microservices could share a database server as long as they are
research method employed. Section four presents the findings by using different schemas. Individual microservices may be
discussing a range of opportunities and challenges associated with dynamically located via service registries and discovery
the adoption and implementation of microservice architecture. mechanisms.5,17 While, in theory, the strict autonomy of
Section five concludes the paper by discussing the research limita- microservices is thought to enforce modularization, how
tions and identifying opportunities for future research. well this actually works in practice is a still unanswered
empirical question.8
Since each microservice has its own data store, there is no
Literature review
single source of truth, and maintaining data consistency may
Research on microservices is recent and limited.2,11,14,15 A become problematic.12 While some published prototypes have
recent literature review identified 71 relevant studies, most avoided this problem by implementing microservices with a
of which were published after 2014. 16 Another recent litera- shared database,17 such solutions are generally seen as being
ture review found that most of the published papers on out of pattern with the share-nothing microservices architec-
microservice are non-empirical. 11 Although there is no for- ture. Implementing complex business processes through
mal definition, a common view is that microservices are microservices may require the addition of a message broker.
“cohesive, independent processes interacting via messages”.2 Such asynchronous messaging may lead to inconsistencies in
Common characteristics of microservice architecture include: individual data stores.12
 JOURNAL OF COMPUTER INFORMATION SYSTEMS 3

The effectiveness of microservice architecture is largely complexity in the system. Instead, the recommendation is
determined by the skills of the cross-functional implementa- to employ choreography, which distributes the coordination
tion teams.7 Implementing and sustaining distributed systems responsibilities to individual microservices, generally in the
is inherently more difficult than monolithic applications.2 For context of event driven architecture.3 However, since indi-
instance, microservices developers and architects need be vidual microservices are not prohibited from making calls
aware of the fallacies of distributed computing, including to other microservices, it is not clear at what point a regular
assuming that the network is reliable, that latency is zero, microservice becomes an orchestrator. Furthermore there is
that the bandwidth is infinite, that the network is secure, still significant debate on whether orchestration can be
that topology doesn’t change, that there is one administrator, entirely avoided, especially when implementing business
that transport cost is zero, and that the network is processes with complex states.19
homogeneous.18 Thus, while more experienced teams may
be able to derive many of the advantages associated with
Methods
microservices, less experienced/skilled teams may be more
effective at implementing traditional monolithic systems.8 This paper adopts evidence-based software engineering
Although some have argued that most organizations (EBSE), which recommends starting with a research question,
implementing microservices (e.g., Netflix and Amazon) start identifying the best data to answer that question, analyzing
by decomposing existing large monolithic applications rather and critically evaluating the data collected, integrating the
than building new applications comprised of microservices,- critical appraisal with our expertise and stakeholders’ values
9,19
others have found that decomposing monolithic applica- and circumstances, and finally critically reflecting on our
tions into microservices is one of the key barriers to the execution of the study with a view to identifying lessons for
adoption of microservices.20 For instance, while describing future research.22 We chose to frame this study in the context
the migration of an on-premises commercial Mobile of EBSE because of the strong grounding of the research
Backend as a Service (MBaaS) platform to a microservices question in the practice of software engineering; e.g., most
architecture in the cloud, Balalaie, Heydarnoori5 highlight a of the relevant research and discussion has so far taken place
number of key challenges associated with such efforts, includ- in the software engineering community. Nevertheless, while
ing architectural refactoring, incremental migration, and the framing this research as EBSE, we need to acknowledge sig-
adoption of DevOps practices (continuous integration, deliv- nificant methodological overlap with qualitative research in
ery, and monitoring). information systems and social sciences more broadly. Given
Taibi, Lenarduzzi20 interviewed 21 practitioners, who had that we were more interested in exploring the how and why
adopted microservice architecture, on their motivations for relating to practical opportunities and challenges associated
migrating to microservices, as well as on the pros and cons of with adoption and implementation of microservice architec-
microservices versus monolithic applications. They found that ture, rather than in questions like who, what, where, how
organizations tend to migrate to microservice architecture to many, and how much, a qualitative research approach was
improve software maintainability and scalability, as well as to deem suitable.
support DevOps. Many organizations also reported adopting Accordingly, qualitative data were collected through semi-
microservices simply because other organizations were doing structured interviews with 19 ICT architects. The number of
it. Taibi, Lenarduzzi20 also identified a number of key issues interviewees is broadly in line with recommendations from
when migrating from monolithic software to microservices, methodological literature, which notes that although the
including the difficulty of decomposing the monolith. appropriate number of interviews depends on the the phe-
Decomposing of the data layer was identified as being parti- nomenon under investigation, the scope of the study, and the
cularly difficult, so much so that many interviewees reported timeframe available,23 studies should generally aim for at least
adopting microservices with a centralized legacy database. 15 interviews.24 All participants were interviewed face-to-face,
Microservices architecture is closely tied with continuous and each interview generally lasted between 30 and 60 min-
delivery through DevOps, as well as the use of container utes. Most interviews were recorded (several participants did
technologies (lightweight virtualization packaging mechan- not agree to being recorded) and subsequently transcribed.
ism) and Platform as a Service (PaaS) cloud infrastructure.5,14 All interviewees had more than 10 years of professional
However, recent experiments have indicated that container ICT experience, and more than five years of experience as
technologies like Docker may have potentially significant per- domain, solution, and/or enterprise architects (see Table
formance impact of 10%–20%. 21 2). While there is a significant overlap between the differ-
Implementing complex business processes that span the ent roles, enterprise architects generally aim to simplify
boundaries of individual microservices is no trivial matter. and optimize the entire ICT landscape of an organization,
Although it is generally recommended that microservices domain architects specialize in particular industries (e.g.,
should avoid complex orchestration,8, exactly how this telecommunication) or broad technology types (e.g., cloud
may best be accomplished in practice is not well under- computing), and solution architects generally specialize in
stood. Orchestration, which originates with SOA, relies on a particular products or technology stacks (e.g., Big Data
centralized process/service that coordinates all other micro- analytics). Most of the interviewees had had a range of
services partaking in the execution of a business process. roles in both private and public organizations, and at the
Since such orchestrators assume all responsibility for com- time of the study, eight of the interviewees were employed
mand and control, this approach increases coupling and as consultants/contractors, seven were employed in public
4 S. BAŠKARADA ET AL.

Table 2. List of Interviewees.

# Position ICT Experience ICT Architecture Experience Employment Type
1 enterprise architect > 25 years > 15 years public organization
2 enterprise architect > 30 years > 15 years public organization
3 enterprise architect > 20 years > 10 years public organization
4 solution architect > 10 years > 5 years consultant/contractor
5 domain architect > 15 years > 5 years public organization
6 solution architect > 20 years > 10 years consultant/contractor
7 solution architect > 30 years > 15 years public organization
8 domain architect > 10 years > 5 years private organization
9 enterprise architect > 30 years > 15 years public organization
10 solution architect > 20 years > 10 years consultant/contractor
11 domain architect > 15 years > 10 years private organization
12 solution architect > 10 years > 5 years private organization
13 domain architect > 20 years > 10 years consultant/contractor
14 solution architect > 10 years > 5 years consultant/contractor
15 solution architect > 15 years > 5 years consultant/contractor
16 solution architect > 20 years > 10 years consultant/contractor
17 solution architect > 10 years > 5 years consultant/contractor
18 solution architect > 20 years > 10 years public organization
19 enterprise architect > 25 years > 10 years private organization

organizations, and the remaining four were permanent properties may include causes, conditions, consequences,
full-time employees of large private organizations. dimensions, types, and processes. Once identified, cate-
As this study adopts a qualitative rather than a quanti- gories and their properties may then be integrated into a
tative approach, there was no need to select a statistically preliminary theory. While Glaser and Holton29 explain
representative sample. Instead, participants were selected what needs to be compared, exactly how this is to be
based on their subject matter expertise, availability, and done remains relatively ambiguous. When comparing
willingness to participate in the study. All interviewees coded items, other scholars have suggested looking for
were identified through authors’ professional networks. equivalence, similarity and difference.28
All of the interviewees had extensive experience with We followed three sequential stages: open coding, axial
large corporate systems, middleware, service-oriented coding, and selective coding.30 During open coding, we
architectures, and to a somewhat more limited extent broke down the data into codes and categories. During axial
microservices. Although a set of predefined questions coding, we explored and explained the relationships between
was used to guide the interviews (see Table 3), the semi- those codes and categories. During selective coding, we iden-
structured approach provided the authors with the flex- tified a couple of central categories (opportunities and chal-
ibility to refocus questions, or prompt for more informa- lenges), related other codes and categories to that core, and
tion, when an interesting or novel topic emerged. 24 The explained them in terms of that core.
high-level interview questions detailed in Table 3 were The coding was iteratively performed by the lead
largely based on the main research question. The first researcher and reviewed by the co-authors. Following each
four questions were aimed at building rapport with the review, any coding-related disagreements were discussed by
interviewees as well as at establishing their level of exper- the researchers and the codebook was updated accordingly.31
tise. Questions four and five were directly derived from While no quantitative inter-coder reliability assessments were
the main research question, and the final question is a undertaken, inter-coder reliability was not considered proble-
standard closing question generally used in qualitative matic as the number of coding-related disagreements reduced
studies. (and inter-coder consensus increased) with each iteration. In
The constant comparative method of qualitative data order to ensure a level of face-validity, the outcomes of the
analysis was used to identify key factors, themes, and analysis were reviewed by several subject matter experts.
patterns.25,26 Qualitative data analysis in general, and the
constant comparative method in particular, aim to add
structure to unstructured text. For instance, thematic ana-
lysis, where categories are grouped into overarching
Table 3. Interview Questions.
themes, is one of the most frequently employed
# Question
approaches to qualitative data analysis.27 Such structure,
1 Could you please tell us about your current role (position, organization,
which is introduced in stages, forms the basis of any etc.)?
resulting frameworks, theories, and explanations.28 The 2 Could you please tell us about your professional ICT experience?
constant comparative method was first outlined by 3 Could you please tell us about your professional ICT architecture
experience?
Glaser 25 in a seminal paper that highlighted the impor- 4 Could you please tell us about your experience with microservices and
tance of simultaneous coding and analysis. The method related architectural trends (e.g., SOA)?
5 In your opinion, what are the advantages of microservice vs. monolithic
initially involves the identification of as many categories architectures?
of analysis as possible. According to Glaser, this data 6 What are some of the key practical challenges associated with the
categorization directly leads to the identification of theo- adoption and implementation of microservices?
7 Is there anything else you would like to add?
retical properties relating to categories. Such theoretical
 JOURNAL OF COMPUTER INFORMATION SYSTEMS 5

Results and discussion

Although all 19 interviewees had extensive experience with
large corporate systems, middleware, and service-oriented
architectures, their experience with microservices was signifi-
cantly more limited. This can be explained by the newness
and as yet relatively limited adoption of the architectural
trend. While all interviewees had some exposure to microser-
vices, only seven had implemented major production systems
through microservice architecture. Three of those had imple-
mented new applications, while the other four had decom-
posed existing monoliths into microservices. Nine
interviewees had experimented with a small number of rela-
tively simple microservices, either in sandpit and/or produc- Figure 1. Types of Corporate Systems.
tion environments. The remaining three interviewees had
considered the adoption of microservices, but for various had seriously considered applying microservice architecture to
reasons never proceeded with implementation. Based on our reengineer corporate systems of record.
discussions with the interviewees, we identified two main The opportunity to use heterogeneous technology stacks
opportunities and 10 key challenges associated with the adop- was singled out by most interviewees as almost an end in
tion and implementation of microservice architecture. itself. Existing monoliths are generally based on relatively
fixed technology stacks, some of which may be relatively
old (e.g., several of the interviewees had recently worked
Opportunities on monoliths written in COBOL). Relatively old technol-
Perhaps unsurprisingly, the opportunities associated with the ogy stacks may not provide the best system performance
adoption of microservice architecture identified by the inter- and/or user experience, and relatively rare technologies
viewees agreed with the purported benefits promoted by var- may be expensive and difficult to maintain (e.g., the supply
ious vendors and enthusiasts. They were centered around of COBOL developers is much more limited that the sup-
improving agility in software development (Dev) well as ply of Java developers). Thus, the possibility for heteroge-
around optimizing scalability in IT operations (Ops). neous technology stacks in the microservice architecture
was seen as a significant enabler of experimentation and
innovation. Different teams and/or developers could
experiment with different technologies and the best tech-
Development/deployment agility nologies could be identified through the process of natural
All of the interviewees highlighted the lack of agility asso- selection. Since individual developers may be more pro-
ciated with large monolithic corporate systems as a major ductive in particular technologies, giving developers the
issue. Such systems and the associated governance procedures freedom to choose their own tools was also seen as a
are seen as barriers to modern digital business initiatives. boost to productivity.
While microservices were acknowledged as a potential solu- In addition to the higher agility in software development,
tion to some of the problems associated with simpler mono- the interviewees also stressed more agile softer deployment.
liths, none of the interviewees suggested that complex Since microservices can be independently deployed, there is
corporate systems of record (e.g., ERP and CRM) should be no need to deploy the entire system/monolith each time any
decomposed into microservice architecture. Large corporate of the microservices are updated. Such approach is also less
systems of record generally support complex business pro- risky, since any problematic deployments can also be rolled
cesses that may span the entire organization (as well as exter- back relatively quickly.
nal suppliers and service providers). As a result, individual
modules of such systems are highly interdependent.
Operational scalability
Furthermore, corporate systems of record should be fairly
stable, without a need for frequent changes. Instead, the Besides development/deployment agility, operational scalabil-
interviewees suggested that microservice architecture may be ity was identified as another key potential benefit of micro-
more suitable for corporate systems of engagement (used for service architecture. Most interviewees highlighted the
communication and collaboration), systems of differentiation difficulty of appropriately scaling monolithic applications.
(bespoke systems underpinning organizational business mod- Given the ubiquitous adoption of cloud infrastructure and
els), and systems of innovation—experimental systems devel- platform services, scaling out (adding extra virtual servers)
oped to address ad hoc business requirements that may be was preferred to scaling up (adding extra components like
incorporated into future systems of differentiation (see RAM and CPU to existing servers). Although different appli-
Figure 1). Using this terminology, five of the architects inter- cation tiers (presentation, logic, and data) may be scaled
viewed had implemented corporate systems of differentiation separately, this was seen as insufficiently flexible as different
using microservice architecture, while 11 had utilized micro- modules from each tier may have different scaling require-
services for systems of innovation. None of the interviewees ments (see Figure 2). Moreover, several interviewees were of
6 S. BAŠKARADA ET AL.

the view that microservice architecture was well suited to understanding of a range of non-functional aspects, includ-
serverless (function as a service computing); e.g. Azure ing security, system fault-tolerance, microarchitecture reco-
Functions and Amazon Web Services Lambda. Serverless verability, latency, and the like.
computing aims to simplify IT operations by abstracting
away virtual machines, virtual network infrastructure, and
scaling. Saas and COTS applications
Only a small number of the interviewees reported developing
bespoke corporate applications (mainly systems of innova-
Challenges tions and some systems of differentiation), and none of the
Most of the interviewees had significant reservations regard- interviewees reported developing bespoke systems of record
ing the adoption of microservice architecture. These included and systems of engagement. In general, the interviewees were
the lack of relevant skills, the reliance on Software as a Service of the view that most organizations prefer buying established
(SaaS) and commercial off the shelf (COTS) on-premises COTS products and/or subscribing to cloud-based SaaS solu-
applications, organizational culture and structure, governance, tion than developing bespoke systems. Such reliance on
difficulties associated with monolith decomposition/refactor- monolithic COTS and SaaS application places obvious limits
ing, master data management, orchestration and choreogra- on the potential uptake of microservice architecture. Finally,
phy, testing, and performance. in contrast to microservices, which imply decomposition of
monoliths, SOA integrates perfectly well with monolithic
COTS and SaaS products.
Lack of relevant skills
While developing individual microservices may not presup- Organizational culture
pose any particular skillsets (since they may be developed
with heterogeneous technology stacks), effectively imple- Since individual microservices are owned by individual devel-
menting and efficiently managing a large application devel- opers and/or small teams, microservice architecture requires a
oped using microservice architecture requires significant significant amount of organizational trust. Each microservice
advanced skills in distributed system development and developer/owner needs to trust that other developers/owners
DevOps. Given that individual microservices can be devel- will produce and operate efficient and reliable microservices.
oped and deployed independently, and considering that Because of network effects, microservice architecture becomes
non-trivial applications may be composed of a large number more useful as more microservices partake in it. As a result,
of microservices, the resulting architectural complexity for microservice architecture to be effective, the organization
(continuous development/delivery, monitoring, scaling, needs to be accepting of microservices.
recovery, etc.) cannot be managed manually. Popular
DevOps tools include Jenkins (for continuous integration),
Governance
Docker (for containerized deployment), Docker Swarm (for
container clustering and orchestration), and Kubernetes (for The distributed nature of microservices requires a significant
load balancing, scaling, and discovery). Moreover, the shift from traditional governance frameworks and processes.
assumption that, due to their relative simplicity, individual Governance of microservices architecture is by definition dis-
microservices are easy to develop is also misleading. tributed. While individual owners are responsible for their
Compared with large teams developing monoliths, where microservices, they also need to consider potential impacts
individual developers can specialize in particular technolo- of changes on other dependent microservices. Given the dis-
gies/features, microservice developers need to have a solid tributed nature of microservice architecture, governance is

presentation tier logic tier data tier

microservice microservice microservice
microservice microservice microservice
microservice microservice microservice
microservice microservice microservice

web server application server database server

microservice microservice microservice

microservice microservice microservice
Internet microservice microservice microservice
firewall load balancer microservice load balancer microservice load balancer microservice

web server application server database server

microservice microservice microservice

microservice microservice microservice
microservice microservice microservice
microservice microservice microservice

web server application server database server

Figure 2. Three tier architecture.

 JOURNAL OF COMPUTER INFORMATION SYSTEMS 7

generally ensured through interface/API contracts. Any Decomposition/refactoring

changes to interfaces of microservices generally have signifi-
Decomposing large existing monoliths was seen by most
cant broader effects. Although interface changes can be dis-
interviewees as largely impractical, especially in the context
couraged and minimized, they cannot be entirely avoided. As
of systems of record. The four interviewees who had decom-
a result, changes to any interfaces need to be broadly com-
posed existing monoliths into microservices confirmed the
municated and coordinated with related microservices.
enormity of the task and suggested that in some cases it
may even be easier developing a new application from scratch
rather than decomposing an existing monolith. The intervie-
Organizational structure wees noted that the lack of documentation and the fact that
many of the original architects, designers, and developers had
The fact that most IT departments are organized around moved on, meant that the monolith had to be reengineered
“plan, build, run” silos was identified as perhaps the biggest
before it could be decomposed. Whether the result is worth
obstacle to microservice architecture. Given that many (per- the effort may be determined by the business criticality of the
haps most) organizations predominantly rely on SaaS and application in question. All four architects who reported
COTS software suggests that traditional “plan, build, run”
decomposing an existing monolith into microservices had
structures of IT departments are probably here to stay for done it for a business critical system of differentiation.
some time. The fact that such organizational structures run
counter to DevOps and microservice architecture philoso-
phies was seen as a major barrier to effective adoption. Master data management
According to Conway’s Law, “organizations which design
systems . . . are constrained to produce designs which are Given that microservice architecture discourages a common
copies of the communication structures of these data model, and encourages decentralized data management,
organizations”.32 For instance, the fact that more loosely- interviewees expressed significant concerns regarding master
coupled organizations tend to produce more modular designs data management. There was little understanding regarding
has found strong empirical support.33 how data consistency may best be ensured in microservice
DevOps and microservice architecture presuppose the con- architecture, given that the same data may be stored in multi-
trol of the entire deployment pipeline, from development to ple databases in a range of formats. This can cause obvious
operations. This is generally not the case in siloed IT depart- problems with data updates. While it was acknowledged that
ments (see Figure 3). Given that microservices and DevOps using a centralized data store (which some of the interviewees
largely originated in IT organizations like Google, Amazon, had done with microservice-based systems of innovation) may
and Netflix, whose business models revolve around IT ser- alleviate some of these problems, there was also general agree-
vices, there was some concern among the interviewees about ment that this would introduce an unacceptable level of cen-
how such structures could be effectively implemented in tralization that is counter to the spirit of decentralized
organizations whose business model does not revolve around microservice architecture.
IT. In such organizations, effective adoption of microservices
and DevOps may require major structural changes to existing Orchestration and choreography
IT departments; for instance, by distributing relevant IT
expertise among various business units. There was little consensus on when to use orchestration and
when choreography in microservice architecture. While most
of the interviewees had experience with SOA orchestration,
very few had experience with event-based architectures and
service choreography. And although most of the interviewees
understood that microservice architecture encourages choreo-
graphy over orchestration, there was a general consensus that
some level of orchestration may be required with more com-
plex business processes.

Testing
While individual microservices may be independently devel-
oped, tested (analogous to traditional unit testing), and
deployed, microservice architecture presupposes multiple
interdependent/coordinating microservices. As a result, when-
ever an individual microservice is changed, it needs to be
tested together with any other microservices that may be
impacted. This may include integration, system, and accep-
tance testing. Furthermore, testing of distributed systems built
using microservice architecture is inherently more difficult
Figure 3. microservices across the plan, build, run organizational structure. than testing of centralized monoliths. One of the key
8 S. BAŠKARADA ET AL.

difficulties associated with distributed systems is that they are context of microservices include SaaS and COTS applications,
inherently less stable than non-distributed systems, and that organizational culture, governance, organizational structure,
trying to anticipate all possible modes of failure is pretty testing, and architecture-related performance.
much impossible. In addition, many of the non-functional Our findings further indicate that not all types of corporate
failure modes may be difficult to automate in a DevOps systems may equally benefit from microservice architecture;
microservice architecture, and when automated, comprehen- there was a general consensus that large corporate systems of
sively testing a large microservices application can be very record (e.g., ERP and CRM) may not be appropriate targets
slow. for microservice architecture. Similarly, while organizations
that predominantly deal with ICT services (e.g., Amazon,
Netflix, and the Guardian) may find it easier to take advan-
Performance
tage of microservice architecture, many traditional organiza-
Given the distributed nature of microservice architecture, tions (where IT is merely seen as an enabler or “necessary
and especially the fact that what would have been method/ evil”) may struggle to overcome organizational challenges
procedure calls in a monolith are replaced with RESTful associated with adoption of microservices and underpinning
API calls over a network, many of the interviewees were DevOps methodologies.
concerned about potential performance penalties associated Like any study, this paper has a number of limitations. The
with microservice architectures. This concern was amplified obvious limitation is that as a qualitative study we are unable
by the fact that few microservice-based applications are to claim that our findings apply across any particular popula-
currently available as COTS products with clearly specified tions. On the other hand, we are not claiming any universality
performance parameters. Developing distributed microser- with our findings. Instead, we are simply presenting a range of
vice-based applications in-house was seen as particularly concerns identified from a non-representative sample. This
risky since estimating the likely performance of such appli- paper aims to add to the literature by identifying and discuss-
cations was seen as being more difficult. Several intervie- ing a range of issues associated with adoption and implemen-
wees raised a concern relating to reporting from tation of microservice architecture. To what extent these
microservice-based applications. Given that data are distrib- issues apply to organizations more generally may be investi-
uted across numerous microservices/databases, any complex gated in future research if and when required.
reporting may require significant inter-microservice com-
munication through RESTful APIs, which may introduce
significant performance penalties.
References
Conclusion 1. Singh J, Sharma G, Hill J, Shnackenberg A. Organizational agility:
what it is, what it is not, and why it matters. in Academy of
Microservice architecture is the latest architectural trend Management Proceedings. 2013. Academy of Management.
that has been significantly gaining in popularity over the 2. Dragoni N, Giallorenzo S, Lafuente AL, Mazzara M, Montesi F,
last few years. While there is a lot of hype associated with Mustafin R, Safina L. Microservices: Yesterday, today, and tomor-
microservices, and while many vendors and enthusiasts row, in Present and Ulterior Software Engineering; Cham,
Switzerland: Springer:2017. 195–216.
promote a range of architectural benefits purportedly 3. Newman S. Building microservices: Designing fine-grained sys-
associated with microservices, with the exception of a tems. Sebastopol, CA, USA: O’Reilly Media, Inc; 2015.
small number of frequently mentioned success stories 4. Dragoni N, Lanese I, Larsen ST, Mazzara M, Mustafin R, Safina L.
(e.g., Amazon, Netflix, and the Guardian), few organiza- Microservices: how to make your application scale. in International
tions seems to have refactored or developed from scratch Andrei Ershov Memorial Conference on Perspectives of System
Informatics. 2017. Springer.
large organizational systems of record or systems of dif- 5. Balalaie A, Heydarnoori A, Jamshidi P. Microservices architecture
ferentiation using microservice architecture. Our study enables devops: migration to a cloud-native architecture. IEEE
with 19 experienced ICT architects has found that there Software. 2016;33:42–52.
is a lot of professional uncertainty associated with adop- 6. Hasselbring W Microservices for scalability: keynote talk abstract.
tion of microservice architecture. Although most of the in Proceedings of the 7th ACM/SPEC on International Conference
on Performance Engineering. 2016. ACM.
interviewees understood purported benefits of microser- 7. O’Connor R, Elger P, Clarke PM. Exploring the Impact of
vice architectures, namely improved development/deploy- Situational Context—A Case Study of a Software Development
ment agility and operational scalability, they also had Process for a Microservices Architecture. in Software and System
significant reservations relating to a range of technical Processes (ICSSP), 2016 IEEE/ACM International Conference on.
and organizational aspects of microservice adoption. 2016. IEEE.
8. Lewis J, Fowler M. Microservices: a definition of this new archi-
While some of the opportunities and challenges discussed tectural term. 2014 Feb 2018; Available from: https://martinfowler.
in this paper have also been identified in other studies, others, com/articles/microservices.html.
to the best of our knowledge, provide a novel contribution to 9. Thönes J. Microservices. IEEE Software. 2015;32:116–116.
the microservices literature. Factors discussed in other studies 10. Hunter T II. Advanced Microservices: A Hands-on Approach to
include development/deployment agility,10 operational Microservice Infrastructure and Tooling. San Francisco,
California, USA: Apress; 2017.
scalability,9 lack of relevant skills,7 master data management,12 11. Vural H, Koyuncu M, Guney S. A Systematic Literature Review on
decomposing/refactoring,20 and orchestration and Microservices. in International Conference on Computational
choreography.19 Factors not previously considered in the Science and Its Applications. 2017. Springer.
 JOURNAL OF COMPUTER INFORMATION SYSTEMS 9

12. MuleSoft. Best Practices for Microservices. 2018 Feb; Available from: 22. Kitchenham BA, Dyba T, Jorgensen M. Evidence-based software
https://www.mulesoft.com/lp/whitepaper/api/microservices-best- engineering. in Proceedings of the 26th international conference on
practices. software engineering. 2004. IEEE Computer Society.
13. Bass L, Weber I, Zhu L. DevOps: A Software Architect’s 23. Pan SL, Tan B. Demystifying case research: a structured–pragmatic–
Perspective. New York, NY: Addison-Wesley Professional; 2015. situational (SPS) approach to conducting case studies. Inf Organ.
14. Pahl C, Jamshidi P. Microservices: A Systematic Mapping Study. in 2011;21:161–76.
6th International Conference on Cloud Computing and Services 24. Baškarada S. Qualitative Case Study Guidelines. Qual Rep.
Science (CLOSER 2016). 2016. 2014;19:1–25.
15. Alshuqayran N, Ali N, Evans R. A systematic mapping study in micro- 25. Glaser BG. The constant comparative method of qualitative
service architecture. in Service-Oriented Computing and Applications analysis. Soc Probl. 1965;12:436–45.
(SOCA) IEEE 9th International Conference on. 2016. IEEE. 26. Spradley JP. The ethnographic interview. Fort Worth (TX): Holt,
16. Di Francesco P, Malavolta I, Lago P. Research on architecting micro- Rinehart & Winston; 1979.
services: trends, focus, and potential for industrial adoption. Software 27. Aronson J. A pragmatic view of thematic analysis. The Qualitative
Architecture (ICSA) IEEE International Conference on. 2017. IEEE. Report. 1995;2:1–3.
17. Le VD, Neff MM, Stewart RV, Kelley R, Fritzinger E, Dascalu SM, 28. LeCompte MD. Analyzing qualitative data. Theory Pract.
Harris FC. Microservice-based architecture for the NRDC. Industrial 2000;39:146–54.
Informatics (INDIN), 2015 IEEE 13th International Conference on. 29. Glaser BG, Holton J. Remodeling Grounded Theory. Forum
2015. IEEE. Qualitative Sozialforschung/Forum: Qualitative Social Research.
18. Wilson G Eight fallacies of distributed computing - tech talk. 2015 2004;5(02).
Feb 2018; Available from: http://blog.fogcreek.com/eight-fallacies- 30. Glaser BG, Strauss AL. The Discovery of Grounded Theory.
of-distributed-computing-tech-talk/. London, UK: Weidenfeld and Nicolson; 1967.
19. Dragoni N, Dustdar S, Larsen ST, Mazzara M. Microservices: migration 31. Hruschka DJ, Schwartz D, St. John DC, Picone-Decaro E, Jenkins RA,
of a mission critical system. arXiv preprint arXiv:1704.04173, 2017. Carey JW. Reliability in Coding Open-Ended Data: lessons Learned
20. Taibi D, Lenarduzzi V, Pahl C. Processes, Motivations, and Issues from HIV Behavioral Research. Field Methods. 2004;16(3):307–31.
for Migrating to Microservices Architectures: an Empirical 32. Conway ME. How do committees invent. Datamation.
Investigation. IEEE Cloud Computing. 2017;4:22–32. 1968;14:28–31.
21. Kratzke N, About microservices, containers and their underesti- 33. MacCormack A, Baldwin C, Rusnak J. Exploring the duality
mated impact on network performance. arXiv preprint between product and organizational architectures: a test of the
arXiv:1710.04049, 2017. “mirroring” hypothesis. Res Policy. 2012;41:1309–24.