Defining and measuring microservice granularity—a literature overview

Coupling metrics

The coupling measures the degree of dependence of one software component in relation to another. If there is a high degree of coupling, the software component cannot function properly without the other component; furthermore, when we change a software component, we must obligatorily change the other component. For these reasons when designing microservice-based applications, we should look for a low degree of coupling between each microservice.

Mazlami, Cito & Leitner (2017) represented the information in the monolith and create an undirected, edge-weighted graph G. Each graph edge has a weight defined by the weight function; this weight function determines how strong the coupling between the neighboring edges is, according to the coupling strategy in use (Mazlami, Cito & Leitner, 2017). These coupling strategies can be used as metrics to define the granularity. These metrics are defined as follows:

Dependency weight. Ahmadvand & Ibrahim (2016) said “dependency weight indicates the frequency of using the dependency. For example, the dependency weight between a billing and shopping cart is high, because with each call to the former a call is required to the latter. On the other hand, the dependency weight between the billing service and a service managing the meta-data of payment methods is low, because the former calls the latter only once a day” (Ahmadvand & Ibrahim, 2016).

Logical coupling. Gall, Jazayeri & Krajewski (2003) coined the term logical coupling as a retrospective measure of implicit coupling based on the revision history of an application source code (Gall, Jazayeri & Krajewski, 2003). Mazlami, Cito & Leitner (2017) define the value of the logical coupling is one if classes (C₁, C₂) have changed together in a certain commit. They use the logical coupling aggregate which is the sum of the logical coupling for each pair of classes (Mazlami, Cito & Leitner, 2017).

Semantic coupling. Basically, semantic coupling couples together classes that contain code about the same things, i.e., domain model entities. The semantic coupling strategy can compute a score that indicates how related two files are, in terms of domain concepts or “things” expressed in code and identifiers (Mazlami, Cito & Leitner, 2017).

Contributor count and contributor coupling. The contributor coupling strategy aims to incorporate the team-based factors into a formal procedure that can be used to cluster class files according to the team-based factors (reduce communication overhead to external teams and maximize internal communication and cohesion inside developer teams). It does so by analyzing the authors of changes on the class files in the version control history of the monolith. The procedure to compute the contributor coupling is applied to all class files. In the graph G representing the original monolith M, the weight on any edge is equal to the contributor coupling between two classes C_i and C_j that are connected in the graph. The weight is defined as the cardinality of the intersection of the sets of developers that contributed to class C_i and C_j (Mazlami, Cito & Leitner, 2017).

Structural coupling. Structural coupling consists of the number of classes outside package P_j referenced by classes in the package P_j divided by the number of packages (Candela et al., 2016).

Afferent coupling (Ca). The number of classes in other packages (services) that depend upon classes within the package (service) itself, as such it indicates the package’s (service’s) responsibility (Martin, 2002) cited by (Li et al., 2019).

Efferent coupling (Ce). The number of classes in other packages (services), that the classes in a package (service) depend upon, thus indicates its dependence on others (Martin, 2002) cited by (Li et al., 2019).

Instability (I). Measures a package’s (service’s) resilience to change through calculating the ratio of Ce and Ce + Ca. I = 0 indicates a completely stable package (service), whereas I = 1 a completely unstable package (service) (Martin, 2002) cited by (Li et al., 2019).

Coupling between microservice (CBM). Taibi & Syst (2019) defined CBM extending the well-known coupling between objects; this coupling can occur through method calls, field accesses, inheritance, arguments, return types, and exceptions. They calculated the relative CBM for each microservice by dividing the number of external links between the number of classes in the microservices (Taibi & Syst, 2019).

Integrating interface number (IFN). The number of published interfaces of a service. The smaller the IFN, the more likely the service is to assume a single responsibility. The IFN for the system is the average of all IFN (Jin et al., 2019).

Average domain redundancy (ADR). A favorable microservice design avoids duplication of responsibilities across services. Mazlami, Cito & Leitner (2017) computed the average domain redundancy metric as a proxy to indicate the amount of domain-specific duplication or redundancy between the services on a normalized scale between 0 and 1, where we favor service recommendations with lower ADR values (Mazlami, Cito & Leitner, 2017).

