Understanding and addressing quality attributes of microservices architecture: A Systematic literature review

Microservices Architecture (MSA) originates from agile developer communities and has received shifting focus in both industry and academia in recent years [1] after the prosperity of SOA (Service-oriented Architecture). No agreement has been reached about the relationship between MSA and SOA [2]. Some MSA advocates claim that MSA is a new architectural style, while some SOA proponents think that MSA is merely an implementation approach of SOA. Our paper follows the former claim based on the definition and nine characteristics of MSA from Fowler et al. [1]. and the seven principles defined by Newman [3].

In the perspective of architecture, the quality assurance is considered as a key concern during the migration or the development of microservices-based systems [7,8]. Many researchers have contributed to the design and the quality improvement of microservices-based systems [2,3,9].

Quality Attributes (QAs) are inevitably discussed in the migration practices from monolithic applications to MSA [12,13], for instance, maintainability, reusability, and scalability.

Most of the existing studies on MSA focus on architectural principles and application of the architectural patterns [14–16] in microservices migration practices, which can provide an analytic view of common patterns and practices used for MSA and can be considered as a starting point of our work.

To ensure consistent meanings of quality attributes extracted from different studies, we used the commonly accepted standards like ISO/IEC 25,010 [26] and considered specific attribute definitions provided by Bass et al. [27]. For example, both the explicit expression like “performance” in [Khaz 16] and the implicit expression like “response time” in [Sing 17] are all recognized as the QA of performance.

This study identifies six most concerned QAs from reviewed studies related to MSA: scalability, performance, availability, monitorability, security, and testability. Scalability and performance are the two most concerned QAs addressed in MSA, while testability gains the least concern of researchers. The correlation exists among the identified QAs and is considered by some researchers, e.g., the trade-off between performance and scalability or dependency between monitorability and scalability.

Horizontal scalability is a most important property of MSA, since it decomposes the monolith into independent microservices and enables microservice instances scale out conveniently.

Horizontal Duplication is a tactic for scalability that is based on the theory of the X-axis in the Application Scale Cube defined by Abbott et al. [28]. This tactic guides the increase or decrease of microservice instances responding to the changing amount of requests. Solutions of the Horizontal Duplication tactic are identified from 14 studies that fall into two types: Reactive Auto-scaling and Proactive Auto-scaling.

Reactive Auto-scaling: This Reactive Auto-scaling solution is responsible for scaling microservices in and out based on a threshold-based auto-scaling mechanism. A scaler decides to scale in or outaccording to an upper and lower threshold as well as the information periodically monitored, e.g., the workload intensity, the CPU utilization, HTTP latency, HTTP throughput or the message queue metrics [Klin 18]. If the monitored information exceeds the threshold pre-defined, the scaler will choose to increase or decrease the instances of the microservice.

Proactive Auto-scaling: The Proactive Auto-scaling solution addresses the scale-out or in throughsome basic processes [Prac 18,Alip 17]: 1) predicting workload from history to find the number of requests for each microservice that will come to microservices in the future; 2) converting requests to the needed resource (amount of CPU core and memory) to keep microservices working under SLA; 3) matching the supply from the needed resources so as to ensure that enough resources are available and also cost-effective.

Vertical Decomposition tactic guides the decomposition of a monolith into a set of appropriate microservices including databases so as to achieve higher and more independent scalability.

When applying the Vertical Decomposition tactic, decisions should be carefully made to find appropriate granularity of microservices for the balance of scalability and the performance. High cohesion and loose coupling can be considered to decide the size of microservice candidates balancing between the independent scalability and the performance in terms of the network communication of services [Kloc 17].

Fine-grained and loose coupling microservices may improve the resource utilization and help to save the cost of system due to the independent scalability of specific services rather than the whole system. However, it does not mean that the smaller size of the microservice, the better. Too small microservices may lead to the increase of the quantity of services and also the interactions among microservices via network, which may negatively impacted the performance because of the longer response time to deal with the more communications of services.

Performance is a measure of a system ’s ability to meet timing requirements when responding to an event [27]. Performance is another most critical QA for distributed microservices in MSA, which often uses lightweight and REST-based mechanisms for microservices’ communication.

There is a trade-off between scalability and performance [Kloc 17]. The smaller size of microservices may increase scalability, while it can also decrease the performance due to the more interactions among microservices. On the contrary, the performance may be improved through merging two microservices and reducing the communication overhead, at the cost of scalability to some extent.

The most commonly used tactic addressing performance is Resource Management and Allocation, which operates on the response side to make the resources at hand work more effectively in handling the demands put to them [27]. This tactic is similar to the definition of tactics from Bass et al., for example, the “Increase Resources” and the “Scheduling”.

According to Bass et al., the demand for resources of systems is not controllable [27]. Under this circumstance, effective management of these resources on the response side may be critical for the concern of performance.

