Microservices

Code smells and architectural smells (also called bad smells) are symptoms of poor design that can hinder code understandability and decrease maintainability. Several bad smells have been defined in the literature for both generic architectures and specific architectures. However, cloud-native applications based on microservices can be affected by other types of issues. In order to identify a set of microservice-specific bad smells, researchers collected evidence of bad practices by interviewing 72 developers with experience in developing systems based on microservices. Then, they classified the bad practices into a catalog of 11 microservice-specific bad smells frequently considered harmful by practitioners. The results can be used by practitioners and researchers as a guideline to avoid experiencing the same difficult situations in the systems they develop. Microservices are currently enjoying increasing popularity and diffusion in industrial environments, being adopted by several big players such as Amazon, LinkedIn, Netflix, and SoundCloud. Microservices are relatively small and autonomous services that work together, are modeled around a business capability, and have a single and clearly defined purpose. 1,2 Microservices enable independent deployment, allowing small teams to work on separated and focused services by using the most suitable technologies for their job that can be deployed and scaled independently. 1,2 Microservices are a newly developed architectural style. Several patterns and platforms such as nginx (www.nginx.org) and Kubernetes (kubernetes.io) exist on the market. During the migration process, practitioners often face common problems, which are due mainly to their lack of knowledge regarding bad practices and patterns. 3,4 In this article, we provide a catalog of bad smells that are specific to systems developed using a microservice architectural style, together with possible solutions to overcome these smells. To produce this catalog, we surveyed and interviewed 72 experienced developers over the course of two years, focusing on bad practices they found during the development of microservice-based systems and on how they overcame them. We identified a catalog of 11 microservice-specific bad smells by applying an open and selective coding 5 procedure to derive the smell catalog from the practitioners' answers. The goal of this work is to help practitioners avoid these bad practices altogether or deal with them more efficiently when developing or migrating monoliths to microservice-based systems. As with code and architectural smells, which are patterns commonly considered symptoms of bad design, 1,6 we define microservice-specific bad smells (called " microservice smells " hereafter) as indicators of situations—such as undesired patterns, antipatterns, or bad practices—that negatively affect software quality attributes such as understandability, testability, extensibility, reusability, and maintainability of the system under development.

This is a short review article on how we tested Filipo's monolithic application and what has changed with the transition to mi-croservice architecture. Containers and microservices are becoming increasingly popular, providing additional capabilities. But like any other new technology, they put new challenges on developers. The proposed methodology is systematized as sequence of actions and flexible, therefore it is easy to understand and use. Optional performance of some activities, such as defining non-functional tests, allows the test process to focus on the specific needs of the user and performing step-by-step testing. The proposed methodology can be used by different specialists for different test purposes. Another advantage of the proposed methodology is that it uses a small set of test artifacts. When implementing full coverage tests based on the methodology, it is possible to achieve a high level of automation, where it is necessary to ensure only the tested business process.

The cloud is an emerging paradigm which leads the way for different approaches and standards. The architectural styles are evolving based on the requirements of the cloud as well. In recent years microservices is seen as the architecture style for scalable, fast evolving cloud applications. As part of this paper, a systematic mapping study was carried out around microservices. It is aiming to find out the current trends around microservices, the motivation behind microservices research, emerging standards and the possible research gaps. The obtained results can help researchers and practitioner in software engineering domain who want to be aware of new trends about SOA and cloud computing.

Beats-Per-Minute (BPM) is a microservice-based platform that provides a monitoring solution for the continuous acquisition, analysis and visualisation of health related data. BPM combines Commercial Off-The-Self (COTS) Activity Trackers and a scalable cloud-based infrastructure. This paper demonstrates the efficacy, reliability and integrity of BPM when utilised as a monitoring solution for health conditions, such as Cardio-vascular Disease. The results are indicative of the suitability of a microservice-based architecture for such a platform.