Absolute importance of the service (AIS). The number of clients that invoke at least one operation of a service’s interface (Rud, Schmietendorf & Dumke, 2006).

Absolute Dependence of the Service (ADS). The number of other services that service S depends on, i.e., the number of services from which S invokes at least one operation (Rud, Schmietendorf & Dumke, 2006).

Services interdependence in the system (SIY). The number of service pairs that are bi-directionally dependent on each other (Rud, Schmietendorf & Dumke, 2006).

Dependencies composition. Cojocaru, Uta & Oprescu (2019) defined dependencies composition as “The test assesses how balanced outward dependencies are across the microservices, by counting the outward dependencies each microservice has toward its peers. The algorithm constructs a dependency graph of the system where each dependency represents a communication path utilized for exchanging data between two components of the system” (Cojocaru, Uta & Oprescu, 2019).

Strongly connected components (SCC). SCC identifies strongly connected components on the previously mentioned dependency graph using Tarjan’s algorithm. If cycles are detected in the communication paths, then the respective services should be aggregated into one microservice. The score is divided by the total number of microservices within the system (Cojocaru, Uta & Oprescu, 2019).

Silhouette score. Nunes, Santos & Rito Silva (2019) define the silhouette score as “the difference between the mean nearest-cluster distance a and the mean intra-cluster distance b divided by the greatest of a and b. This score ranges its values from −1 to 1, representing incorrect clustering (samples on wrong clusters) and highly dense clustering, respectively. This metric creates a parallelism with the overall coupling of the clusters of the system, as our objective was to obtain a high intra-cluster similarity and a low inter-cluster similarity, so the partition between clusters is well defined” (Nunes, Santos & Rito Silva, 2019).

Perepletchikov et al. (2007) proposed a set of design-level metrics to measure the structural attribute of coupling in service-oriented systems, which can be adapted to microservices (Perepletchikov et al., 2007).

Cohesion metrics

Cohesion and coupling are two contrasting goals. A solution balancing high cohesion and low coupling is the goal for developers. Candela et al. (2016) employed a two-objective approach aimed at maximizing package cohesion and minimizing package coupling. They used class dependencies and structural information to measure the structural cohesion, which can be adapted to microservices. The metrics used in the related work are listed below:

Lack of cohesion. Lack of cohesion of classes for the J_th package (P_j) measured as the number of pairs of classes in P_j with no dependency between them (Candela et al., 2016). Al-Debagy & Martinek (2020) used the metric in a different way as “It is based on Henderson-Sellers’s lack of cohesion metrics (Al-Debagy & Martinek, 2020). But the proposed version is modified to be applicable for microservices’ APIs. It works by finding how many times a microservice has used a specific operation’s parameter, divided by the product of the number of operations multiplied by the number of unique parameters”. Candela et al. (2016) used lack of structural cohesion to measure the lack of cohesion between classes divided by the number of packages, and they also defined a lack of conceptual cohesion as a metric (Candela et al., 2016).

Relational cohesion. Relational cohesion was defined as “the ratio between the number of internal relations and the number of types in a package (service). Internal relations include inheritance between classes, invocation of methods, access to class attributes, and explicit references like creating a class instance. Higher numbers of RC indicate higher cohesion of a package (service)” (Larman, 2004) cite by (Li et al., 2019).

Cohesion at the domain level (CHD). The cohesiveness of interfaces provided by a service at the domain level. The higher the CHD, the more functionally cohesive that service is (Jin et al., 2019).

Average cohesion at the domain level (Avg. CHD). The average of all CHD values within the system (Jin et al., 2019).

Cohesion at the message level (CHM). The cohesiveness of the interfaces published by a service at the message level. The higher a service’s CHM, the more cohesive the service is, from an external perspective. CHM is the average functional cohesiveness (Jin et al., 2019).

Service interface data cohesion (SIDC). The cohesion of a given service S with respect to the similarity of parameter data types of its interface’s operations (Perepletchikov, Ryan & Frampton, 2007).

