Search

Cloud-native and microservice architectures have taken over the development world by storm. While being incredibly scalable and resilient, microservice architectures also come at the cost of increased overhead to build and maintain. Google's Service Weaver aims to simplify the complexities associated with implementing cloud-native systems by introducing the concept of a single modular binary composed of agent-like components, thereby abstracting away the microservice architecture notion of individual services. While Service Weaver presents a promising approach to streamline the development of cloud-native applications and addresses nearly all significant aspects of conventional cloud-native systems, there are existing tradeoffs affecting the overall functionality of the system. Notably, Service Weaver's straightforward implementation and deployment of components alleviate the overhead of constructing a complex microservice architecture. However, it is important to acknowledge that certain features, including separate code bases, routing mechanisms, resiliency, and security, are presently lacking in the framework., Comment: This paper is accepted for publication at the International Conference on Cloud Computing and Services Science (CLOSER) 2024

Architecture recovery tools help software engineers obtain an overview of their software systems during all phases of the software development lifecycle. This is especially important for microservice applications because their distributed nature makes it more challenging to oversee the architecture. Various tools and techniques for this task are presented in academic and grey literature sources. Practitioners and researchers can benefit from a comprehensive overview of these tools and their abilities. However, no such overview exists that is based on executing the identified tools and assessing their outputs regarding effectiveness. With the study described in this paper, we plan to first identify static analysis architecture recovery tools for microservice applications via a multi-vocal literature review, and then execute them on a common dataset and compare the measured effectiveness in architecture recovery. We will focus on static approaches because they are also suitable for integration into fast-paced CI/CD pipelines.

Microservices have been recognized for over a decade. They reshaped system design enabling decentralization and independence of development teams working on particular microservices. While loosely coupled microservices are desired, it is inevitable for dependencies to arise. However, these dependencies often go unnoticed by development teams. As the system evolves, making changes to one microservice may trigger a ripple effect, necessitating adjustments in dependent microservices and increasing maintenance and operational efforts. Tracking different types of dependencies across microservices becomes crucial in anticipating the consequences of development team changes. This paper introduces the Endpoint Dependency Matrix (EDM) and Data Dependency Matrix (DDM) as tools to address this challenge. We present an automated approach for tracking these dependencies and demonstrate their extraction through a case study., Comment: Accepted in ESOCC 2023

Microservice architecture gains momentum by fueling systems with cloud-native benefits, scalability, and decentralized evolution. However, new challenges emerge for end-to-end (E2E) testing. Testers who see the decentralized system through the user interface might assume their tests are comprehensive, covering all middleware endpoints scattered across microservices. However, they do not have instruments to verify such assumptions. This paper introduces test coverage metrics for evaluating the extent of E2E test suite coverage for microservice endpoints. Next, it presents an automated approach to compute these metrics to provide feedback on the completeness of E2E test suites. Furthermore, a visual perspective is provided to highlight test coverage across the system's microservices to guide on gaps in test suites. We implement a proof-of-concept tool and perform a case study on a well-established system benchmark showing it can generate conclusive feedback on test suite coverage over system endpoints., Comment: This paper is accepted for publication at ESOCC 2023

When developing and managing microservice systems, practitioners suggest that each microservice should be owned by a particular team. In effect, there is only one team with the responsibility to manage a given service. Consequently, one developer should belong to only one team. This practice of "one-microservice-per-developer" is especially prevalent in large projects with an extensive development team. Based on the bazaar-style software development model of Open Source Projects, in which different programmers, like vendors at a bazaar, offer to help out developing different parts of the system, this article investigates whether we can observe the "one-microservice-per-developer" behavior, a strategy we assume anticipated within microservice based Open Source Projects. We conducted an empirical study among 38 microservice-based OS projects. Our findings indicate that the strategy is rarely respected by open-source developers except for projects that have dedicated DevOps teams.

Testing microservice systems involves a large amount of planning and problem-solving. The difficulty of testing microservice systems increases as the size and structure of such systems become more complex. To help the microservice community and simplify experiments with testing and traffic simulation, we created a test benchmark containing full functional testing coverage for two well-established open-source microservice systems. Through our benchmark design, we aimed to demonstrate ways to overcome certain challenges and find effective strategies when testing microservices. In addition, to demonstrate our benchmark use, we conducted a case study to identify the best approaches to take to validate a full coverage of tests using service-dependency graph discovery and business process discovery using tracing., Comment: 7 pages

Microservice-based systems are often complex to understand, especially when their sizes grow. Abstracted views help practitioners with the system understanding from a certain perspective. Recent advancement in interactive data visualization begs the question of whether established software engineering models to visualize system design remain the most suited approach for the service-oriented design of microservices. Our recent work proposed presenting a 3D visualization for microservices in augmented reality. This paper analyzes whether such an approach brings any benefits to practitioners when dealing with selected architectural questions related to system design quality. For this purpose, we conducted a controlled experiment involving 20 participants investigating their performance in identifying service dependency, service cardinality, and bottlenecks. Results show that the 3D enables novices to perform as well as experts in the detection of service dependencies, especially in large systems, while no differences are reported for the identification of service cardinality and bottlenecks. We recommend industry and researchers to further investigate AR for microservice architectural analysis, especially to ease the onboarding of new developers in microservice~projects., Comment: The paper (10 pages) is accepted in ICPC 2023