In the last years, cloud-native architectures have emerged as a target platform for the deployment of microservice architectures. The migration of existing monoliths into cloud-native applications is still in the early phase, and only few companies already started their migrations. Therefore, success and failure stories about different approaches are not available in the literature. This context connects also to the recently discussed DevOps context where development and continuous deployment are closely linked.

Microservice architecture is a cloud application design pattern that implies that the application is divided into a number of small independent services, each of which is responsible for implementing of a certain feature. The need for continuous integration of developed and/or modified microservices in the existing system requires a comprehensive validation of individual microservices and their co-operation as an ensemble with other microservices. In this paper, we would provide an analysis of existing methods of cloud applications testing and identify features that are specific to the microservice architecture. Based on this analysis, we will try to propose a validation methodology of the microservice systems.

Network Functions Virtualization (NFV), considered a key enabler of Network "softwarization", promises to reduce the capital and operational expenditure for network operators by moving packet processing from purpose-built hardware to software running on commodity servers. However, the state-of-the-art in NFV is merely replacing monolithic hardware with monolithic Virtual Network Functions (VNFs), the software that realizes different network functions (e.g., Firewalls, WAN Optimizers, etc.). Although this is a first step towards deploying NFV, common functionality is repeatedly implemented in monolithic VNFs. Repeated execution of such redundant functionality introduces processing overhead when VNFs are chained to realize Service Function Chains and leads to sub-optimal usage of infrastructure resources. This stresses the need for re-architecting the NFV ecosystem, from VNFs to their orchestration, through modular VNF design and flexible service composition. In that perspective, we make the case for using the microservice software architecture, proven to be effective for building large scale cloud applications from reusable and independently deployable components, to re-architect the NFV ecosystem. We also discuss the state-of-the-art in realizing modular VNFs from both industry and academia. Finally, we outline a set of research challenges for microservice-based NFV platforms.

The evolution of the power systems towards the smart grid paradigm is strictly dependent on the modernization of distribution grids. To achieve this target, new infrastructures, technologies and applications are increasingly required. This paper presents a smart metering infrastructure that unlocks a large set of possible services aimed at the automation and management of distribution grids. The proposed architecture is based on a cloud solution, which allows the communication with the smart meters from one side and provides the needed interfaces to the distribution grid services on the other one. While a large number of applications can be designed on top of the cloud, in this paper the focus will be on a real-time distributed state estimation algorithm that enables the automatic reconfiguration of the grid. The paper will present the key role of the cloud solution for obtaining scalability, interoperability and flexibility, and for enabling the integration of different services for the automation of the distribution system. The distributed state estimation algorithm and the automatic network reconfiguration will be presented as an example of coordinated operation of different distribution grid services through the cloud.

Microservices have been getting more and more popular in recent years, and several companies are migrating monolithic applications to microservices. Microservices allow developers to independently develop and deploy services, and ease the adoption of agile processes. However, many companies are still hesitant to migrate because they consider microservice as a hype or because they are not aware of the migration process and the benefits and issues related to migration. For this purpose, we conducted a survey among experienced practitioners who already migrated their monoliths to microservices. In this paper, we identify a process framework based on the comparison of three different migration processes adopted by the interviewed practitioners, together with the common motivations and issues that commonly take place during migrations.

A multilayered autoscaling gets an increasing attention both in research and business communities. Introduction of new virtualization layers such as containers, pods, and clusters has turned a deployment and a management of cloud applications into a simple routine. Each virtualization layer usually provides its own solution for scaling. However, synchronization and collaboration of these solutions on multiple layers of virtualization remains an open topic. In the scope of the paper, we consider a wide research problem of the autoscaling across several layers for cloud applications. A novel approach to multilayered autoscalers performance measurement is introduced in this paper. This approach is implemented in Autoscaling Performance Measurement Tool (APMT), which architecture and functionality are also discussed. Results of model experiments on different requests patterns are also provided in the paper.