Migrating towards Microservices: Migration and Architecture

Smells
Andrés Carrasco Brent van Bladel Serge Demeyer
University of Antwerp University of Antwerp University of Antwerp
Antwerp, Belgium Antwerp, Belgium Antwerp, Belgium
andres.carrasco@student.uantwerpen.be brent.vanbladel@uantwerpen.be serge.demeyer@uantwerpen.be

ABSTRACT The microservices architectural style has grown in popular-

Migrating to microservices is an error-prone process with deep pit- ity for the last few years, due to its potential benefits, such as
falls resulting in high costs for mistakes. Microservices is a relatively technology heterogeneity, resilience, scalability, eased deployment,
new architectural style, resulting in the lack of general guidelines productivity, reusability, and repleaceability among others [51].
for migrating monoliths towards microservices. We present 9 com- Moreover, some research has reported reduced complexity, lower
mon pitfalls in terms of bad smells with their potential solutions. coupling, higher cohesion, simpler integration, better reusability,
Using these bad smells, pitfalls can be identified and corrected in and performance increase after migrating to a microservices archi-
the migration process. tecture [9, 27]. However, the benefits of adopting a microservices
architecture come with the complexities of distributed systems,
CCS CONCEPTS such as the need for resilience, scaling, and data consistency [43].
Many new technologies have emerged in recent years for deal-
• Software and its engineering → Extra-functional proper-
ing with these complexities, such as containerization, automated
ties; Software architectures; Software creation and management;
deployment, and scaling of applications; these technologies are con-
sidered enablers for the growth of microservices. Moreover, rapid
KEYWORDS provisioning, basic monitoring and rapid application deployment
Architecture Smells, Migration Smells, MicroServices, Literature are prerequisites for any microservices application [21]. Such re-
Study quirements are inherently available in the cloud, thus becoming
ACM Reference Format: the default home for microservices.
Andrés Carrasco, Brent van Bladel, and Serge Demeyer. 2018. Migrating Regardless of the complexities inherent in microservices, a trend
towards Microservices: Migration and Architecture Smells. In Proceedings on migrating monolithic applications towards microservices archi-
of the 2nd International Workshop on Refactoring (IwoR ’18), September 4, tectures has become apparent. Multiple development teams have
2018, Montpellier, France. ACM, New York, NY, USA, 6 pages. https://doi.org/ published their experience migrating to a microservices architec-
10.1145/3242163.3242164 ture, including some success stories. However, due to the nature of
microservices, following such advices may not be suitable for every
1 INTRODUCTION strategy. Therefore, publicly available knowledge in this migration
Microservices is an architectural style for developing an application trend, such as best practices, success stories, and pitfalls should be
in independently and automatically deployable services communi- collected. The subsequent consolidation of this knowledge in form
cating with lightweight mechanisms [23]. The term microservices of migration and architecture smells can provide useful information
has become a buzzword nowadays. While some debate is still on- for teams looking to migrate their applications into microservices.
going on whether microservices is an architectural style itself, or In this paper, we present 5 new architecture and 4 new migra-
simply a way of doing Service-Oriented Architectures (SOA), there tion bad smells found by digesting 58 different sources from the
is a concrete distinction on its realization [61]. academia and grey literature. The rest of this paper is structured
There is not a one-size-fits-all strategy for microservices, i.e., as follows. Section 2 provides an overview of related work. Sec-
each solution has a different strategy in place. This plethora of tion 3 presents the research questions, and Section 4 explains our
strategies makes the outlining of its characteristics difficult. How- methodology. Section 5 presents the 5 new architecture bad smells,
ever, some characteristics are common among microservices, such whereas the 4 new migration bad smells are presented in Section 6.
as the componentization via services, smart endpoints with dumb Section 7 discusses the threats to validity, and Section 8 concludes.
pipes, and decentralization [23].

Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
2 RELATED WORK
for profit or commercial advantage and that copies bear this notice and the full citation Refactoring is part of the Software Engineering Body of Knowledge
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
(SWEBOK). Initially refactoring was intended for restructuring
to post on servers or to redistribute to lists, requires prior specific permission and/or a code. However, Stal extended the concept of refactoring to include
fee. Request permissions from permissions@acm.org. software architecture refactoring [53]. When refactoring an archi-
IwoR ’18, September 4, 2018, Montpellier, France
© 2018 Association for Computing Machinery.
tecture, the software is changed in a holistic manner for addressing
ACM ISBN 978-1-4503-5974-0/18/09. . . $15.00 architecture smells.
https://doi.org/10.1145/3242163.3242164