Service Interface Usage Cohesion (SIUC). The cohesion of a given service S based on the invocation behavior of clients using operations from its interface (Perepletchikov, Ryan & Frampton, 2007).

Entities composition. According to Cojocaru, Uta & Oprescu (2019), “entities composition assesses whether the entities are equally distributed among the proposed microservices and no duplicates, which might break the cohesion, exist. They define an entity as the class, or action of the service” (Cojocaru, Uta & Oprescu, 2019).

Relation composition. According to Cojocaru, Uta & Oprescu (2019) “relation composition assesses the quantitative variation in published language per relation. It applies the concept of relative assessment to entities shared between the services via their communication paths. The test identifies services communicating much more data than their peers, and thus potential communication bottlenecks” (Cojocaru, Uta & Oprescu, 2019).

Responsibilities composition. Cojocaru, Uta & Oprescu (2019) stated that the responsibilities composition “assesses to what extent the use case responsibilities are equally distributed among the proposed microservices. It uses the coefficient of variation between the number of use case responsibilities of each microservice. Services having relatively more responsibility may imply low cohesion: a service providing multiple actions violates the single responsibility principle” (Cojocaru, Uta & Oprescu, 2019).

Semantic similarity: According to Cojocaru, Uta & Oprescu (2019) “semantic similarity uses lexical distance assessment algorithms to flag the services that contain unrelated components or unrelated actions hindering cohesion” (Cojocaru, Uta & Oprescu, 2019).

Perepletchikov, Ryan & Frampton (2007) “reviewed categories of cohesion initially proposed for object-oriented software in order to determine their conceptual relevance to service-oriented designs”; and proposed a set of metrics for cohesion that can be adapted for microservices (Perepletchikov, Ryan & Frampton, 2007).

Complexity metrics

The complexity of microservices should be low, so that they can be changed within several weeks, rewritten, and improved quickly. If the complexity is high, then the cost of change is higher. Measuring complexity is fundamental for developing microservice-based applications. The metrics used by the authors of the papers are listed below.

Function points. A method for measuring the size of a software. A function point count is a measurement of the amount of functionality that software will provide (Totalmetrics.com, 2020).

COSMIC function points. Focuses on data movements between different layers. One of the benefits of the COSMIC method is that it can estimate the size in the planning phase, based on the user’s functional requirements. The four main data group types are: entry, exit, read and write. The COSMIC function point calculation is aimed at measuring the system at the time of planning. This size calculation can be used for estimating efforts (Vural, Koyuncu & Misra, 2018).

Total response for service (TRS). The sum of all responses for operation (RFO) values for all operations of the interface of service S (Perepletchikov et al., 2007).

Number of singleton clusters (NSC). Nunes, Santos & Rito Silva (2019) said “that having more than two singleton clusters is considered negative. Considering a final microservice architecture with clear functional boundaries established, it is likely that there are not two services in which their content is a single domain entity” (Nunes, Santos & Rito Silva, 2019).

Maximum cluster size (MCS). Nunes, Santos & Rito Silva (2019) “MCS should not be bigger than half of the size of the system. Even with a cluster size inside this range, there is also a dependency regarding the number of entity instances that are part of the aggregate” (Nunes, Santos & Rito Silva, 2019).

Performance metrics

Performance is a critical point of microservice-based applications. The selected papers used eight performance metrics:

The number of calls or requests. The number of times that a microservice is called.

The number of rejected requests. The number of times that a microservice does not respond or exceeds the time limit.

Response or execution time. The execution time of the invoked service.

Interaction number (IRN). The number of calls for methods among all pairs of extracted microservices. The smaller is the IRN, the better the quality of candidate microservices as a low IRN reflects loose coupling (Saidani et al., 2019).

Number of executions. The number of test requests sent to the system or microservices.

Maximum request time. The maximum time for a request (output) made from one microservice to another.

Maximum response time: The maximum response time is that of a call (input) or request to the system or microservice. It is the time to process a response to another microservice.

Number of packets sent: The packets sent to the system or microservice.

