Microservices have been one of the fastest-rising trends in the development of enterprise applications and enterprise application landscapes. Even though various mapping studies investigated the open challenges around microservices from literature, it is dificult to have a clear view of existing challenges in designing, developing, and maintaining systems based on microservices architecture as it is perceived by practitioners. In this paper, we present the results of an empirical survey to assess the current state of practice and collect challenges in microservices architecture. Therefore, we synthesize the 25 collected results and produce a clear overview for answering our research questions. The result of our study can be a basis for planning future research and applications of microservices architecture.
Microservices architecture (MSA) is based on a share-nothing philosophy and
relies on a long evolving experience in software engineering and system design.
This architectural style structures a system as a set of loosely-coupled small
services which are isolated in small coherent and autonomous units [
Many organizations, such as Amazon, Netflix, and the Guardian, utilize
MSA to develop their continuous delivery of large and complex applications
while providing flexibility and diversity of technology stack [
The main contributions of this paper are: (i) providing an up-to-date map of the state of the practice in MSA and its complexities for future research; (ii) an evaluation of the potential research field on MSA. The audience of this paper are both researchers interested to supplement and update their overview of most recent challenges in this field for their future contributions as well as practitioners interested to get an overview of existing challenges and solutions, thereby making better decisions for their organization.
The rest of the paper is organized as follows. Section 2 gives an overview on
the existing reviews from literature, whereas the design of our study is presented
in Section 3. We elaborate the results of our study in Section 4 by putting them
in a broader perspective for answering the proposed research questions. With
Section 5 we conclude the paper and discuss the future work. The full survey
data including the questionnaire and preprocessed results is shared and available
online [
As described in the previous section, the existing academic studies reviewed the literature to provide an overview of open challenges in MSA. There is no academic survey on the state of the practice in MSA as of now. As a basis for our study, we consider the following systematic literature reviews and mapping studies conducted about state of the art in MSA.
Pahl and Jamshidi [
Since surveys provide a better overview of usage of technology in the software
industry [
We created our online survey based on the guidelines described by Jacob et al.
[
First, we reached the potential participants via our personal contacts and asked them to take part and also forwarded our invitations to potential participants that they may know. In addition, we posted the survey invitation to several online communities, XING, meet-up groups, and advertised the survey via mailing lists of the NGINX, Inc. In order to control who was answering our survey, we started our survey with a filter question about taking part in a project with relevance to MSA. 4
In total, 40 experts participated in our survey and 25 of them has answered yes to the filter question about being involved in any project or program that are related to the microservices architecture. Since our research is related to the practical part of the MSA, we consider only the answers of the participants who answered yes to the filter question and answered at least one of the other questions from our survey. The Majority of the respondents, 19 (76%), are practitioners from industry whereas only 2 of them (0.08%) are from academia. Furthermore, 4 participants are active in both academic and industrial contexts. By asking about the role of the participants in their current activities, 17 (68%) stated that they are developers, 11 (44%) system architects, and 3 (12%) of them are team leaders. All of the team leaders and 8 of the system architects are developers simultaneously. Relative to experience with MSA, 11 (44%), have between 1 and 2 years, and 8 (32%) have between 2 and 5 years of experience. 21 participants stated that they use agile methods in their organizations. 4.1
RQ1: What are the main challenges/concerns in the design and the development process of microservices? To answer RQ1, we asked our participants about their main challenges in the development process of microservices. According to the 8 comments and free-text answers of the survey to this question, the distributed nature of the MSA is one of the main challenges in the development and debugging of the systems based on this architectural style. “Too many repositories to maintain”, “Hard to find issues in a distributed system. Rarely any benefit”, “networking between dockers”, “sharing base data among diferent services considering performance limitations”, and “debugging a microservice that relies on other services can be tricky” are som12e of these comments. Next common challenge is the skill and knowledge. It s1e0ems that there are dificulties between customers and development teams in “8understanding MS of the Top Management/Director levelsN”ot,at“alglIemtpotritanntg the right developers/engineers”, and “Changing the people’s mindSlsighttlhyiamtporatarnte used to tr6aditional monoliths”. Finally, “correct separation of domainIms”portaanntd “finding the 4appropriate service cuts” are the third majority of the concFVaeeirryrlyinmimspporostrattnaatntted by our 2participants. Nevertheless, they have also recommended to use MSA instead of ot0her architectural approaches in case of “Distributed teams that can have logical sSeecpuriatyratiPoerfnorsm”anc.e Resilience Memory Usage Reliability Response time Fault tolerance
Security
Performance
Resilience
Memory Usage Reliability
Response Time Fault Tolerance
In order to get an overview of the main concerns of our participants regarding nonfunctional features of their MSA, we asked “How important is it for you to optimize the following features of your microservice architecture?” – Security – Performance – Resilience – Memory Usage – Reliability – Response time – Fault tolerance 1 1 We use 5 levels of importance: Not at all important, Slightly important, Important, Fairly Important, and Very important 12 10 8 6 4 2 0 Not at all Important Slightly important Important Fairly important Very important
RQ2: What are the main reasons leveraging and preventing the usage of systematic approaches in microservices architectures? We asked the participants “How do you derive service boundaries?”. On the one hand, a big amount of the participants (7/25) use Manually / Good Feeling methods based on their experiences and skills. Looking at the skills of these participants reveals that most of them have less than 2 years of experience with MSA. On the other hand, 6/25 of participants inform us that they use systematic approaches, especially Domain Driven Design, for deriving the service boundaries. It shows a significant correlation (85%) with their experience on MSA, between 2 to 5 years. Automatic methods, such as tooling, formal methods, and algorithms for deriving service boundaries were used by 3 participants. Two of them have less than 2 years of experience in MSA and only one has between 2 and 5 years of experience. These answers are depicted in Fig. 3.
The next question was: “Which notation(s) do you use to describe your architecture?”. As shown in Fig. 4, 8/25 of the participants stated that they use Graphical Modeling Languages (GML) because of agility, simplicity, and easily available GML tools. 2/25 use Textual Modeling Languages (TML) and 7 6 5 4 3 2 1 10 9 8 7 6 5 4 3 2 1 0 0 Systematic (e.g., Domain Driven Design) Automatic (e.g., tooling, formal models and Manually /Good Feeling (e.g., experiences
algorithms, ...) and skills) 4/25 of them use Domain Specific Languages (DSL). Nevertheless, 9/25 of participants stated that they do not use any notation in this context. None of the participants named any tool, technique, and framework for modeling their MSA which indicates the limited awareness on existing tools for MSA among the practitioners.
Textual Modeling Languages Graphical Modeling Languages Domain Specific Languages (TML) (DSL) None
RQ3: Are there any suggestions or solutions from the experts to improve aspects of the microservices architecture? Finding a trade-of between reusing and developing the architectural artifacts is a well-known issue in any software architecture. We asked the participants about their opinion on usage of artifacts from third-parties within a MSA as the following question: “If you use any artifacts from third-parties in your microservice architecture, do you consider the following features? How important are they for you?”.
– Last Release Date – Security Less than 2 years Between 2 and 5 years respondent count 10 9 8 7 6 5 4 3 2 1 0 Very important Fairly important Important Slightly important Not at all important – Last Release – Memory Usage – License 2
As Fig. 5 illustrates, Security, License, and Memory usage are the most respected concerns according to the given priorities. Furthermore, one respondent mentioned that “he/she often finds out about memory footprint or computing time only after he/she has integrated and tested” about third-party frameworks or libraries. There is also an interesting suggestion from a respondent to start renaming microservice nomenclature in order to facilitate the utilization of Domain Driven Design tools within the MSA context.
Last Release Date In this paper we reported the results of our online survey that we conducted among experts of Microservices architecture (MSA). We have investigated survey responses to answer our three research questions about challenges in MSA. Since the majority of our experts are from industry, our research reflects the practical issues in MSA. Our work can be used as a complementary work to the existing literature reviews to guide researchers to the open issues and problems in MSA and ofer an overview from practical point of view.
Among the collected responses, the lack of notations, methods, and frameworks to architect MSA can be considered as important points. The lack of tool or framework support for selecting third-party artifacts according to their features, e.g. security, last release, as well as the shortage of knowledge of the practitioners about systematic methods are the top main gaps, which can be addressed in the future work. According to the results of our survey, optimization in Security, Response Time, and Performance have higher priorities than Resilience, Reliability, Fault Tolerance, and Memory Usage. 2 We use 5 levels of importance: Not at all important, Slightly important, Important, Fairly Important, and Very important
Future work includes (i) conducting a survey each year to monitor the change over time, (ii) performing a new survey with a larger scope to collect more details about further aspects of MSA in the practice and (iii) proposing solutions for the identified gaps.