1
IwoR ’18, September 4, 2018, Montpellier, France Andrés Carrasco, Brent van Bladel, and Serge Demeyer

The microservices architecture is a new architectural style for Table 1: Search Results
developing an application in independently and automatically de-
ploying services [23]. As such, development teams wishing to adopt Academic Literature Grey Literature
this new architecture must migrate their existing systems. In order refactoring microservices 24 16
migrating microservices 10 8
to investigate the migration process towards microservices, Taibi et
Total 34 24
al. surveyed 21 practitioners who adopted the microservices archi-
tecture [56]. This survey had the goal of determining the reason for
the migration and the issues presented in the process. The reason processes could help individuals avoid or fix bad smells in
reported for the migration was driven by technical motivations, their design.
such as reduced maintenance, and scalability. Whereas the main • Approach - From the gathered publications, common best
issues included: the requirement of experienced developers for the practices and pitfall solutions could be extracted and ex-
inherent complexity in the architectural style, economical burden trapolated. These findings are presented as potential so-
due to the required effort for adopting microservices, and the re- lutions for the architectural and migration bad smells de-
sistance of older developers and architects to new technologies. tected in RQ1.
This showed experts the need for migration patterns with the goal
of aiding the migration towards microservices. Taibi et al. subse- 4 EXPERIMENTAL SETUP
quently conducted a systematic mapping study for gathering a The sources are gathered using two search engines, namely Google
catalog of principles and patterns for microservices [57]. However, Scholar and Google. Google Scholar allows the searching of aca-
their focus was on gathering architectural patterns for compos- demic literature by search terms, whereas the Google engine allows
ing a catalog, rather than identifying the potential pitfalls when the searching of grey literature on the Internet. All activities re-
migrating towards microservices. garding the search are performed in a portable version of Firefox.
To aid practitioners in identifying the potential pitfalls, Taibi This ensures the traceability of our findings through its browsing
and Lenarduzzi defined 11 bad smells related to the microservices history. Moreover, all found Internet sources are downloaded and
architecture [55]. These smells were identified by analyzing 265 persisted in HTML and PNG formats, alongside an entry in a Bibtex
bad practices experienced by 72 practitioners. However, their inves- database. Each source is tagged with the search terms utilized to
tigation does not include the advice from the state-of-the-art, only find the source, as well as the type of literature.
from practitioners. Garousi et al. raised the need for including both In each of the search engines, the following search terms are
state-of-the-art and -practice sources when performing research utilized for finding relevant literature: refactoring microservices and
in Software Engineering. When focusing exclusively on research migrating microservices. In Google Scholar, the results of both search
contributions an established body of knowledge is removed [25]. terms are investigated incrementally by time of publication starting
Therefore, a literature survey of best practices for microservices, from 2014 after the term was defined in the grey literature by Fowler
including both academic and grey literature is needed for identi- and Lewis [23]. Each of the search results were investigated and
fying more potential pitfalls and their solutions. In this work, we then discriminated by their relevancy through the abstract. Next,
perform such a literature survey. for searching grey literature in the Google engine, relevant entries
are typically within the first few result pages. Therefore, we stop our
3 RESEARCH QUESTIONS search whenever the results fail to include lessons learned or best
practices. Lastly, our search was performed at the end of April 2018,
RQ1) What architecture and migration bad smells are present in
any literature published after that date has not been considered.
microservices?
Our search yielded in total 58 relevant sources; 34 (58, 62%)
• Motivation - Identifying the bad smells in the microser-
academic publications and 24 (41, 37%) grey literature sources.
vices architecture and migration processes would allow
When searching for refactoring microservices we found 24 academic
individuals to make better decisions when taking apart
sources and 16 from the grey literature. Moreover, when searching
their monolithic applications, aiding their refactoring ef-
for migrating microservices we found 10 academic sources and 8
forts.
from the grey literature. In Table 1 our findings are summarized by
• Approach - Gathering publications from the Academia and
search term and source. Finally, the smells in the following section
grey literature explaining their lessons learned while refac-
were extrapolated from all the relevant sources.
toring monoliths into microservices, allows us to extract
and extrapolate common pitfalls. Moreover, the inclusion
5 ARCHITECTURE SMELLS
or exclusion of literature is decided by its contribution to
the general proper architectural and migration practices 5.1 Single Layer Teams
for microservices. Finally, this knowledge is consolidated Description: Conway’s Law states that a system’s design structure
in the form of architectural and migration bad smells. is a mirror of the organization communication’s structure that
designs the system [15]. If a team is divided by layers, e.g. a team
RQ2) How can architecture and migration bad smells in microser- for UI, Application Logic, and Database, simple changes can require
vices be avoided? time and effort to approve between the teams. Therefore, a team
• Motivation - Identifying potential solutions to the bad may introduce logic in whatever layer the have access to. Although
smells in the microservices architecture and migration this smell is not unique to microservices, its existence may be