Ren et al. (2018) (P29) they used package analysis (PA), static structure analysis (SSA), class hierarchy analysis (CHA), static call graph analysis (SCGA), and combined static and dynamic analysis (CSDA) to evaluate migration performance. However, they did not explain the details of the performance analysis test or the metrics they used (Ren et al., 2018).

Other quality attributes metrics

Few metrics were directly related to quality attributes. The metrics proposed in the revised works are defined as follows:

Cost of quality assurance. It can be calculated by adding up the time spent by testers validating not only the new features but also the non-regression on existing ones, along with the time spent on release management (Gouigoux & Tamzalit, 2017).

Cost of deployment. The time spent by operational teams to deploy a new release, in man-days; it decreases greatly as teams automate deployment (Gouigoux & Tamzalit, 2017).

Security impact. The security policy applied to requirements or services. Assets and threats identified lead to deployed security mechanisms, which form security policies. Ahmadvand & Ibrahim (2016) mapped the identified policies to the corresponding functional requirements, mainly based on their access to the system assets. Security impact is a qualitative value (low, medium, high) (Ahmadvand & Ibrahim, 2016).

Scalability impact. Ahmadvand & Ibrahim (2016) define the Scalability impact as the required level of scalability (high, medium, low) to implement a a functional requirement or service. Defining the requirements at design time for a software system to be scalable is a challenging task. Ahmadvand & Ibrahim (2016) think that a requirements engineer should answer a question such as “What is the anticipated number of simultaneous users for this functionality?” (Ahmadvand & Ibrahim, 2016).

Computational resources metrics

The computational resources are all the software and hardware elements necessary for the operation of the microservice-based applications. The proposed metrics are listed.

Average of memory. The average memory consumption for each microservice or application.

Average of disk. The average of disk consumption for each microservice or application.

Average of network. The average network bandwidth consumption for the entire system; Kb/s used by system or microservice (De Alwis et al., 2019).

Average of CPU. The average of the CPU consumption by the system or microservice.

Service composition cost (SCC). Homay et al. (2019) stated that “identifying which existing functionalities in the service are consuming more resources is not an easy task. Therefore, we suggest relying on each request that a service provider receives from a service consumer. Because each request is a chain of stats or activities that needs to be satisfied inside of the service provider to generate a related response. The cost-of-service composition for the service s will be equal to the maximum cost of requests (routes)” (Homay et al., 2019).

Service decomposition cost (SDC). According to Homay et al. (2019), “By refining a service into smaller services, we will make some drawbacks. The SDC is a function that calculates the overhead of refining the service s into smaller pieces” (Homay et al., 2019).

Team metrics

Each microservice can be developed by a different team, and with different programming languages and database engines. It is important to consider metrics that allow analysis of microservices’ granularity and its impacts on the development team. The proposed metrics in the analyzed are as follows:

Team size reduction (TSR). Reduced team size translates to reduced communication overhead and thus more productivity and the team’s focus can be directed toward the actual domain problem and service for which it is responsible. TSR is a proxy for this team-oriented quality aspect. Let RM be a microservice recommendation for a monolith M. TSR is computed as the average team size across all microservice candidates in the RM divided by the team size of the original monolith M (Mazlami, Cito & Leitner, 2017).

Commit count. The number of commits in the code repository made by the developers.

We found very few metrics related to the development team. This can be an interesting topic for future research.

Source code metrics

The source code is one of the most important sources for analyzing certain characteristics of an application. Some authors have used it to identify microservices and define their granularity. The proposed metrics are described below:

Code size in lines of code. The total size of the code in the repository, in terms of in lines of code, microservices’ lines of code, or application’s lines of code.

The number of classes per microservice. Helps to understand how large the identified microservice is and to identify if any microservice is too big compared to others. The number of classes should be minimized because a smaller number of classes implies more independent development of the microservice (Taibi & Syst, 2019).

The number of duplicated classes. In some cases, two execution traces will have several classes in common. The number of duplicated classes helps one to reason about the different slicing options, considering not only the size of the microservices but also the number of duplications, that will be then reflected in the microservices’ development. Duplicated classes should be avoided since duplication adds to the system’s size and maintenance (Taibi & Syst, 2019).

