Abstract
While a wide range of resources is available on orchestration techniques and best practices for containerized software systems, many are not documented clearly or in detail. This complicates the process of selecting the most suitable methods for various usage scenarios. To address this gap, we documented a set of orchestration patterns. This paper reports the results of a focus group conducted during the EuroPLoP 2024 conference, where we aimed to obtain feedback on that group of patterns and on a wider pattern map we outlined. We also aimed to identify container orchestration patterns that have not yet been documented. We found that participants knew most of the patterns we included on the pattern map. Additionally, one of the practices mentioned by the participants (Node Balancing) was previously documented as a pattern by us with the name of Service Balancing. Finally, we found important insights into container orchestration patterns, expanding our pattern map to include eight new proto-patterns.

Abstract
Logging has long been a pillar for monitoring and troubleshooting software systems. From server and infrastructure to application-specific data, logs are an easy and quick way to collect information that may prove useful in diagnosing future issues. When systems become distributed, as is common on the cloud, logs are harder to collect and process. This paper presents three design patterns for logging in cloud-native applications. Standard Logging advises using a standard format for logs across all services and teams so they are easier to process by humans and machines. Audit Logging suggests that important user actions and system changes are recorded in a data store to ensure regulatory compliance or help investigate user-reported issues. Lastly, Log Sampling is about prioritizing logs to maintain a manageable amount of storage. These patterns were mined from existing literature on logging and cloud best practices to make them simpler to communicate, more detailed, and easier for all practitioners to understand.

Abstract
Although service-based architectures offer significant advantages, some aspects of service orchestration remain challenging, particularly for new adopters. Despite the availability of resources on orchestration techniques, many lack clarity or detail. As a result, best practices are often not well explained or standardized, making them difficult to implement and hindering broader adoption within the software industry. To address these concerns, we looked into existing literature and tools to identify common practices. We used our findings to describe as patterns two patterns focused on orchestration configuration, which we present in this paper, and that serve as a stepping stone for other orchestration practices: labeling and resource reserve and limit. These patterns contribute to configuring a system; the former consists of defining key-value pairs to express identifiable properties of system components, and the latter is about supporting two bounds for each resource type: the amount of resources reserved for the service to operate and the maximum amount of resources it can use.

Abstract
Over the years, sensitive data has been growing in software systems. To comply with ethical and legal requirements, the General Data Protection Regulation (GDPR) recommends using pseudonymization and anonymization techniques to ensure appropriate protection and privacy of personal data. Many anonymization techniques have been described in the literature, such as generalization or suppression, but deciding which methods to use in different contexts is not a straightforward task. Furthermore, anonymization poses two major challenges: choosing adequate techniques for a given context and achieving an optimal level of privacy while maintaining the utility of the data for the context within which it is meant to be used. To address these challenges, this paper describes four new design patterns: Generalization, Hierarchical Generalization, Suppress Outliers, and Relocate Outliers, building on existing literature to offer solutions for common anonymization challenges, including avoiding linkage attacks and managing the privacy-utility trade-off. © 2024 Copyright held by the owner/author(s).

Abstract

Abstract