2
Migrating towards Microservices: Migration and Architecture Smells IwoR ’18, September 4, 2018, Montpellier, France

more pronounced in them. Each service ought to be completely Academic Sources: [4–6, 8, 10, 11, 18, 19, 34, 36, 43, 47, 57, 58, 61,
independent from the others, however, teams might be tempted 62]
to cram their responsibilities on a larger service and make other Grey Literature Sources: [7, 13, 21, 35, 39, 45, 49]
services dependent to simplify their work. This goes against the
independence of microservices and therefore should be avoided.
5.4 Dismiss Documentation
Solution: Split up cross-functional teams by service. Each team
should be composed of the different skills required for the full Description: Documenting any application is generally a good
development of the service. This ensures the independence of each idea. However, this task is often overlooked or not maintained
team and consequently the service. However, coordination between at all, leading to inconsistent and outdated documentation. This
the development teams cannot be ignored. smell is valid for any software system, however, in microservices
documenting the exposed API is particularly important. With the
Academic Sources: [1, 5, 9–11, 19, 36, 37, 43, 47] increased number of independent services, the overview of the sys-
Grey Literature Sources: [2, 23, 26, 32, 35] tem can be easily lost. Moreover, when implementing microservices
with multiple teams the cooperation could be hindered without
proper documentation.
5.2 Greedy Service Container Solution: Utilize API in-code documentation frameworks, such as
Description: DevOps practices align with the goals of microser- Swagger, when possible. Otherwise ensure each team is responsible
vices [5]. For instance, Continuous Delivery allows the automated in maintaining a published API for their service.
deployment of a software system on-demand. This automation is
considered to be essential for microservices, especially when con- Academic Sources: [4, 19, 20, 43]
sidering a highly-scalable system. Containerization reduces the Grey Literature Sources: [7, 35, 52, 61]
time to deployment, therefore, it is considered as one of the main
enablers for the microservices architectural style. Not using them
adds a whole new level of complexity to the management and or- 5.5 Grinding Dusty or Coarse Services
chestration of the application. However, they still require time for Description: A monolith must be broken down into services, for
their setup. A team looking to cut corners might define a container this the proper granularity must be determined. This depends on
for all the application to simplify the setup. However, this makes the what the application actually is doing and the wrong granularity
container heavier and removes the independence of the services. can have profound side-effects. If you have a too coarse granularity
the benefits of microservices might actually not be worth it, while
Solution: Use containers per service. This allows the reduction having a too fine granularity might introduce performance issues
of the time to deployment, as well as the automation of resource due to network latency or other problems.
allocation. Moreover, having a container per service aids the scala-
bility of the system, as they can be easily automated for replication. Solution: The services to be extracted from the monolith can be de-
Even though other approaches exist, such as full virtualization with termined with Domain-Driven Design techniques, such as Bounded
an image, they are generally slow to create and time consuming. Context [43, 59]. Bounded Context presents a good initial approach
Therefore, the general consensus is to utilize containers in the for defining service granularity. However, the resulting granularity
microservices architecture. might not be the appropriate for all applications throughout their
evolution. Therefore, microservices must be continuously moni-
Academic Sources: [4–6, 8, 10–12, 18–20, 27, 28, 34, 36, 38, 43, 46, tored and potentially merging or splitting them if it would aid the
47, 51, 56–58, 61] overall performance of a system.
Grey Literature Sources: [7, 14, 16, 30–32, 35, 39, 41, 54]
Academic Sources: [27, 33, 40, 42, 43]
Grey Literature Sources: [17, 22, 23, 29, 45]
5.3 Single DevOps Toolchain
Description: Microservices architecture require DevOps toolchains,
6 MIGRATION SMELLS
such as continuous delivery, continuous integration, monitoring,
and orchestration. Typically a monolith is split up into multiple ser- 6.1 Thinking Microservices Are a Silver Bullet
vices, for which DevOps toolchains must be independently created. Description: However promising microservices seem to be, their
However, a time-pressured team might try cut corners and define advantages come with many inherent complexities and challenges
the same pipeline for all microservices. This would remove the at possibly a high cost. Therefore, this architectural style might not
autonomy of the service and remove most if not all of the benefits be worthwhile for many applications.
of the architectural style.
Solution: The potential benefits and downfalls of adopting mi-
Solution: Have a separate autonomous pipeline for each of the croservices must be thoroughly analyzed. Moreover, alternative
microservices. This means having the complete DevOps toolchain solutions without microservices should also be drafted. All potential
per service, allowing it to be autonomously scaled, monitored, de- solutions are then to be compared. The decision of proceeding with
veloped, etc., from other services. the migration, can be taken if after the analysis the microservices