Internal co-change frequency (ICF). How often entities within a service change together as recorded in the revision history. A higher ICF means that the entities within this service will be more likely to evolve together. The ICF is the average of all ICFs within the system (Jin et al., 2019).

External co-change frequency (ECF). How often entities assigned to different services change together, according to the revision history. A lower ECF score means that entity pairs located in different services are expected to evolve more independently. Similarly, ECF is the average ECF value of all services within the system (Jin et al., 2019).

The ratio of ECF to ICF (REI). The ratio of co-change frequency across services vs. the co-change frequency within services. The ratio is expected to be less than 1.0 if co-changes happen more often inside a service than across different services. The smaller the ratio is, the less likely co-changes are across services, and the extracted services tend to evolve more independently. Ideally, all co-changes should happen inside the services. REI is calculated as ECF divided by ICF (Jin et al., 2019).

Modularity quality measure. The modularity of a component or service can be measured from multiple perspectives, such as structural, conceptual, historical, and dynamic dimensions(Candela et al., 2016). They extend the modularity quality (MQ), as defined by Mancoridis et al. (1998) as structural and conceptual dependencies, using structural modularity quality and conceptual modularity quality to assess the modularity of service candidates. Structural modularity quality (SMQ) measures the quality of modularity from a structural perspective. The higher the SMQ, the better modularized the service is. On the other hand, conceptual modularity quality (CMQ), similarly measures modularity quality from a conceptual perspective. The higher the CMQ, the better (Jin et al., 2019).

Granularity metrics

Measuring granularity is complex. Granularity is related to size, including the number of functionalities or services that the application or microservice will have. It is also related to coupling and cohesion. Being more granular implies that microservice has no dependencies and can function independently, as an independent and encapsulated piece. Six granularity metrics were identified:

Weighted service interface count (WSIC): WSIC(S) is the number of exposed interface operations of service S. The default weight is set to one. Alternate weighting methods, which need to be validated empirically, can take into consideration the number and the complexity of data types of parameters in each interface (Hirzalla, Cleland-Huang & Arsanjani, 2009). WSIC(S) is the number of exposed interface operations of service S. Operations can be weighted based on the number of parameters or their granularity (e.g., a complex nested object) with the default weight being set to one (Bogner, Wagner & Zimmermann, 2017a).

Component Balance (CB): The CB is a system-level metric to evaluate the appropriateness of granularity, i.e., if the number and size uniformity of the components (in this case, services) are in a favorable range for maintainability (Bouwers et al., 2011).

Operation number (OPN): The OPN is used to compute the average number of public operations exposed by an extracted microservice to other candidate microservices. The smaller the OPN is the better (Saidani et al., 2019).

Number of microservices: The number of microservices that are part of the system or application.

Lines of code: The lines of code measure the number of lines of code in the microservice. Additionally, it may consider the total size of the code in the repository.

Number of nanoentities: Cojocaru, Uta & Oprescu (2019) stated that “the number of nanoentities (attributes or fields of a class) computes the number of nanoentities assigned to each proposed service, storing the result as a floating-point parameterized list. The list’s length is equal to the number of services found in the system model specification file” (Cojocaru, Uta & Oprescu, 2019).

The fundamentals of microservices suggest that they must have low coupling, high cohesion, and low complexity. Based on the described metrics, a model or method could be defined that uses artificial intelligence to determine the most appropriate dimensioning and size for microservices. Some have already been defined, mainly for migrations from monoliths to microservices. The number of microservices, their size, and their computational complexity directly affect the use of computational resources and therefore their cost of deployment. This is an interesting topic for future research.

In conclusion, some papers used metrics to evaluate the granularity of the microservices, including coupling, cohesion, number of calls, number of requests, and response time, although few methods or techniques use complexity as a metric, even though it seems fundamental for microservices. More research that considers design-level metrics is needed to define the granularity of the microservices that are part of an application, as well as research proposing models, methods, or techniques to determine the most appropriate granularity.

Runtime characteristics

