Fast and Efficient What-If Analyses of Invocation Overhead and Transactional Boundaries to Support the Migration to Microservices

TL;DR

The paper addresses the challenge of selecting service boundaries during migration to microservices while preserving non-functional properties like performance and data consistency. It introduces a trace rewriting-based what-if analysis that rewrites production traces to reflect alternative deployment models and analyzes overhead and transaction boundaries, prioritizing usability and speed over precision. The industrial case study motivates the method and a proof-of-concept demonstrates fast analysis and positive practitioner feedback. The work offers a practical toolchain to guide iterative boundary design and highlights directions for applying to real applications and extending monitoring and visualization.

Abstract

Improving agility and maintainability are common drivers for companies to adopt a microservice architecture for their existing software systems. However, the existing software often relies heavily on the fact that it is executed within a single process space. Therefore, decomposing existing software into out-of-process components like microservices can have a severe impact on non-functional properties, such as overall performance due to invocation overhead or data consistency. To minimize this impact, it is important to consider non-functional properties already as part of the design process of the service boundaries. A useful method for such considerations are what-if analyses, which allow to explore different scenarios and to develop the service boundaries in an iterative and incremental way. Experience from an industrial case study suggests that for these analyses, ease of use and speed tend to be more important than precision. In this paper, we present emerging results for an approach for what-if analyses based on trace rewriting that is (i) specifically designed for analyzing the impact on non-functional properties due to decomposition into out-of-process components and (ii) deliberately prefers ease of use and analysis speed over precision of the results.

Figures (2)

• Figure 1: Overview of our Approach. The circled numbers indicate the steps in which the respective element is used.
• Figure 2: Example Trace Visualization. The blue bars represent the spans, and the small shapes within the bars represent different types of events: Rectangles represent transaction events (in the example, start (white) and commit (green) of a transaction), circles represent accesses to entities, and diamonds represent consistency issues of different types. For instance, the yellow diamond represents a read of an entity with pending changes in another transaction, which may indicate an expectation of read-your-writes consistency. Invocation overhead is depicted as the "whiskers" before and after the respective span. The colored bars in the background represent the transaction state at the corresponding point in time: A green bar denotes that a transaction is active and has no pending writes, whereas a red bar indicates an active transaction with pending writes. The time during which a transaction is suspended is represented by a gray bar.