3
IwoR ’18, September 4, 2018, Montpellier, France Andrés Carrasco, Brent van Bladel, and Serge Demeyer

architecture still seems to be the best solution. However, many is- 6.4 Forgetting about the CAP Theorem
sues and pitfalls may arise in the process. Therefore, the migration Description: Brewer’s CAP Theorem states that a distributed data
process must be planned with great care. Otherwise, the benefits store cannot simultaneously provide more than two of the follow-
of microservices can be outweighed by the unexpected costs of ing guarantees: Consistency, Availability, and Partition tolerance.
mistakes. Due to the nature of microservices, the trade-off scale is tipped
Academic Sources: [5, 6, 11, 20, 36, 43, 56] towards Availability and Partition tolerance, i.e. we have eventual
Grey Literature Sources: [30, 60] consistency.

Solution: While there is no solution for ensuring consistency at all

6.2 Rewrite All Services into Microservices at times, being aware of it and planning for it is critical in microser-
Once vices. For instance, working with inconsistent states and implement-
Description: Rewriting any application is not trivial and often ing ways to detect and correct such inconsistencies is a possible
not a good idea. Many new faults can be inadvertently introduced, solution. Utilizing Domain-Driven Design practices or Command
leading to unnecessary risks. Thus, the best approach for migrating Query Responsibility Segregation (CQRS) can help mitigate data in-
monoliths towards microservices is incrementally, i.e., service by consistency by limiting the shared data between services. However,
service. if consistency at all times is of big importance, the microservices
architecture might not be the proper strategy.
Solution: The services of the monolith must be identified by tech-
niques from Domain-Driven Design (DDD), such as the Bounded
Context pattern [43, 59]. Through Bounded Context large systems Academic Sources: [8, 10, 11, 18, 24, 34, 36, 43, 57, 61]
can be modeled according to domains, these domains are considered Grey Literature Sources: [23, 35, 44, 50]
to be a microservice each. This ensures that a change or addition
of functionality is isolated to a domain or in this case a microser- 7 THREATS TO VALIDITY
vice. Moreover, having multiple bounded contexts in a microservice
should be avoided. Once the services have been identified, they 7.1 Conclusion Validity
should be gradually removed from the monolith and transformed To ensure the validity of our conclusions to a reasonable extent,
into microservices. The migration should be started with a sim- we included all the relevant sources that lead to our conclusions
ple service for allowing the development team to gain experience for each of the presented bad smells. Moreover, both academic
building their first microservice. Even though the extracted service and grey literature is included in the research to ensure a proper
is simple, the monolith has to a certain degree been reduced in heterogeneity.
complexity. By continuously following this process iteratively, the
monolith will gradually be transformed into microservices.
7.2 Internal Validity
Academic Sources: [5, 12, 43, 56] Our search is in no way exhaustive, relevant sources for the research
Grey Literature Sources: [2, 3, 22, 26, 39, 41, 45, 48, 50, 50] may have been excluded, as the inclusion and exclusion of sources
were based on our judgment and experience. However, in hopes
for repeatability of results, search engines alongside search terms
6.3 Learn as You Go were reported.
Description: With the complexities inherent in distributed sys-
tems, putting together a team of inexperienced developers in dis-
tributed systems is generally not a good idea. Their inexperience 7.3 Construct Validity
may result in higher cost and development time, as they battle with Our general inexperience conducting academic investigations is
the pitfalls of distributed systems. This smell is not unique to mi- a threat to the validity of our research. However, the RQs and
croservices, it can be present on the development of any software. methodology was discussed with experienced researchers in the
However, the learning curve inherent to microservices might be field. This grant us a reasonable degree of confidence in the validity
too steep for inexperienced developers, as it requires knowledge in of our research.
many different aspects of the development.
Solution: Ensure there are at least a couple of experienced devel- 7.4 External Validity
opers with distributed systems in the team. If this is not possible Our research is limited to 58 sources. Although gathering a proper
and adopting the microservices strategy is a must, start with a amount of sources was attempted, we cannot assume our findings
small team developing one simple microservice. Once this team are a digestion of all best practices, success stories and pitfalls of
has enough experience, separate them into newly created teams migrating monoliths towards microservices. However, we included
with other developers. In this way, some developers would have literature from both state-of-the-art and -practice to a reasonable
acquired some experience and can lead the new teams. extent. As future work, the usefulness and understandability of
Academic Sources: [5, 6, 43, 57] the presented bad smells should be evaluated and our conclusions
Grey Literature Sources: [22, 49] reevaluated.