In this section, we detail the runtime quality attributes and the way they were addressed by the papers, whether they used metrics to evaluate their proposals.

• Scalability, performance, and reliability (fault tolerance) were used by only one paper (P2). P2 proposed a re-implementation of otoo.de (a real-life case study). They defined the granularity through vertical decomposition, they used DevOps including continuous deployment, to deliver features quickly to customers. Team organization is crucial for success, this organization was based on Conway’s Law. Full automation of quality assurance and software deployment allows for early fault and error detection, thus reducing repair times both during development and during operations (Hasselbring & Steinacker, 2017). This paper did not propose metrics for evaluation.

• Scalability and performance were used by two papers (P10, P29); P10 proposed an automatic decomposition method, which was based on a black-box approach that mines the application access logs using a clustering method to discover URL partitions having similar performance and resource requirements. Such partitions were mapped to microservices (Ahmadvand & Ibrahim, 2016). The metrics used in this paper were performance metrics (response time SLO violations, number of calls, number of rejected requests, and throughput) and computational resource metrics (Avg. CPU, number of virtual machines used, and allocated virtual machines). P29 used the source code and the runtime logs in a semi-automatic method, it used granularity, performance, and source code metrics to evaluate the decompositions. They presented a program analysis-based method to migrate monolith legacy applications to microservices architecture; this method used a function call graph, a Markov chain model to represent migration characteristics, and a k-means hierarchical clustering algorithm (Ren et al., 2018).

• Only performance was used by two papers (P4, P13). P4 examined the granularity problem of the microservice and explored its effect on the latency of the application. Two approaches for the deployment of microservices were simulated; the first one with microservices in a single container, and the second one with microservices divided into separate containers. They discussed the findings in the context of the Internet of Things (IoT) application architectures (Shadija, Rezai & Hill, 2017); that paper corresponds to an evaluation or comparison, it is not a method to define the microservice granularity; it used performance metrics (response time and the number of calls). P13 presented three formal coupling strategies and embedded those in a graph-based clustering algorithm: (1) logical coupling, (2) semantic coupling, and (3) contributor coupling. The coupling strategies rely on meta-information from monolithic code bases to construct a graph representation of the monoliths that are in turn processed by the clustering algorithm to generate recommendations for potential microservice candidates in a refactoring scenario; P13 was the only one that proposed development team based metrics; logical coupling, average domain redundancy, contributor coupling, semantic coupling, commit count, contributor count, and lines of code were the metrics used by this paper.

• Scalability and security were used by one paper (P11). P11 proposed a methodology, consisting of a series of steps and activities that must be carried out to identify the microservices that will be part of the system. It is based on the use cases and the analysis made by the architect in terms of the scalability and security of each use case, as well as the dependencies with the other use cases (Ahmadvand & Ibrahim, 2016); this paper used the following metrics: dependency weight, security impact, and scalability impact (qualitative metrics).

• Scalability, performance, and availability were addressed by two papers (P12, P21). P12 presented discovery techniques that help identifying the appropriate parts of consumer-oriented business systems that could be redesigned as microservices with desired characteristics such as high cohesion, low coupling, high scalability, high availability, and high processing efficiency (De Alwis et al., 2018). They proposed microservice discovery algorithms and heuristics. It was an automatic method that used coupling (structural coupling), cohesion (lack of cohesion), computational resources (avg. memory, avg. disk), and performance metrics (number of requests, execution time). P21 was a semi-automatic method, a genetic algorithm with semantic similarity based on DISCO and non-dominated sorting genetic algorithm-II (NSGAII). That paper presented four microservice patterns, namely object association, exclusive containment, inclusive containment, and subtyping for ‘greenfield’ (new) development of software while demonstrating the value of the patterns for ‘brownfield’ (evolving) developments by identifying prospective microservices (De Alwis et al., 2019). The metrics used by that paper were: structural coupling, lack of cohesion, the average CPU, the average of the network, number of executions, and the number of packets sent.

Software as an artifact characteristic

Only two software as an artifact characteristic were used, which were maintainability and modularity. Only maintainability was used by one paper (P3); whereas maintainability, and modularity were used by (P16), which proposed the most complete method.

