GranMicro: A Black-Box Based Approach for Optimizing Microservices Based Applications

Dynamic Evaluation of Microservice Granularity Adaptation

“…We consider controlled experiment on Filmflix to be the most appropriate evaluation means for investigating metrics of concern; it provides significant scale for answering them. In particular, looking at microservice-related literature (e.g., [1,19,22,24,31,32,42,43,58], and [15]), we observed that microservice-specific proposed architectural design support processes can be evaluated on case studies of comparable scale and scope of functionality to Filmflix.…”

“…The common practice in developing microservices is to use design patterns; the practice can implicitly or explicitly inform reasoning about granularity. Examples of documented guidelines to support this reasoning include [21,38,44,52]).…”

Systematic scalability analysis for microservices granularity adaptation design decisions

“…In that scenario, the scalability dimension is the number of concurrent requests while the scalability metric is the response time of the system. number of available virtual IP addresses A presentation of the current solutions for modelling, integrating, testing, deploying, and monitoring microservices; all these dimensions affect or are affected by granularity adaptation decisions hence the presentation in this book can act as procedural guidance for granularity adaptation decision-making [24] A series of microservice decomposition strategies mostly based on isolating independent bounded contexts [ An industrial experience reporting on data-driven granularity adaptation decisions [28] An industrial experience reporting on a monolithic subsystem migration to microservices [29] Case study application End user base size, number of countries the application is serving, audit compliance considerations, data transport and synchronisation costs downtime rate after pursuing adaptation An industrial experience advocating for microservitization through "Everythingas-a-Service" [30] Discussion technology migration costs, number of interdependent teams A case study describing procedural extraction of microservices from a monolithic architecture [31] Discussion Number of interdependent database tables,number of RESTful APIs Describing a pattern for extracting microservices from monoliths based on incrementally building new functionalities surrounding existing ones [32] Describing a pattern for extracting microservices driven by the event flow throughout the architecture [33] Proposal of a technique which identifies candidates for microservice decomposition depending on whether they are client-, server-or data-related [34] Case study application Code base size (measured in lines of code), number of shared database tables, number of cross-cutting functionalities, number of microservices per crosscutting functionality Issues related to componentisation, organisation, endpoints and messaging mechanisms in the microservice architecture are discussed; these issues affect granularity adaptation hence this discussion can support the decision-making process [35] An experience report on a migration to decompose an existing application into microservices and on how to decompose an ongoing legacy modernization project [36] Case study application Technology migration costs, number of bounded contexts, number of access points to back-end microservices, number of non-user related functionalities, volume of read/write database operations, infrastructure platform migration costs transactional consistency after pursuing adaptation A microservice decomposition approach based on extending the usage of web mining techniques and clustering algorithms to characterise the workloads received by a microservice application [37] Case study application Volume of requests received by the application An experience reporting on a migration process to decompose an existing application into microservices and hte lessons learnt from this transition [38] Discussion end user base size, complexity of end user requirements…”

Microservice Architectures for Advanced Driver Assistance Systems: A Case-Study

“…It is different with systems that are created with the component-based architecture, where it also occurs that a system consists of many components. Since components are units of functionality and not containerized, they are, however, generally more tightly coupled [10]. In both cases, it is comparatively easier to keep track of the entries for a possible attack.…”