4
Migrating towards Microservices: Migration and Architecture Smells IwoR ’18, September 4, 2018, Montpellier, France

8 CONCLUSIONS [17] Neil Crawford. 2016. Extracting a Microservice from a Monolith. https:
//tech.findmypast.com/extracting- a- microservice- from- a- monolith. https:
We presented a brief overview of the apparent trend in both the //tech.findmypast.com/extracting-a-microservice-from-a-monolith Accessed 7.
academia and industry of migrating monolithic architectures to- May 2018.
[18] Nicola Dragoni, Schahram Dustdar, Stephan Thordal Larsen, and Manuel Mazzara.
ward microservices. Next, we presented 5 new architectural and 4 2017. Microservices: Migration of a Mission Critical System. CoRR abs/1704.04173
new migration bad smells by digesting 58 different sources from (2017). arXiv:1704.04173 http://arxiv.org/abs/1704.04173
the academia and grey literature, extending the list of 11 smells [19] Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara,
Fabrizio Montesi, Ruslan Mustafin, and Larisa Safina. 2017. Microservices: yester-
proposed by Taibi and Lenarduzzi [55]. Moreover, we presented a day, today, and tomorrow. In Present and Ulterior Software Engineering. Springer,
possible solution for each of the 9 smells as discussed in the sources. 195–216.
Our contribution provides a foundation for actionable information [20] Nicola Dragoni, Ivan Lanese, Stephan Thordal Larsen, Manuel Mazzara, Ruslan
Mustafin, and Larisa Safina. 2018. Microservices: How To Make Your Appli-
on the successful refactoring of monolithic applications towards cation Scale. In Perspectives of System Informatics, Alexander K. Petrenko and
microservices. Andrei Voronkov (Eds.). Springer International Publishing, Cham, 95–104.
[21] Martin Fowler. 2014. MicroservicePrerequisites. https://martinfowler.com/
bliki / MicroservicePrerequisites.html. https : / / martinfowler.com / bliki /
REFERENCES MicroservicePrerequisites.html Accessed 16. May 2018.
[1] Mohsen Ahmadvand and Amjad Ibrahim. 2016. Requirements Reconciliation for [22] Martin Fowler. 2015. MonolithFirst. https : / / martinfowler.com / bliki /
Scalable and Secure Microservice (De)composition. In 2016 IEEE 24th International MonolithFirst.html. https://martinfowler.com/bliki/MonolithFirst.html Ac-
Requirements Engineering Conference Workshops (REW). 68–73. https://doi.org/ cessed 7. May 2018.
10.1109/REW.2016.026 [23] Martin Fowler and James Lewis. 2014. Microservices, a definition of this new ar-
[2] Saba Anees. 2016. How to Migrate to Microservices. https : / / chitectural term. http://martinfowler.com/articles/microservices.html. Accessed
blog.appdynamics.com/product/how- to- migrate- to- microservices. https: 05.04.2018.
//blog.appdynamics.com/product/how-to-migrate-to-microservices Accessed 7. [24] Andrei Furda, Colin Fidge, Olaf Zimmermann, Wayne Kelly, and Alistair Barros.
May 2018. 2017. Migrating Enterprise Legacy Source Code to Microservices: On Multi-
[3] Hendry Anwar. 2017. Refactoring Monolith to Microservices. http : Tenancy, Statefulness and Data Consistency. IEEE Software PP, 99 (2017), 1–1.
/ / us.arvato.com / blog / refactoring - monolith - to - microservices. http : / / https://doi.org/10.1109/MS.2017.440134612
us.arvato.com/blog/refactoring-monolith-to-microservices Accessed 7. May [25] Vahid Garousi, Michael Felderer, and Mika V Mäntylä. 2016. The need for
2018. multivocal literature reviews in software engineering: complementing systematic
[4] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. 2015. Microservices literature reviews with grey literature. In Proceedings of the 20th International
migration patterns. Technical report, Tech. Rep. TR-SUTCE-ASE-2015-01, Auto- Conference on Evaluation and Assessment in Software Engineering. ACM, 26.
mated Software Engineering Group (2015). [26] Johannes Giani. 2018. 6 Things to Consider for Microservice Migration. https:
[5] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. 2016. Microservices //www.inovex.de/blog/microservice-migration. https://www.inovex.de/blog/
Architecture Enables DevOps: An Experience Report on Migration to a Cloud- microservice-migration Accessed 7. May 2018.
Native Architecture. IEEE Software 33, 3 (2016), 42–52. [27] Jean-Philippe Gouigoux and Dalila Tamzalit. 2017. From Monolith to Microser-
[6] Armin Balalaie, Abbas Heydarnoori, and Pooyan Jamshidi. 2016. Migrat- vices: Lessons Learned on an Industrial Migration to a Web Oriented Architecture.
ing to Cloud-Native Architectures Using Microservices: An Experience Re- In 2017 IEEE International Conference on Software Architecture Workshops (ICSAW).
port. In Advances in Service-Oriented and Cloud Computing, Antonio Celesti 62–65. https://doi.org/10.1109/ICSAW.2017.35
and Philipp Leitner (Eds.). Springer International Publishing, Cham, 201–215. [28] Claudio Guidi, Ivan Lanese, Manuel Mazzara, and Fabrizio Montesi. 2017. Mi-
https://link.springer.com/chapter/10.1007%2F978-3-319-33313-7_15 croservices: A Language-Based Approach. Springer International Publishing, Cham,
[7] Kyle Brown. 2016. Refactoring for microservices. https://www.ibm.com/ 217–225. https://doi.org/10.1007/978-3-319-67425-4_13
developerworks / cloud / library / cl - refactor - microservices - bluemix - trs - 1 / [29] Arun Gupta. 2015. Microservice Design Patterns. http://blog.arungupta.me/
index.html. https://www.ibm.com/developerworks/cloud/library/cl-refactor- microservice-design-patterns/. http://blog.arungupta.me/microservice-design-
microservices-bluemix-trs-1/index.html Accessed 27. Apr. 2018. patterns/ Accessed 7. May 2018.
[8] Kyle Brown and Bobby Woolf. 2016. Implementation Patterns for Microservices [30] Arun Gupta. 2015. Monolithic to Microservices Refactoring for Java EE Applica-
Architectures. In Proceedings of the 23rd Conference on Pattern Languages of tions. http://blog.arungupta.me/monolithic-microservices-refactoring-javaee-
Programs. The Hillside Group, 7. applications. http://blog.arungupta.me/monolithic-microservices-refactoring-
[9] Antonio Bucchiarone, Nicola Dragoni, Schahram Dustdar, Stephan T Larsen, and javaee-applications Accessed 7. May 2018.
Manuel Mazzara. 2017. From Monolithic to Microservices: An experience report. [31] Arun Gupta. 2015. ZooKeeper for Microservice Registration and Discovery.
Technical Report. Technical University of Denmark, Örebro University, TU Wien, http://blog.arungupta.me/zookeeper-microservice-registration-discovery. http:
Danske Bank, and Innopolis University. //blog.arungupta.me/zookeeper-microservice-registration-discovery/ Accessed
[10] Tomas Cerny, Michael J. Donahoo, and Michal Trnka. 2018. Contextual 7. May 2018.
Understanding of Microservice Architecture: Current and Future Directions. [32] Grzegorz Gwoźdź. 2018. How can you refactor a monolithic application
SIGAPP Appl. Comput. Rev. 17, 4 (Jan. 2018), 29–45. https://doi.org/10.1145/ into microservices? https : / / medium.com / @NeotericEU / how - can - you -
3183628.3183631 refactor-a-monolithic-application-into-microservices-2eef8e323840. https://
[11] Lianping Chen. 2018. Microservices: Architecting for Continuous Delivery and medium.com/@NeotericEU/how-can-you-refactor-a-monolithic-application-
DevOps. In Proceedings of the IEEE International Conference on Software Architec- into-microservices-2eef8e323840 Accessed 7. May 2018.
ture (ICSA 2018) (03 2018). [33] Sara Hassan and Rami Bahsoon. 2016. Microservices and Their Design Trade-
[12] Fan Chen-Yuan and Ma Shang-Pin. 2017. Migrating Monolithic Mobile Ap- Offs: A Self-Adaptive Roadmap. In 2016 IEEE International Conference on Services
plication to Microservice Architecture: An Experiment Report. In 2017 IEEE Computing (SCC). 813–818. https://doi.org/10.1109/SCC.2016.113
International Conference on AI Mobile Services (AIMS). 109–112. https://doi.org/ [34] Munezero Immaculee Joselyne, Benjamin Kanagwa, and Joseph Balikuddembe.
10.1109/AIMS.2017.23 2017. A framework to Modernize SME Application in Emerging Economies:
[13] Matt Chotin. 2018. Top 3 Challenges of Adopting Microservices as Part of Microservice Architecture Pattern Approach. In Microservices 2017.
Your Cloud Migration. https://devops.com/top- 3- challenges- of- adopting- [35] Vivek Juneja. 2016. From Monoliths to Microservices: An Architectural Strat-
microservices- as- part- of- your- cloud- migration. https://devops.com/top- egy. https:/ /thenewstack.io/from- monolith - to- microservices. https: //
3- challenges- of- adopting- microservices- as- part- of- your- cloud- migration thenewstack.io/from-monolith-to-microservices Accessed 7. May 2018.
Accessed 7. May 2018. [36] Miika Kalske, Niko Mäkitalo, and Tommi Mikkonen. 2018. Challenges When
[14] Michael Churchman. 2017. Refactoring Your App with Microservices - Rancher Moving from Monolith to Microservice Architecture. In Current Trends in Web
Labs. https://rancher.com/refactoring-app-microservices. https://rancher.com/ Engineering, Irene Garrigós and Manuel Wimmer (Eds.). Springer International
refactoring-app-microservices Accessed 27. Apr. 2018. Publishing, Cham, 32–47.
[15] Melvin E Conway. 1968. How do committees invent. Datamation 14, 4 (1968), [37] Alessandra Levcovitz, Ricardo Terra, and Marco Tulio Valente. 2016. Towards
28–31. a Technique for Extracting Microservices from Monolithic Enterprise Systems.
[16] Pedro Costa. 2018. Migrating to Microservices and Event-Sourcing: the Dos CoRR abs/1605.03175 (2016). arXiv:1605.03175 http://arxiv.org/abs/1605.03175
and Dont’s. https://hackernoon.com/migrating-to-microservices-and-event- [38] David S. Linthicum. 2016. Practical Use of Microservices in Moving Workloads to
sourcing-the-dos-and-donts-195153c7487d. https://hackernoon.com/migrating- the Cloud. IEEE Cloud Computing 3, 5 (Sept 2016), 6–9. https://doi.org/10.1109/
to-microservices-and-event-sourcing-the-dos-and-donts-195153c7487d Ac- MCC.2016.114
cessed 7. May 2018.

