Supporting Architectural Decision Making on Data Management in Microservice Architectures

Abstract

Today many service-based systems follow the microservice architecture style. As microservices are used to build distributed systems and promote architecture properties such as independent service development, polyglot technology stacks including polyglot persistence, and loosely coupled dependencies, architecting data management is crucial in most microservice architectures. Many patterns and practices for microservice data management architectures have been proposed, but are today mainly informally discussed in the so-called "grey literature": practitioner blogs, experience reports, and system documentations. As a result, the architectural knowledge is scattered across many knowledge sources that are usually based on personal experiences, inconsistent, and, when studied on their own, incomplete. In this paper we report on a qualitative, in-depth study of 35 practitioner descriptions of best practices and patterns on microservice data management architectures. Following a model-based qualitative research method, we derived a formal architecture decision model containing 325 elements and relations. Comparing the completeness of our model with an existing pattern catalog, we conclude that our architectural decision model substantially reduces the effort needed to sufficiently understand microservice data management decisions, as well as the uncertainty in the design process.

Decision Models for Selecting Patterns and Strategies in Microservices Systems and their Evaluation by Practitioners

“…During microservices system development, decision models [5,7] and practitioners' feedback [8,17] provide a set of guidelines (e.g., architectural models, patterns, recommended practices) that can empower the practitioners (e.g., architects) to rely on reusable knowledge and best practices to design, develop, validate, and evolve microservices systems [14]. Decision guidance models for microservices systems: Decision guidance models represent concentrated knowledge and rationalization about design decisions, such as modelling notations, patterns, and reference architectures to architect and develop microservices systems [8].…”

“…Practitioners' perspectives and recommendations for architecting microservices systems: In contrast to decision models, practitioners' perspectives (i.e., developers' feedback) can streamline the industrial practices and experts' recommendations for the design and development of microservices systems. Ntentos et al [17] present best practices and patterns for microservice systems. Based on identified practices and patterns, the authors have derived a formal architecture decision model containing 325 elements and relations.…”

“…Existing research on pattern-based architecting of microservices systems [7] exploits decision models but lacks strategies associated with patterns and their impacts on quality attributes (i.e., architecturally significant requirements). In contrast to survey-based studies on finding suitability and application of decision models [17], our work first derives four decision models that can leverage a multitude of patterns and strategies addressing various MSA design areas, and then validates these decision models based on practitioners' feedback.…”

Evaluating and Improving Microservice Architecture Conformance to Architectural Design Decisions

“…In this section, we briefly introduce the three ADDs and the corresponding patterns and practices as decision options, based on our prior work. The decisions have been modeled based on an empirical study of existing best practices and patterns by practitioners [10], while the metrics used to assess the pattern conformance of each given system derive from [9].…”

Avoiding Excessive Data Exposure Through Microservice APIs

“…Since data autonomy and isolation are key characteristics of a microservice architecture [10], exchanging data between services is essential and avoiding data transfer at all is not an option for obvious reasons. Dias and Siriwardena [5] refer to data transfer that goes beyond what is strictly necessary, as excessive data exposure and further suggest that each API should only provide precisely that part of the information required by its consumers.…”