Microservice system solutions are driving digital transformation; however, fundamental tools and system perspectives are missing to better observe, understand, and manage these systems, their properties, and their dependencies. Microservices architecture leads towards decentralization, which implies many advantages to system operation; it, however, brings challenges to their development. Microservice systems often lack a system-centric perspective that would help engineers better cope with system evolution and quality assessment. In this work, we explored microservice-specific architecture reconstruction based on static analysis. Such reconstruction typically results in system models to visualize selected system-centric perspectives. Conventional models involve 2D methods; however, these methods are limited in utility when services proliferate. We considered various architectural perspectives relevant to microservices and assessed the relevancy of the traditional method, comparing it to alternative data visualization using 3D space. As a representative of the 3D method, we considered a 3D graph model presented in augmented reality. To begin testing the feasibility of deriving such perspectives from microservice systems, we developed and implemented prototype tools for software architecture reconstruction and visualization of compared perspectives. Using these prototypes, we performed a small user study with software practitioners to highlight the potentials and limitations of these innovative visualizations used for common practitioner reasoning and tasks.

Microservices are supporting digital transformation; however, fundamental tools and system perspectives are missing to better observe, understand, and manage these systems, their properties, and their dependencies. Microservices architecture leans toward decentralization, which yields many advantages to system operation; it, however, brings challenges to their development. Microservices lack a system-centric perspective to better cope with system evolution and quality assessment. In this work, we explore microservice-specific architecture reconstruction based on static analysis. Such reconstruction typically results in system models to visualize selected system-centric perspectives. Conventional models are limited in utility when the service cardinality is high. We consider an alternative data visualization using 3D space using augmented reality. To begin testing the feasibility of deriving such perspectives from microservice systems, we developed and implemented prototype tools for software architecture reconstruction and visualization of compared perspectives.

Microservices bring various benefits to software systems. They also bring decentralization and lose coupling across self-contained system parts. Since these systems likely evolve in a decentralized manner, they need to be monitored to identify when possibly poorly designed extensions deteriorate the overall system quality. For monolith systems, such tasks have been commonly addressed through static analysis. However, given the decentralization and possible language diversity across microservices, static analysis tools are lacking. On the other hand, there are available tools commonly used by practitioners that offer centralized logging, tracing, and metric collection for microservices. In this paper, we assess the opportunity to combine current dynamic analysis tools with anomaly detection in the form of quality metrics and anti-patterns. We develop a tool prototype that we use to assess a large microservice system benchmark demonstrating the feasibility and potential of such an approach., Comment: 10 pages, 4 figures, IEEE SOSE 2022

It is well recognized that design patterns improve system development and maintenance in many aspects. While we commonly recognize these patterns in monolithic systems, many patterns emerged for cloud computing, specifically microservices. Unfortunately, while various patterns have been proposed, available quality assessment tools often do not recognize many. This article performs a grey literature review to find and catalog available tools to detect microservice API patterns (MAP). It reasons about mechanisms that can be used to detect these patterns. Furthermore, the results indicate gaps and opportunities for improvements for quality assessment tools. Finally, the reader is provided with a route map to detection techniques that can be used to mine MAPs.

Microservices fuel cloud-native systems with small service sets developed and deployed independently. The independent nature of this modular architecture also leads to challenges and gaps. The intended system design might deviate far from what is eventually produced and maintained as the architecture tends to degrade over time. This paper challenges the audience on how static analysis could contribute to microservice system development and management, particularly managing architectural degradation. It elaborates on challenges and needed changes in the traditional code analysis to better fit these systems and discusses implications for practitioners once robust static analysis tools become available

Internet of Things (IoT) is an emerging technology that has the promising power to change our future. Due to the market pressure, IoT systems may be released without sufficient testing. However, it is no longer acceptable to release IoT systems to the market without assuring the quality. As in the case of new technologies, the quality assurance process is a challenging task. This paper shows the results of the first comprehensive and systematic mapping study to structure and categories the research evidence in the literature starting in 2009 when the early publication of IoT papers for IoT quality assurance appeared. The conducted research is based on the most recent guidelines on how to perform systematic mapping studies. A set of research questions is defined carefully regarding the quality aspects of the IoT. Based on these questions, a large number of evidence and research papers is considered in the study (478 papers). We have extracted and analyzed different levels of information from those considered papers. Also, we have classified the topics addressed in those papers into categories based on the quality aspects. The study results carry out different areas that require more work and investigation in the context of IoT quality assurance. The results of the study can help in a further understanding of the research gaps. Moreover, the results show a roadmap for future research directions.

Contemporary development of the Internet of Things (IoT) technology brings a number of challenges in the Quality Assurance area. Current issues related to security, user's privacy, the reliability of the service, interoperability, and integration are discussed. All these create a demand for specific Quality Assurance methodology for the IoT solutions. In the paper, we present the state of the art of this domain and we discuss particular areas of system testing discipline, which is not covered by related work sufficiently so far. This analysis is supported by results of a recent survey we performed among ten IoT solutions providers, covering various areas of IoT applications., Comment: 10 pages Internet of Things (IoT)