Load Balancing is a tactic that distributing incoming load on an individual microservice among its many instances. By this way, requests can be fulfilled in a manner that maximizes speed and capacity utilization and ensures that no one service is significantly overworked compared to others, which could dred toegrade performance.

Centralized load balancing is the most common mechanism to manage the load of microservices. It usually sets up a centralized load balancer, which sits between the client and the services accepting incoming network and application traffic and distributes the traffic across multiple back-end services in a real-time way using various push-based algorithms, for example, the RoundRobin algorithm, the JSQ algorithm, the JIQ algorithm [Abad 18], the hybrid scheduling algorithm [Fili 18], or the adaptive SQLB algorithm. The centralized load balancer is usually transparent to the clients and the clients do not know the service list. It is responsible for checking the health of the server pool underneath and use specific algorithms for the load’s distribution. Common server-side load balancing solutions [Sing 17] are Ngnix, HA Proxy, etc.

Distributed load balancing is an approach on the upswing in MSA. The load balancer of this approach is composed of a set of schedulers or implemented by the client itself. The distributed load balancer or client gets a list of available servers and then distributes the requests to different servers according to a specific pull-based load balancing algorithms, such as FCFS algorithm [Fili 18, Liu 18b]. Different from the centralized side load balancing, client itself of distributed load balancing holds the list of service IPs that it can deliver the requests, selects an IP from the list randomly or according to a specific method, and forwards the request to certain services.

Containerization is an emerging tactic for MSA, which achieves virtualization through containers. We found that four primary studies adopted this tactic for higher performance than virtual machines (VMs).

Docker is the most representative technology implementing the Containerization tactic. It increases the performance of microservices from two aspects [Kang 16]: Firstly, different from VM in their architecture, containers can share the same host OS and require guest processes to be compatible with host kernel. This way can reduce the overhead of communication among different guest OSs for different container processes, can thus contribute for high performance, less memory requirement and reduced infrastructure cost. Secondly, the lightweight characteristic of Docker containers could help to create and run more microservices contributing to higher resource utilization.

Profiling is a tactic that analyzes the characteristics of a microservices-based system including the required memory, CPU, or bandwidth, and provides both scheduling engine and auto-scaling resource manager with essential information to optimize the performance [Fili 18]. Two primary solutions related to this tactic are CPU and memory profiling.

To some extent, employing lightweight profilers such as Linux Perf can enable an “always-on” approach and support continuous performance assurance [Nico 18]. However, the scalability of solution for the Profiling tactic should be considered and addressed, since the “always-on” approach may also significantly increase the cost of data processing and storage

Availability measures the ability of a systemto repair faults so that the period of a service with the unavailable state does not exceed a required value [27]. According to the definition of Bass et al., availability is a broad perspective and encompasses what is normally called reliability [26].

Circuit breaker is a tactic that prevents requests to a service in case of a failure.When facing with a failure, the circuit breaker opens depending on a specific threshold. After a period of time predefiend, the circuit breaker closes again and will not open until errors are detected.

Monitorability is a measure of a system’s ability to support the operations staff to monitor the system while it is executing [27]. Moni toring becomes an essential but more complex part of microservices-based systems due to the high level of dynamic structure and behavior of such a system

Improving monitorability may impact other QAs of a system with MSA style, e.g., the scalability, performance, and availability.

Security is a measure of a system’s ability to protect data and information from unauthorized access while providing access to people and systems that are authorized [27]. MSA distributes the application logic into multiple smaller microservices, resulting in a much more complex network interaction model between services. Attackers can thus exploit this complexity to launch attacks against applications [Sun 15].

Testability is a measure of a system’s ability to demonstrate its faults through (typically execution-based) testing [27]. As the relationship between microservices is complex and some microservices may experience frequent modification, it is necessary to pay attention to the testability of this kind of systems to minimize the impact on the performance, availability and security.

MSA should be embraced with caution and decisions should be carefully made by practitioners when considering the migration from monolithic systems. Firstly, practitioners may need to decide whether or not they must migrate to MSA through evaluating the return on investment (ROI). The return may refer to some intolerable pains’ in their legacy systems that could be addressed by MSA, while the investment means the additional efforts and cost to implement the tactics for specific QAs of the identified set in this SLR or other important ones we do not obtain due to the restricted time span. Secondly, the complex relationships among QAs require to be considered during the migration to MSA, e.g, dependency or trade-off.

Image description:
Reference architecture of MSA-based systems involving tactics identified

In addition to the QAs listed in Table 4, we also identify other three QAs but without essential evidence support, i.e. interoperability, portability, and maintainability [29]. They were only mentioned in the reviewed studies with no evidence for answering our research questions. interoperability and portability of MSA are claimed to be positively influenced in three and two papers respectively. On the contrary, three papers mentioned that maintaining multiple services with complex relationship is in the list of the challenging items while building MSA. More empirical research is needed to study these QAs, in particular for improving maintainability of MSA.