Design principles, architectural smells and refactorings for microservices: A multivocal review
Antonio Brogi, Davide Neri, Jacopo Soldani, Olaf Zimmermann
TL;DR
This paper systematically reviews literature to identify common architectural smells in microservices and discusses refactoring strategies to address these issues, aiming to improve microservice design and implementation.
Contribution
It provides a comprehensive overview of recognized architectural smells in microservices and proposes refactoring solutions, filling a gap in consolidated knowledge.
Findings
Identified key architectural smells in microservices.
Mapped refactoring strategies to specific smells.
Highlighted the importance of addressing smells for better microservice quality.
Abstract
Potential benefits such as agile service delivery have led many companies to deliver their business capabilities through microservices. Bad smells are however always around the corner, as witnessed by the considerable body of literature discussing architectural smells that possibly violate the design principles of microservices. In this paper, we systematically review the white and grey literature on the topic, in order to identify the most recognised architectural smells for microservices and to discuss the architectural refactorings allowing to resolve them.
Click any figure to enlarge with its caption.
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
\SetWatermarkText
preprint \SetWatermarkScale1
11institutetext: Antonio Brogi, Davide Neri, Jacopo Soldani 22institutetext: University of Pisa, Pisa, Italy. {name}.{surname}@unipi.it 33institutetext: Olaf Zimmermann 44institutetext: University of Applied Sciences of Eastern Switzerland (HSR FHO), Rapperswil, Switzerland. [email protected]
Design principles, architectural smells and refactorings for microservices: A multivocal review
Antonio Brogi
Davide Neri
Jacopo Soldani
Olaf Zimmermann
(Received: date / Accepted: date)
Abstract
Potential benefits such as agile service delivery have led many companies to deliver their business capabilities through microservices. Bad smells are however always around the corner, as witnessed by the considerable body of literature discussing architectural smells that possibly violate the design principles of microservices. In this paper, we systematically review the white and grey literature on the topic, in order to identify the most recognised architectural smells for microservices and to discuss the architectural refactorings allowing to resolve them.
Keywords:
Microservices SOA Architectural principles Architectural smells Refactorings
1 Introduction
Microservices architectures, first discussed by Lewis and Fowler o2-microservices-fowler , bring various advantages such as ease of deployment, resilience, and scaling b1-building-microservices . Many IT companies deliver their core business through microservice-based solutions nowadays, with Amazon, Facebook, Google, LinkedIn, Netflix and Spotify being prominent examples. To deliver on their promises, microservices must be designed in quality and style, which is unfortunately not always the case m26-microservices-pains-gains .
Microservice-based architectures can be seen as peculiar extensions of service-oriented architectures, characterized by an extended set of design principles Pautasso:2017:MSIP ; microservices-tenets-m6 . These principles include shaping services around business concepts, decentralising all development aspects of microservice-based solutions (from governance to data management), adopting a culture of automation, ensuring the independent deployability and high observability of microservices, and isolating failures b1-building-microservices . Key questions are hence:
How to check whether one or more microservices design principles are violated in an application?
Which refactorings can be applied to resolve violations of the principles?
The currently available information on architectural smells indicating possible violations of the design principles of microservices is scattered over a considerable amount of literature. Our objective here is to systematically analyse such literature, in order to identify the most recognised smells, as well as architectural refactorings for resolving the smells occurring in an application pn-arch-ref-cloud . In particular, we focus on the design principles dealing with the dynamic aspects of the interactions between microservices at runtime, i.e., on the process viewpoint, as per the 4+1 viewpoint scheme 4plus1viewpoints . More precisely, we consider the independent deployability of microservices, their horizontal scalability, isolation of failures and decentralisation.
As recommended by Garousi et al. need-multivocal-reviews , to capture both the state of the art and the state of practice in the field, we conducted a multivocal systematic review of the existing literature, including both white literature (i.e., peer-reviewed papers) and grey literature (i.e., blog posts, industrial whitepapers and books). We selected studies, published since 2014 (when the microservice-based architectural style was first discussed o2-microservices-fowler ) until the end of January 2019. Then, following the guidelines for systematic reviews need-multivocal-reviews ; petersen-systematic-reviews , we excerpted a taxonomy of design principles, architectural smells and corresponding refactorings. We then exploited this taxonomy to classify the selected studies, in order to distill the actual recognition of the identified smells and the usage of the corresponding refactorings.
In this paper, we illustrate the results of our study. More precisely, we first present the obtained taxonomy, including seven architectural smells and 16 refactorings, organised by design principles. We then discuss each smell, by illustrating why it can violate the design principle it is associated with, and by showing how to resolve it by means of an architectural refactoring.
We believe that the results presented in this study can provide benefits to both researchers and practitioners interested in microservices. A systematic presentation of the state of the art and practice on architectural smells and refactorings for microservices provides a body of knowledge to develop new theories and solutions, to analyse and experiment research implications, and to establish future research directions. At the same time, it can help practitioners to better understand the currently most recognised architectural smells for microservices, and to choose among the architectural refactorings allowing to resolve such smells. This can have a pragmatic value for practitioners, who can use our study as a starting point for microservices experimentation or as a guideline for day-by-day work with microservices.
The rest of the paper is organised as follows. Sect. 2 defines the research problem and illustrates the research methodology. Sect. 3 presents a taxonomy for design principles, architectural smells and refactorings, which is retaken in Sect. 4 to overview the current state of the art and practice on such smells and refactorings. Sects. 5 and 6 discuss potential threats to the validity of our study and related work, respectively. Finally, Sect. 7 draws some concluding remarks.
2 Setting the stage
2.1 Research problem definition
This survey focuses on the architectural principles of microservices that pertain to the process viewpoint, i.e., dealing with the dynamic aspects of microservices interacting at runtime 4plus1viewpoints . Starting from the principles proposed by Newman b1-building-microservices and by Lewis and Fowler o2-microservices-fowler , and considering the mapping to tenets proposed by Zimmermann microservices-tenets-m6 , we identified four such principles:
- •
The microservices forming an application should be independently deployable.
- •
The microservices forming an application should be horizontally scalable.
- •
Failures should be isolated.
- •
Decentralisation should occur in all aspects of microservice-based applications, from data management to governance.
The objective of this survey is to identify the architectural smells indicating possible violations of such principles, as well as the currently available solutions for refactoring microservice-based architectures in order to resolve the identified smells.
Due to space limitations, we cannot cover all microservices tenets from the literature in this paper. Hence, we decided to focus on four particularly relevant principles, driven by three selection criteria:
Roots in highly significant design time and runtime quality attributes and style-defining elements, 2. 2.
Consequences of not adhering to a principle in terms of technical risk and re-engineering cost, and 3. 3.
Generality, i.e., if these four principles are met, others follow or can be achieved with similar means.
For instance, independent deployability is a defining tenet in most (if not all) definitions of microservices and enables decentralized continuous delivery, thereby meeting criteria (1) and (3). Scalability is a quality attribute (1) and horizontal scalabilty is hard to retrofit (an aspect of (2)). Failure isolation meets criteria (1) and (2). Finally, decentralization is mentioned as crucial (and novel) in many introductions to microservices and enables independent, autonomous decision making, as required to achieve (1) and (3).
2.2 Search for studies
With the objective of capturing the state of the art and practice in the field, we searched for both white literature (i.e., peer-reviewed journal and conference articles) and grey literature (i.e., blog posts, industrial whitepapers and books), in line with what recommended by Garousi et al. need-multivocal-reviews .
The structuring of the search string was done by following the guidelines provided by Petersen et al. petersen-systematic-reviews . We indeed identified the search string guided by the PICO terms of our resarch problem, and the keywords were taken from each aspect of our research problem. Differently from Petersen et al. petersen-systematic-reviews , we did not restrict our focus to specific research settings. By restricting ourselves to certain types of research settings, we could have obtained a biased or incomplete analysis, as some architectural smells or refactorings might have been over-/under-represented for a certain type of study.
As a result, our search string was formed by the following terms:
microservice*
(smell* antipattern* bad practice* pitfall* refactor* reengineer*)
(where ‘*’ matches lexically related terms). The search was restricted to studies published since the beginning of 2014 (when microservices were first proposed by Lewis and Fowler o2-microservices-fowler ) until the end of January 2019 (when the present study was initiated).
The search of white literature was carried out in the following indexing databases: ACM Digital Library, DBLP, EI Compendex, IEEE Xplore, INSPEC, ISI Web of Science, Science Direct, SpringerLink. Given the recency of the field and concerns with indexing, Google Scholar played a key role for the initial selection before the inclusion and exclusion stage. The search for industrial studies was instead carried out in renowned blogs in the software engineering community (such as DZone, InfoQ and TechBeacon), in the blog of ThoughtWorks, and in books published by practitioners.
2.3 Sample selection
The above described search criteria were matched by more than 150 studies, which we carefully screened to keep only those studies that were satisfying both the following inclusion criteria:
- •
A study is to be selected if it presents at least one architectural smell pertaining to one of the considered architectural principles of microservices (i.e., independent deployability, horizontal scalability, isolation of failure, or decentralisation).
- •
A study is to be selected it it presents at least one refactoring for resolving one of the architectural smells it discusses.
The inclusion criteria were defined with the ultimate goal of selecting only representative studies, discussing both the architectural smells (pertaining to the process viewpoint) and their corresponding refactorings.
As a result, studies were selected to be analysed further. The list of references to the selected studies can be found in Table 1, which also classifies them by colour, contribution type and year of publication.
3 A taxonomy for design principles, architectural smells and refactorings
Fig. 1 illustrates a taxonomy for the architectural smells pertaining to the considered design principles, and for the refactorings111For the sake of clarity, in the taxonomy we follow the naming of integration patterns proposed by Hohpe and Woolf eip . allowing to resolve such smells. We obtained our taxonomy by following the guidelines for conducting systematic reviews in software engineering proposed by Petersen et al. petersen-systematic-reviews :
We established the design principles, by aligning them with those pertaining to the process viewpoint (as per microservices-tenets-m6 ). 2. 2.
We identified the architectural smells by performing a first scan of the selected studies. 3. 3.
We excerpted the concrete refactorings directly from the selected studies after additional scans.
The identified design principles, architectural smells and refactorings were manually organised to obtain a taxonomy. The taxonomy underwent various iterations among the authors of this study, and it was submitted for validation to an external expert. This resulted in some corrections and amendments to the first version of the taxonomy, which resulted in the taxonomy displayed in Fig. 1.
4 Architectural smells and refactorings
Table 2 shows the classification of all selected studies based on the taxonomy introduced in Sect. 3. The table provides a first overview of the coverage of design principles, architectural smells and refactorings over the selected studies, despite (for reasons of readability and space) it only displays the classifications over the smells listed in the taxonomy222The detailed classification, displaying each occurrence of each refactoring, is publicly available at https://github.com/di-unipi-socc/microservices-smells-and-refactorings.. Such coverage is also displayed in Fig. 2, from which we can observe that all architectural smells in the taxonomy are significantly recognised by the authors of the selected studies, hence making it worthy to discuss them in detail.
We hereafter illustrate how (according to the authors of the selected studies) each design principle can be affected by each corresponding architectural smell, as well as how each smell can be resolved by applying a corresponding refactoring. When multiple refactorings are applicable to resolve an architectural smell, to provide a first measurement of how much a refactoring is used to resolve it, we display the weight333We measure the weight of a refactoring as the percentage of its occurrences among all occurrences of all refactorings for the same smell. This is analogous to what done by Pahl et al. cloud-container-technologies to measure weights while classifying studies on cloud container technologies. of each refactoring by exploiting %-based pie charts.
4.1 Independent deployability
In microservice-based applications, each microservice should be operationally independent from the others, meaning that it should be possible to deploy and undeploy a microservice indepedently from the others b1-building-microservices . This indeed impacts on the initial deployment of a microservice, which can get started without waiting for other microservices to be running, as well as on the possibility of adding/removing replicas of a microservice at runtime.
We discuss below the Multiple Services in One Container smell, showing how it violates the above principle and how it can be resolved.
Multiple services in one container. Containers (such as Docker containers) provide an ideal way to deploy microservices addressing the above requirement, if properly used. Each microservice can indeed be packaged in a container image, and different instances of a same microservice can be launched by spawning different containers from the corresponding image. With this view, the orchestration of the deployment and management of a microservice-based application can be performed by exploiting the currently available support for orchestrating Docker containers o8-microservices-in-practice .
The above is the right way of using containers, at least according to the authors of 16 of the selected studies. They indeed highlight how placing multiple services in one container would constitute an architectural smell for the independent deployability of microservices. If two microservices would be packaged in the same Docker image, spawning a container from such image would result in launching both microservices. Similarly, stopping the container would result in stopping both microservices. In other words, by placing two microservices in the same container, these services would operationally depend one another, as it would not be possible to launch a new instance of one of such microservices, without also launching an instance of the other.
If the Multiple Services in One Container smell occurs, the solution is to refactor the application in such a way that each microservice is packaged in a separate container image.
4.2 Horizontal scalability
The possibility of adding/removing replicas of a microservice is a direct consequence of the independent deployability of microservices. To ensure its horizontal scalability, all the replicas of a microservice should be reachable by the microservices invoking o8-microservices-in-practice .
In the selected studies, two architectural smells emerged as possibly violating the horizontal scalability of microservices, i.e., Endpoint-based Service Interactions and No API Gateway, which we discuss hereafter.
Endpoint-based service interactions. This smell occurs in an application when one or more of its microservices invoke a specific instance of another microservice (e.g., because its location is hardcoded in the source code of the microservices invoking it, or because no load balancer is used). If this is the case, when scaling out the latter microservice by adding new replicas, these cannot be reached by the invokers, hence only resulting in a waste of resources.
From the selected studies, it became evident that the Endpoint-based Service Interactions smell can be resolved by applying three different refactorings (Fig. 3).
The most common solution is to introduce a service discovery mechanism. Such mechanism can be implemented as a service storing the actual locations of all instances of the microservices in an application o3-microservices-io . Microservice instances send their locations to the service registry at startup, and they are unregistered at shutdown. When wanting to interact with a microservice, a client can then query the service discovery to retrieve the location of one of its instances.
The other two possible solutions share the same goal, i.e., decoupling the interaction between two microservices by introducing an intermediate integration pattern. Nine of the selected studies indeed suggest to introduce a message router (e.g., a load balancer), so that the requests to a microservices are routed towards all its actual instances. Four of the selected studies instead suggest to exploit message brokers (e.g., message queues) to decouple the interactions between two or more microservices.
No API gateway. When a microservice-based application lacks an API gateway, the clients of the application necessarily have to invoke its microservices directly. The result is a situation similar to that of the Endpoint-based Service Interactions smell, with the invoker being a client of the application. The client indeed interacts only with the specific instances of the microservices it needs. If one of such microservices is scaled out and the client still keeps invoking the same instance of the microservice, then we have a waste of resources.
The authors of all the selected studies discussing the No API Gateway smell agree that the solution to this smell is to add one API gateway to the application. The latter act as single entry points for all clients, and they handle requests either by routing them or by fanning them out to the instances of the microservices that must handle them o3-microservices-io .
It is worth noting that, even if the No API Gateway smell results in a similar situation to that of the Endpoint-based Service Interactions smell, the refactorings to resolve them are different. The reason for this resides in the main difference between the two architectural smells. The No API Gateway smell occurs at the edge of the architecture of a microservice-based application, with the clients of the application directly invoking its microservices, while the Endpoint-based Service Interactions smell occurs in between its microservices b4-microservice-architecture . Given this, the introduction of an API gateway can be useful not only for facilitating the horizontal scalability of the microservices forming an application, but also for various other reasons. For instance, rather than implementing end-user authentication or throttling in each microservice, these can be implemented once for the whole application in the API gateway o4-seven-microservices-antipatterns .
4.3 Isolation of failures
Microservices can fail for many reasons (e.g., network or hardware issues, application-level issues, bugs), hence becoming unavailable to serve other microservices. Additionally, communication fails from time to time in any kind of distributed system, and this is even more likely to occur in microservice-based systems, simply because of the amount of messages exchanged among microservices microservices-journey-challenges-m7 . Microservice-based applications should hence be designed so that each microservice can tolerate the failure of any invocation to the microservices it depends on o2-microservices-fowler . If this is ensured, then a microservice-based application results to be much more resilient than a monolithic application, simply because failures affects only few microservices in an application, instead of the whole monolith b1-building-microservices .
The authors of the selected studies identify and discuss an architectural smell that can possibly violate the isolation of failures in microservice-based solutions. This is the Wobbly Service Interactions smell, which we discuss hereafter.
Wobbly service interactions. The interaction of a microservice with another microservice is “wobbly” when a failure in can result in triggering a failure also in . This typically happens when is directly consuming one or more functionalities offered by , and is not provided with any solution for handling the possibility of to fail and be unresponsive. If this is the case, will also fail in cascade, and (in a worst case scenario) the failure of can result in triggering the failure of other microservices, which in turn trigger other cascading failures, and so on microservices-journey-challenges-m7 .
To avoid Wobbly Service Interactions (such as the one between and described above), the authors of the selected studies identify four possible solutions (Fig. 4).
The most common solution is the usage of a circuit breaker to wrap the invocations from a microservice to another. In the normal “closed” state, the circuit breaker forwards the invocations to the wrapped microservice, and it monitors their execution to detect and count failing invocations. Once the frequency of failures reaches a certain (customisable) threshold, the circuit breaker trips and “opens” the circuit. All further calls to the wrapped microservice will “safely fail”, as the circuit breaker will immediately return an error message to the calling microservices. The latter can then exploit the error messages returned by the circuit breaker to avoid failing themselves o2-microservices-fowler .
Following the same baseline idea of circuit breakers, ten of the selected studies propose to decouple the interaction between invoking and invoked microservices by exploiting a message broker (e.g., a message queue). The usage of a broker allows the invoker to send its requests to the broker, and allows the invoked microservice to process such requests when it is available. In this way, there is no direct interaction between the two microservices, and the invoker does not fail when the invoked microservice fails (as the former continues to send messages to the broker). On the other hand, the usage of message brokers is more costly compared to circuit breakers. The reason is that message brokers require to intervene on the interaction protocol between two microservices, which should start putting and getting messages to/from the broker. Instead, with circuit breakers the interaction protocol between two microservices is unaltered, as a circuit breaker simply wraps the invocation of a microservice. This is the reason why message brokers are much less discussed than circuit breakers.
The most discussed alternative to circuit breakers are however timeouts, which are a simple yet effective mechanism allowing a microservice to stop waiting for an answer from another microservice, when the latter is unresponsive (e.g., since it failed or due to network issues). Well-placed timeouts provide fault isolation, as the fact that a microservice is unresponsive does not create any other issue in the microservices invoking it b1-building-microservices . However, such a kind of solution might not likely to be applicable nowadays, as some of the APIs used to remotely invoke microservices have few or no explicit timeout settings b1-building-microservices . Note that the timeout can be also set in the invoker (e.g., by setting the timeout on an HTTP request), hence it is not always requested to have a timeout setting on the invoked service.
Finally, another alternative is the usage of bulkheads, whose ultimate goal is to enforce the principle of damage containments (like bulkheads in ships, which prevent water to flow across sections). The idea is that, if cascading failures cannot be avoided, they should at least be limited by exploiting bulkheads. More precisely, the microservices forming an application should be logically and/or physically partitioned so as to ensure that the failure of a microservice can be propagated at most to the other microservices in the same partition, by preventing the rest of the system from being affected by such failure b7-release-it .
4.4 Decentralisation
Decentralisation should occur in all aspects of microservice-based applications b1-building-microservices . This also means the business logic of an application should be fully decentralised and distributed among its microservices, each of which should own its own domain logic microservices-tenets-m6 .
The authors of the selected studies indentify and discuss three architectural smells possibly violating the above principle, i.e., the ESB Misuse, Shared Persistence and Single-layer Teams smells. We hereafter discuss them, by also illustrating the refactorings currently employed to resolve them.
ESB misuse. The misuse of Enterprise Service Buses (ESB) products is considered to be an architectural smell by the microservice community. When positioned as a single central hub (with the services as spokes), an ESB may become a bottleneck both architecturally and organizationally Pautasso:2017:MSIP . “Smart endpoints & dumb pipes” has been a recommended practice since the very beginnings of service-oriented architectures microservices-tenets-m6 that regrettably has not always been followed in all SOA implementations. Such ESB abuse may lead to undesired centralisation of business logic and dumb services b1-building-microservices . The microservices community therefore (re-)emphasizes the decoupling of microservices and their cohesiveness o2-microservices-fowler .
Whenever a central ESB is used for connecting microservices in an application, the topology should be refactored to remove the dependency on a single middleware component instance. Multiple instances should instead be used, and they should implement queue-based asynchronous messaging. The latter only permits adding and removing messages, hence forming a “dumb pipe”. The “smart” part should be left to the microservices, which implement the logic for deciding when/how to process the messages in the message broker microservice-bad-smells-m5 . Additional infrastructure logic, for instance traffic management capabilities, may be placed in side cars accompanying each service. This repositioning and rectification of ESB middleware improves the decoupling characteristics of the services architecture and reestablishes the original “smart endpoints & dumb pipes” recommendations from the first wave of service-orientation.
Shared persistence. The Shared Persistence smell occurs whenever two microservices access and manage the same database, possibly violating the decentralisation design principle m26-microservices-pains-gains .
The three currently available solutions for refactoring microservices and resolving the Shared Persistence smell are shown in Fig. 5.
Although the ultimate goal of these three solutions is the same (i.e., having each database accessed by only one microservice), they are very diverse in spirit. They apply to different situations, highly depending on the microservices accessing the same database.
The most discussed solution is to actually split a database shared by multiple microservices, in such a way that each microservice accesses and manages only the data it needs. This solution is the one requiring less intervention on the microservices, as they would continue to use the same protocol to interact with the databases. At the same time, splitting a database into a set of independent databases is not always possible or easy to achieve. Also, if some data is to be replicated among the databases obtained from the split, then mechanisms for (eventual) data consistency should be introduced after the refactoring m26-microservices-pains-gains . Given the above, the split of database is recommended when the microservices accessing the same database implement separate business logics working on disjoint portions of such database b6-microservices-for-enterprise .
The most discussed alternative is to introduce an additional microservice, acting as “data manager”. The data manager becomes the only microservice interacting with and managing the database, and the microservices that were accessing the database now have to interact with the data manager to ask for accessing and updating the data. While this solution introduces some additional communication overhead, it is considered as always applicable, and the data manager can also be enriched with additional logic for processing the data it manages b6-microservices-for-enterprise .
Finally, it is worth commenting on the refactoring discussed in three of the selected studies, i.e., merging the microservices accessing the same database. The idea is that, when multiple microservices access the same database, this may be a signal of the fact that the application has been split too much, by obtaining too fine-grained microservices processing the same data. If this is the case, then the possibility of merging such microservices is a concrete option to be evaluated microservice-bad-smells-m5 .
Single-layer teams. To maximize the autonomy that microservices make possible, the governance of microservices should be decentralised and delegated to the teams that own the microservices themselves. As pointed out by Zimmermann microservices-tenets-m6 , even if this is not a technical concern, it is related to the process viewpoint due to its cross-cutting nature. The microservice community indeed strongly emphasizes the connection between architecture and organisation, especially concerning the integration of the microservices in an application o6-develop-great-microservices ; o11-creating-microservice ; o2-microservices-fowler .
The classical approach of splitting teams by technology layers (e.g., user interface teams, and middleware teams, and database teams) is hence considered an architectural smell, as any change to a microservice may result in a cross-team project having take time and budgetary approval o2-microservices-fowler . This may be the case for the refactorings discussed so far.
The microservice approach to team splitting is orthogonal to the above, as each microservice should be assigned to a full-stack team whose members span across all technology layers. In this way, the interactions for updating a microservice (e.g., to apply one of the refactorings discussed in this section) are limited to the team managing such microservice, which can independently decide how to proceed and implement the updates migrating-towards-microservices-m13 .
In short, if the governance of a microservice-based is organised by Single-layer Teams, this is an architectural smell. The solution is to split teams by microservice, rather than by technology layer o2-microservices-fowler .
5 Threats to validity
Following the taxonomy developed by Wohlin et al. wohlin , four potential theats may affect the validity of our study. These are the threats to external validity, the threats to internal and construct validity, and the threats to conclusions validity, which we discuss hereafter.
External validity. As per Wohlin et al. wohlin , the external validity concerns the applicability of a set of results in a more general context. Since we selected the primary studies from a very large extent of online sources, the identified architectural smells and refactorings may only be partly applicable to the broad area of disciplines and practices on microservices, hence threatening external validity.
To reinforce the external validity of our findings, we organised two feedback sessions during our analysis of the existing literature. We analysed the discussion following-up from the feedback session, and we exploited this qualitative data to fine-tune both our research methods and the applicability of our findings. We also prepared a GitHub repository444http://github.com/di-unipi-socc/microservices-smells-and-refactorings., where we placed the artifacts produced during our analysis, so as to make it available to all who wish to deepen their understanding on the data we produced. We believe that this can help in making our results and observations more explicit and applicable in practice.
Additionally, one may argue that our selection criteria are too restrictive. The rationale behind such criteria is that we aim focusing only on representative studies, by requiring selected studies to discuss at least an architectural smell and a refactoring for resolving it. There is however a risk of having missed some relevant literature, as a study might not explicitly mention the architectural smells and refactorings in our taxonomy (Fig. 1). To mitigate this threat, we carefully checked both selection criteria against each candidate study, by verifying whether a study was discussing the problems characterised by an architectural smell, and whether it was discussing the architectural changes characterising a refactoring. Even if a study was not explicitly referring to a smell/refactoring, but it was reporting on the corresponding problems/changes, the study was included in the selected literature.
Finally, there is a risk of having missed relevant grey literature, since industrial studies may exploit a different terminology than ours (e.g., a blog post discussing some architectural smells and refactorings may not employ the term “smell” or “refactor”). To mitigate this threat to validity, we included relevant synonyms in the search string, and we exploited the features offered by search engines, which naturally support including related terms in string-based searches.
Construct and internal validity. The internal validity concerns the validity of the method employed to study and analyse data (e.g., the potential types of bias involved), while the construct validity concerns the generalisability of the constructs under study wohlin .
To mitigate the corresponding potential threats, the obtained taxonomy underwent various iterations among the authors of this study to avoid bias by triangulation, and it was submitted for validation to an external expert. The same process was applied to the classification of the selected studies, and to the results of the analysis.
Conclusions validity. The conclusions validity concerns the degree to which the conclusions of a study are reasonably based on the available data wohlin .
In this perspective, and with the aim of performing a sound analysis of the data we retrieved, we exploited inter-rater reliability assessment to limit potential biases in our observations and interpretations. Additionally, the observations and conclusions discussed in this paper were independently drawn, and they were then double-checked against the selected studies and related studies in a joint discussion session.
6 Related work
There exist various studies on microservices, aimed at analysing and classifying the state of the art and practice on microservices. Pahl and Jamshidi microservices-sms and Taibi et al. architectural-patterns-microservices-m3 present two first systematic mapping studies on microservices. Pahl and Jamshidi microservices-sms discuss agreed and emerging concerns on microservices, position microservices with respect to current cloud and container technologies, and elicit potential research directions. Taibi et al. architectural-patterns-microservices-m3 instead report on architectural patterns common to microservice-based solutions, by discussing the advantages, disadvantages and lessons learned of each pattern. However, neither Pahl and Jamshidi microservices-sms nor Taibi et al. architectural-patterns-microservices-m3 provide an overview both on the architectural smells applicable to microservices and on the refactorings for resolving such smells.
Two other examples are the industrial surveys by Di Francesco et al. migrating-towards-microservices-industrial-survey and by Ghofrani and Lübke challenges-microservices-industrial-survey , which both discuss the current state of practice on microservices in the IT industry. Both report on empirical studies conducted in the form of surveys for practictioners working everyday with microservices, to elicit the challenges and advantages on employing microservices. This differs from our study, as we aim at distilling the architectural smells that can affect the architecture of a microservice-based solution, as well as the refactorings allowing to resolve such smells.
Similar considerations apply to the systematic review by Soldani et al. m26-microservices-pains-gains , who provide an overview on the state of practice on microservices. Soldani et al. systematically analyse the grey literature on microservices, in order to identify the technical/operational advantages and disadvantages of the microservice-based architectural style. The objective of Soldani et al. hence differs from ours, as we aim at discussing concrete architectural smells and refactorings for the microservice-based architectural style.
In this perspective, the objective of the studies by Taibi and Lenarduzzi microservice-bad-smells-m5 , by Bogner et al. collaborative-repo-antipatterns , and by Carrasco et al. migrating-towards-microservices-m13 is much closer to ours. Taibi and Lenarduzzi microservice-bad-smells-m5 report on a survey submitted to practictioners experienced with microservices. The survey allowed Taibi and Lenarduzzi to identify 11 microservice-specific architectural smells, each with a refactoring solution allowing to resolve it. Of such smells and refactorings, only four can be related to the design principles of microservices pertaining to the process viewpoint (see Table 2). By integrating the work by Taibi and Lenarduzzi with other carefully selected white/grey literature, we managed to extend the set of architectural smells and refactorings pertaining to the process viewpoint with three additional smells and ten additional refactorings.
Bogner et al. collaborative-repo-antipatterns present a systematic literature review identifying and documenting architectural smells in SOA-based architectural styles, including microservices. Altough the main focus of their review is on the broader SOA, several smells apply also to microservices. However, the review by Bogner et al. collaborative-repo-antipatterns differs from ours, as it focuses only on white literature, and since it does not discuss the architectural refactorings allowing to resolve the identified smells.
Carrasco et al. migrating-towards-microservices-m13 systematically analyses the white and grey literature on architectural smells that can occur while migrating from monoliths to microservice-based solutions. They present nine common smells with their potential solutions, which all pertain to the actual development and operation of microservice-based applications (i.e., development and physical viewpoints). The study by Carrasco et al. migrating-towards-microservices-m13 hence differs from ours, as we focus on the dynamic aspects of microservices that interact at runtime (i.e., process viewpoint).
In summary, to the best of our knowledge, there is currently no study classifying the architectural smells possibly violating the design principles of microservices pertaining to the process viewpoint, together with the refactorings that permit resolving such smells. This is the scope of our study, which we have presented in this paper.
7 Conclusions
We presented the results of a multivocal review focused on identifying architectural smells indicating possible violations of the independent deployability, horizontal scalability, fault isolation and decentralisation of microservices, as well as the refactorings allowing to resolve such smells. More precisely, we presented a taxonomy organising seven architectural smells and 16 refactorings, by associating each smell with the design principle(s) it violates, and each refactoring with the smell it resolves. We then provided an overview of the actual recognition of such smells and refactorings in the selected literature. We also discussed why each architectural smell violates the design principle it pertains to, and how each architectural refactoring allows resolving its corresponding smell.
We believe that our study can be of help to both researchers and practitioners interested in microservices. Together with the review by Carrasco et al. migrating-towards-microservices-m13 , our results can help them to understand the well-known architectural smells for microservices, and to choose among the refactorings allowing to resolve such smells. This can have a pragmatic value for practitioners, who can exploit the results of our study in their daily work with microservices. It can also help researchers to shape new solutions and to establish future research directions.
We plan to exploit our results to develop a design-time support for eliminating architectural smells from microservice-based applications. Our idea is to exploit existing languages for the specification of microservice-based applications (such as TOSCA tosca , for instance). We then plan to develop a tool for processing the specification of a microservice-based application, to automatically detect the architectural smells occurring in such application, and to suggest the architectural refactorings resolving such smells.
Acknowledgements.
This work was partly funded by the POR-FSE project AMaCA (Regione Toscana), and by the project DECLware (PRA_2018_66, University of Pisa). Published version Neri D, Soldani J, Zimmermann O, Brogi A. Design principles, architectural smells and refactorings for microservices, SICS Software-Intensive Cyber-Physical Systems (2019). DOI: 10.1007/s00450-019-00407-8
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1(1) Alagarasan, V.: Seven microservices anti-patterns. Info Q, https://www.infoq.com/articles/seven-uservices-anti patterns (2015)
- 2(2) Alshuqayran, N., Ali, N., Evans, R.: A systematic mapping study in microservice architecture. In: 2016 IEEE 9th Int. Conf. on Service-Oriented Computing and Applications (SOCA), pp. 44–51 (2016). DOI 10.1109/SOCA.2016.15
- 3(3) Balalaie, A., Heydarnoori, A., Jamshidi, P.: Microservices architecture enables devops: Migration to a cloud-native architecture. IEEE Software 33 (3), 42–52 (2016). DOI 10.1109/MS.2016.64
- 4(4) Balalaie, A., Heydarnoori, A., Jamshidi, P., Tamburri, D.A., Lynn, T.: Microservices migration patterns. Software: Practice and Experience 48 (11), 2019–2042 (2018). DOI 10.1002/spe.2608
- 5(5) Bhojwani, R.: Design patterns for microservices. D Zone, https://dzone.com/articles/design-patterns-for-micro services (2018)
- 6(6) Bonér, J.: Reactive Microservice Architecture: Design Principles for Distributed Systems. O’Reilly (2016)
- 7(7) Carneiro, C., Schmelmer, T.: Microservices From Day One: Build Robust and Scalable Software from the Start, 1st edn. Apress, Berkeley, CA (2016)
- 8(8) Carnell, J.: Spring Microservices in Action, 1st edn. Manning Publications Co. (2017)