Abstract
Service-based architecture is an approach that emerged to overcome software development challenges such as difficulty to scale, low productivity, and strong dependence between elements. Microservice, an architectural style that follows this approach, offers advantages such as scalability, agility, resilience, and reuse. This architectural style has been well accepted and used in industry and has been the target of several academic studies. However, analyzing the state-of-the-art and -practice, we can notice a fuzzy limit when trying to classify and characterize the architecture of service-based systems. Furthermore, it is possible to realize that it is difficult to analyze the trade-offs to make decisions regarding the design and evolution of this kind of system. Some concrete examples of these decisions are related to how big the services should be, how they communicate, and how the data should be divided/shared. Based on this context, we developed the CharM, a model for characterizing the architecture of service-based systems that adopts microservices guidelines. To achieve this goal, we followed the guidelines of the Design Science Research in five iterations, composed of an ad-hoc literature review, discussions with experts, two case studies, and a survey. As a contribution, the CharM is an easily understandable model that helps professionals with different profiles to understand, document, and maintain the architecture of service-based systems.& COPY; 2023 Elsevier Inc. All rights reserved.

Abstract

Abstract

Abstract
Monitoring a system over time is as important as ever with the increasing use of cloud-native software architectures. This paper expands the set of patterns published in a previous paper (Liveness Endpoint, Readiness Endpoint and Synthetic Testing) with two solutions for supporting teams in diagnosing occurring issues — Deployment Tracking and Exception Tracking. These patterns advise tracking relevant events that occur in the system. The Deployment Tracking pattern provides means to limit the sources of an anomaly, and the Exception Tracking pattern makes a specific class of anomalies visible so that a team can act on them. Both patterns help practitioners identify the root cause of an issue, which is instrumental in fixing it. They can help even less experienced professionals to improve monitoring processes, and reduce the mean time to resolve problems with their application. These patterns draw on documented industry best practices and existing tools. In order to help the reader find other patterns that supplement the ones suggested in this study, relations to already-existing monitoring patterns are also examined. © 2023 Copyright held by the owner/author(s).

Abstract
This work takes as a starting point a collection of patterns for engineering software for the cloud and tries to find how they are regarded and adopted by professionals. Existing literature assesses the adoption of cloud computing with a focus on business and technological aspects and falls short in grasping a holistic view of the underlying approaches. Other authors delve into how independent patterns can be discovered (mined) and verified, but do not provide insights on their adoption. We investigate (1) the relevance of the patterns for professional software developers, (2) the extent to which product and company characteristics influence their adoption, and (3) how adopting some patterns might correlate with the likelihood of adopting others. For this purpose, we survey practitioners using an online questionnaire (n = 102). Among other findings, we conclude that most companies use these patterns, with the overwhelming majority (97 percent) using at least one. We observe that the mean pattern adoption tends to increase as companies mature, namely when varying the product operation complexity, active monthly users, and company size. Finally, we search for correlations in the adoption of specific patterns and attempt to infer causation, providing further clues on how some practices depend or influence the adoption of others. We conclude that the adoption of some practices correlates with specific company and product characteristics, and find relationships between the patterns that were not covered by the original pattern language and which might deserve further investigation.