Information and Data we collect We may collect the following information: Name Company name your contact information including email address demographic information such as country, preferences and interests other information relevant to surveys, conferences, papers or workshops How we use this information or data Information we collect helps us to understand your interest in metrics and measurements and to provide you with a better membership experience or potential membership service.
We also use information to understand what interests or requirements members, potential members or individuals have in terms of us organising conferences, workshops or other resources, and in particular for the following reasons: Internal record keeping.
Using the information to improve our membership services. We may periodically send promotional emails about upcoming conferences, workshops, presentations, meetings, tools or other information relating to metrics and measurements which we think you may find interesting using the email address which you have provided.
There may be occasions when we need to use your information to contact you for the purposes of conducting surveys on these topics, or your views on membership for example, or to collect opinions on how to improve this website to keep it relevant to those with an interest in metrics and measurements. Such contact with you will be by email. The Security measures we take to keep information and data safe COSMIC is consistently and constantly committed to ensuring that any information provided is secure.
Links to other websites Our website contains links to other websites of interest. Controlling your personal information Any information provided to us in respect of membership, potential membership or as an individual is for the sole use of COSMIC.
Any methodology Devops, Agile, ScaledAgile, Waterfall, software maintenance, and digital transformations. Open Engineering Standard Certification and publications controlled by a community of expert volunteers. The engineering standard for measuring software size.
Mature, Valid, Consistent Functional size measurement is an important basis for measuring productivity and for estimating effort for software activities.
The measurement manual and other documents translated into other languages. Therefore, the search strings were as follow:. Additionally, the decomposition of monolithic applications to microservices is an important research topic, so we include this word. The main objective of the work was to identify the methods, techniques or methodologies used to determine the microservices granularity.
QS1 and QS2 addresses all research question; for each of the proposals selected in each QS, the metrics used, and the quality attributes addressed were identified.
The search in these databases, yield results for QS1 and results for QS2. The search was performed in July Data extraction strategy. First, papers were tabulated; second, duplicated papers were removed; third, title, abstract, and conclusions of all papers were reviewed and analyzed. Each coauthor of this report carried out this process. Study selection criteria and procedures. We selected primary research papers that make a specific proposal methodology, model, technique, or method about microservices granularity, including migrations from monolith to microservices and decompositions of systems in microservices.
After obtaining the relevant studies, the inclusion and exclusion criteria were applied see Table 1. We excluded any paper about monolith migrations that were not directly related to the definition of microservice granularity.
We also excluded papers that proposed methods, techniques, or models for SOA, web services or mobile services. Synthesis of the extracting data. Each of the selected papers was evaluated in full-text form, taking detailed note of the work and the contributions made. The review process was carried out as follow: We download the full-text paper.
Each co-author uses the classification criteria on the paper, using the table presented in the Appendix A; this was carried out by each co-author independently. We discussed and analyzed the results obtained by each author, resolving doubts and contradictions and the results are presented in Appendix A. The results of applying the research protocol is presented in Fig. To analyze the works presenting definitions of the granularity of microservices, classification criteria were defined.
These criteria were based on the classification performed by Wieringa et al. To answer the research questions, we added the classification criteria in each paper: metrics, stage of the development process, technique used, and quality attributes studied or analyzed; namely:.
Metrics used: Which metrics are used to define the granularity of microservices? Development process phases: Phases of the development process on which the work focuses.
Research strategies: Includes solution proposal, validation research, experience paper, opinion paper, philosophical paper, and evaluation research. Quality attribute studied: The Quality attributes considered in the proposal, such as performance, availability, reliability, scalability, maintainability, security, and complexity. Research contribution: Type of contribution made in the article; namely, method, application, problem formulation, reference architecture, middleware, architectural language, design pattern, evaluation, or comparison.
Experimentation type: Type of experimentation used to validate the proposal; namely experiment, case study, theoretical, or other. Technique used: This criterion describes the technique, method or model used to define the granularity of the microservices. Input data: Type of input data used to identify the microservices i. Type of case study: This criterion determines if the case study is a toy example hypothetical case or a real-life case study.
We identified the case study. Automatization level: This criterion determines the level of automation of the proposed technique, if it is manual, automatic, or semi-automatic. Finally, results were presented in four sections: first, the classification of the selected papers; second, the main contributions and research gaps in sizing and definition of microservice granularity were detailed; third, metrics were described an ordered by year and type; and fourth, quality attributes were detailed, and results were discussed, leading to conclusions presented in this article.
The search process took place in July The search in the databases of scientific publications when applying the search strings QS1 and QS2 related to the granularity of the microservices yield and works respectively see Table 2. After applying the inclusion and exclusion criteria, 29 papers were selected that address the definition of the granularity of microservices.
The summarized results of this systematic literature review are synthesized in Fig. For RQ1, we identified the papers that propose a method, model, or methodology to define the microservice granularity; metrics are fundamental because they allow one to measure, monitor, and evaluate any aspect of a microservice, thus defining or determining the appropriate granularity of a microservice.
For RQ2, we identified metrics used to evaluate microservice granularity and their decomposition. Figure 2 shows the type and number of metrics and whether it was applied to microservice, system, development process, or development team.
Finally, for RQ3 we synthesized the works that address quality attributes to evaluate microservices granularity. Appendix A shows the tabulated data and the results of the evaluation of classification criteria. All selected papers were published between and the beginning of two in , seven in , six in , 12 in , and two in The development process phases addressed by each proposal are shown in Fig. Several papers emphasize more than one phase, e. The papers that do not address migration do focus on identifying microservices in the design phase; therefore, defining the size and granularity of microservices from the design phase on is key, because it has implications for development, testing and deployment.
On the research strategy see Fig. On the type of contribution see Fig. On the validation approach see Fig. More than half of studies 13 of 29 validated their proposals using realistic but not real—hypothetical case studies, and the remaining almost-half 14 of 29 used real-life case studies, real-life case studies achieve better validation than hypothetical case studies.
Even better, some studies 8 used actual open-source projects. The case studies found in the reviewed articles are summarized in Table 4 ; they are valuable resources to validate future research and to compare new methods with those identified in this review.
The granularity of microservices involves defining their size and the number that will be part of the application. The size, dimension, or granularity of microservices have traditionally been defined as follows: Trial and error, depending on the experience of the architect or developer. Richardson proposed four decomposition patterns, which allow for the decomposition of an application into services: 1 Decompose by business capability: define services corresponding to business capabilities; 2 decompose by subdomain: define services corresponding to DDD subdomains; 3 self-contained service: design services to handle synchronous requests without waiting for other services to respond.
Zimmermann et al. The patterns are divided in five categories: 1 foundation, 2 responsibility, 3 structure, 4 quality, and 5 evolution. These patterns are an important reference for developing microservice-based applications. There is no specific pattern that helps to determine the number of microservices and their size, that is, the number of operations it must contain Zimmermann et al.
The size of the microservice or optimal granularity is one of the most discussed properties and there are few patterns, methods, or models to determine how small a microservice should be.
In this respect, some authors have addressed this problem and proposed the solutions summarized in Table 5. Migration, The proposal is used in migration from monolith to microservices; From Scratch, The proposal can be used for development from scratch; Ref.
The proposed techniques were classified into manual, semi-automatic, or automatic techniques; manual techniques are methods, procedures, or methodologies performed by the architect or developer decomposing systems following a few steps. Automatic techniques use some type of algorithm to generate decomposition, and the system generates the decomposition.
Semi-automatic combine one part made manually and with another made automatically. Most papers proposed manual procedures to identify the microservice granularity 15 papers ; some proposals were automatic eight papers and few proposals paper were semi-automatic six papers. The papers from and are mostly manual methods or methodologies that detail the way to decompose or determine microservices, using DDD, domain engineering, or a specific methodology.
Later, the papers from , and propose semi-automatic, and automatic methods that use intelligent algorithms and machine learning mostly focused on migrations from monolith to microservices. We can observe a chronological evolution in the proposals, the type of techniques used to define the granularity of the microservices that are part of an application are presented in Fig.
Software metrics allow us to measure and monitor different aspects and characteristics of a software process and product, and there are metrics at the level of design, implementation, testing, maintenance, and deployment. These metrics allow understanding, controling, and improving of what happens during the development and maintenance of the software, to take corrective and preventive actions. We would have expected greater importance for metrics in automatic methods to validate granularity in microservice-based applications and evaluate decompositions yield by methods.
We identify metrics for coupling, cohesion, granularity, complexity, performance, use of computational resources, development team, source code, and so on see Table 6. We classified them into four groups: about development team, about microservices development process, about the system, and about each microservice.
Most identified metrics 40 focused on a microservice, and only two address the microservice development processes. There is a research gap for metrics to evaluate the full development process of microservice-based applications and their impact on the granularity of microservices.
Paper, paper number; Dev. Team, Development team; Dev. Process, Development process; App. Resource, Computational resource; Avg. The most used metrics are related to coupling 14 proposed metrics , followed by performance and cohesion 13 metrics , next, computational resources metrics eight metrics , and complexity and source code seven metrics ; see Fig.
More proposals that include more complexity metrics are required, as well as metrics related to the microservice development process. The other metrics were used by only one paper each. We found that 11 papers used coupling or cohesion metrics, and 5 papers used both. Only one P24 used coupling, cohesion, and complexity metrics.
The size and number of microservices that compose an application directly affects its maintainability. Automation of tests, continuous integration and deployment are essential especially when microservices and many distributed systems must be managed independently by each microservice. The metrics proposed by them can be used or adapted to determine the adequate granularity of the microservices that are going to be part of an application.
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. These coupling strategies can be used as metrics to define the granularity.
These metrics are defined as follows:. Dependency weight. 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.
Logical coupling. Semantic coupling. Basically, semantic coupling couples together classes that contain code about the same things, i. 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. 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.
Afferent coupling Ca. 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, cited by Li et al.
Instability I. Coupling between microservice CBM. 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. Average domain redundancy ADR. A favorable microservice design avoids duplication of responsibilities across services. Absolute importance of the service AIS. The number of other services that service S depends on, i.
Services interdependence in the system SIY. Dependencies composition. Strongly connected components SCC. If cycles are detected in the communication paths, then the respective services should be aggregated into one microservice. Silhouette score. Perepletchikov et al. Cohesion and coupling are two contrasting goals. A solution balancing high cohesion and low coupling is the goal for developers.
Candela et al. 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. Relational cohesion. Internal relations include inheritance between classes, invocation of methods, access to class attributes, and explicit references like creating a class instance.
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. Average cohesion at the domain level Avg. The average of all CHD values within the system Jin et al. Cohesion at the message level CHM. The cohesiveness of the interfaces published by a service at the message level. CHM is the average functional cohesiveness Jin et al.
Service interface data cohesion SIDC. Entities composition. Relation composition. It applies the concept of relative assessment to entities shared between the services via their communication paths. Responsibilities composition. It uses the coefficient of variation between the number of use case responsibilities of each microservice. 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.
Focuses on data movements between different layers. The four main data group types are: entry, exit, read and write. 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.
Number of singleton clusters NSC. Maximum cluster size MCS. 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.
Interaction number IRN. The number of calls for methods among all pairs of extracted microservices. 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. Ren et al. However, they did not explain the details of the performance analysis test or the metrics they used Ren et al. Few metrics were directly related to quality attributes. The metrics proposed in the revised works are defined as follows:. Cost of quality assurance. Cost of deployment. Security impact. The security policy applied to requirements or services. Assets and threats identified lead to deployed security mechanisms, which form security policies.
Scalability impact. Defining the requirements at design time for a software system to be scalable is a challenging task. 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.
Average of CPU. The average of the CPU consumption by the system or microservice. Service composition cost SCC. 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. Service decomposition cost SDC. According to Homay et al.
Each microservice can be developed by a different team, and with different programming languages and database engines. The proposed metrics in the analyzed are as follows:. Team size reduction TSR. TSR is a proxy for this team-oriented quality aspect.