5
IwoR ’18, September 4, 2018, Montpellier, France Andrés Carrasco, Brent van Bladel, and Serge Demeyer

[39] Abhijit Mandal. 2018. Migrating to Microservices. https : / / dzone.com / [50] Rafael Romão. 2017. Microservices Architecture As A Large-Scale Refactoring
articles/migrating- to- microservices. https://dzone.com/articles/migrating- Tool. http://blog.avenuecode.com/microservices-architecture-as-a-large-scale-
to-microservices Accessed 7. May 2018. refactoring-tool. http://blog.avenuecode.com/microservices-architecture-as-a-
[40] Genc Mazlami, Jürgen Cito, and Philipp Leitner. 2017. Extraction of Microser- large-scale-refactoring-tool Accessed 7. May 2018.
vices from Monolithic Software Architectures. In Web Services (ICWS), 2017 IEEE [51] Tasneem Salah, Mohamed Jamal Zemerly, Chan Yeob Yeun, Mahmoud Al-Qutayri,
International Conference on. IEEE, 524–531. and Yousof Al-Hammadi. 2016. The evolution of distributed systems towards
[41] Ben Morris. 2015. Refactoring large monoliths to microservices: strategies, risks microservices architecture. In 2016 11th International Conference for Internet
and pragmatic reality. http://www.ben-morris.com/refactoring-large-monoliths- Technology and Secured Transactions (ICITST). 318–325. https://doi.org/10.1109/
to- microservices- strategies- risks- and- pragmatic- reality. http://www.ben- ICITST.2016.7856721
morris.com/refactoring- large- monoliths- to- microservices- strategies- risks- [52] Ryan Scheuermann. 2017. 9 Tips for a Painless Microservices Migration. http:
and-pragmatic-reality Accessed 7. May 2018. //engineering.invisionapp.com/post/painless-microservices-migration. http:
[42] Ola Mustafa, Jorge Marx Gómez, Mohamad Hamed, and Hergen Pargmann. 2018. //engineering.invisionapp.com/post/painless-microservices-migration Accessed
GranMicro: A Black-Box Based Approach for Optimizing Microservices Based 7. May 2018.
Applications. In From Science to Society, Benoît Otjacques, Patrik Hitzelberger, Ste- [53] Michael Stal. 2007. Software Architecture Refactoring. In Tutorial in The Inter-
fan Naumann, and Volker Wohlgemuth (Eds.). Springer International Publishing, national Conference on Object Oriented Programming, Systems, Languages and
Cham, 283–294. Applications.
[43] Sam Newman. 2015. Building Microservices: Designing Fine-Grained Systems. [54] Chris Stetson. 2017. How To ’Refactor’ Monolithic Applications into Microser-
O’Reilly Media. vices. http://www.datacenterknowledge.com/archives/2017/06/05/refactor-
[44] Pramod Nikam. 2017. How will you design, break and migrate database monolithic-applications-microservices. http://www.datacenterknowledge.com/
matching to microservices? http://techprehension.com/2017/12/31/how- archives/2017/06/05/refactor-monolithic-applications-microservices Accessed 7.
will- you- design- break- and- migrate- database- matching- to- microservices. May 2018.
http://techprehension.com/2017/12/31/how- will- you- design- break- and- [55] Davide Taibi and Valentina Lenarduzzi. 2018. On the Definition of Microservices
migrate-database-matching-to-microservices Accessed 7. May 2018. Bad Smells. IEEE Software vol 35 (05 2018).
[45] Brice Nkengsa. 2016. Migrating from a Monolith to a Microservices Archi- [56] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2017. Processes, Mo-
tecture. https://medium.com/@briceicle/migrating- from- a- monolith- to- a- tivations, and Issues for Migrating to Microservices Architectures: An Em-
microservices- architecture- 99cecf8af366. https://medium.com/@briceicle/ pirical Investigation. IEEE Cloud Computing 4, 5 (September 2017), 22–32.
migrating-from-a-monolith-to-a-microservices-architecture-99cecf8af366 Ac- https://doi.org/10.1109/MCC.2017.4250931
cessed 7. May 2018. [57] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. 2018. Architectural Patterns
[46] Claus Pahl and Pooyan Jamshidi. 2016. Microservices: A Systematic Mapping for Microservices: A Systematic Mapping Study. In 8th International Conference
Study. In Proceedings of the 6th International Conference on Cloud Computing and on Cloud.
Services Science. 137–146. [58] MVLN Venugopal. 2017. Containerized Microservices architecture. International
[47] Florian Rademacher, Sabine Sachweh, and Albert Zündorf. 2017. Differences Journal Of Engineering And Computer Science 6, 11 (2017), 23199–23208.
between Model-Driven Development of Service-Oriented and Microservice Archi- [59] Vaughn Vernon. 2013. Implementing domain-driven design. Addison-Wesley.
tecture. In 2017 IEEE International Conference on Software Architecture Workshops [60] James Ward. 2015. Refactoring to Microservices. https://www.jamesward.com/
(ICSAW). 38–45. https://doi.org/10.1109/ICSAW.2017.32 2015/05/26/refactoring-to-microservices. https://www.jamesward.com/2015/
[48] Chris Richardson. 2016. Refactoring a Monolith into Microservices. https: 05/26/refactoring-to-microservices Accessed 7. May 2018.
//www.nginx.com/blog/refactoring- a- monolith- into- microservices. https: [61] Olaf Zimmermann. 2017. Microservices tenets: Agile approach to service devel-
//www.nginx.com/blog/refactoring-a-monolith-into-microservices Accessed opment and deployment. Computer Science - Research and Development 32, 3 (01
27. Apr. 2018. Jul 2017), 301–310. https://doi.org/10.1007/s00450-016-0337-0
[49] Curtis Rissi. 2015. Thoughts on Migrating to a Microservices Architecture. [62] Christian Zirkelbach, Alexander Krause, and Wilhelm Hasselbring. 2018. On the
http://www.boringgeek.com/thoughts- on- migrating- to- a- microservices- Modernization of ExplorViz towards a Microservice Architecture. In Combined
architecture. http://www.boringgeek.com/thoughts- on- migrating- to- a- Proceedings of the Workshops of the German Software Engineering Conference
microservices-architecture Accessed 7. May 2018. 2018, Vol. Online Proceedings for Scientific Conferences and Workshops. CEUR
Workshop Proceedings, Ulm, Germany. http://eprints.uni-kiel.de/42119/