P3 used a balance between the cost of quality assurance and the cost of deployment for defining microservices granularity, it was a manual method. The choice of granularity should be based on the balance between the costs of quality assurance and the cost of deployment (Gouigoux & Tamzalit, 2017).

P16 presented a framework that consists of three major steps: (1) extracting representative execution traces, (2) identifying entities using a search-based functional atom grouping algorithm, and (3) identifying interfaces for service candidates (Jin et al., 2019). They also presented a comprehensive measurement system to quantitatively evaluate service candidate quality in terms of functionality, modularity, and evolvability. P16 proposed an automatic method, which used a search-based functional atom grouping algorithm and a non-dominated sorting genetic algorithm-II (NSGA II). The evaluation metrics were coupling (Integrating interface number), cohesion at message level, cohesion at domain level, structural modularity quality, conceptual modularity quality, internal co-change frequency (ICF), external Co-change frequency (ECF), and the ratio of ECF to ICF.

Quality attributes and artificial intelligence

In some cases, artificial intelligence techniques are being used to improve the quality attributes of microservices. For example:

Alipour & Liu (2017) proposed two machine learning algorithms and predicted the resource demand of microservice backend systems, as emulated by a Netflix workload reference application. They proposed a microservice architecture that encapsulates monitoring functions of metrics and learning of workload patterns. Then, this service architecture is used to predict the future workload for making decisions about resource provisioning (Alipour & Liu, 2017).

Prachitmutita et al. (2018) proposed a new self-scaling framework based on the predicted workload, with an artificial neural network, a recurrent neural network, and a resource scaling optimization algorithm used to create an automated system to manage the entire application with Infrastructure-as-a-service (IaaS) (Prachitmutita et al., 2018).

Ma et al. (2018) proposed an approach, called scenario-based microservice retrieval (SMSR), to recommend appropriate microservices for users based on the Behavior-driven Development (BDD) test scenarios written by the user. The proposed service retrieval algorithm is based on word2vec, an automatic learning method widely used in natural language processing (NLP) to perform service filtering and calculate service similarity (Ma et al., 2018).

Abdullah, Iqbal & Erradi (2019) proposed a complete automated system for breaking down an application into microservices, implementing microservices using appropriate resources, and automatically scaling microservices to maintain the desired response time (Abdullah, Iqbal & Erradi, 2019).

Artificial intelligence can help to improve and control different characteristics of microservices, especially those related to improving quality attributes. Some proposals have been made in this regard, but more research is needed.

Finally, we identified the automatic and semi-automatic methods, which used metrics and addressed some quality attribute to define the granularity (see Table 8). Only six papers meet those conditions (P10, P12, P13, P16, P21, and P29), and were the more suitable methods to define the granularity of microservices.

Also, we identified semi-automatic methodologies, which used metrics to define the granularity, only two papers were found (P14 and P22); there were no automatic methodologies, most of them were manual methodologies (P11, P17, P18, and P26) and only one was semi-automatic but it did not use metrics (P25).

P14 was a data flow-driven decomposition algorithm. Their methodology, first, the use case specification and business logics were analyzed based on requirements; second, the detailed dataflow diagrams (DFD) at different levels and the corresponding process-datastore version of DFD (DFD PS) are constructed from business logics based on requirement analysis; third, we designed an algorithm to automatically condense the DFD PS to a decomposable DFD, in which the sentences between processes and data stores are combined; last but not least, microservice candidates were identified and extracted automatically from the decomposable DFD (Li et al., 2019). The metrics used by P14 were coupling (afferent coupling, efferent coupling, instability) and cohesion (relational cohesion) metrics. P14 did not address any quality attribute directly.

P22 proposed a clustering algorithm applied to aggregate domain entities. It used coupling (silhouette score) and complexity (number of singleton clusters, maximum cluster size) metrics. The authors proposed an approach to the migration of monolith applications to a microservice architecture that focused on the impact of the decomposition on the monolith business logic (Nunes, Santos & Rito Silva, 2019).