Abstract
Incorporating linked data-based models into the process of describing cultural objects is increasingly important for cultural heritage. Communities such as libraries, archives, and museums have developed and adopted models specific to their contexts. Without a trivial solution, choosing models to support more general applications is challenging. This Ph.D. aims to analyze existing solutions and practices in these domains and propose validated solutions for the discovery, access, interoperability, and reuse of cultural objects, following the FAIR principles. Transversal to the base models used, this research intends to adopt solutions that balance the simplicity of the models with the satisfaction of the requirements.

Abstract
This package provides all published resources used and produced in the context of the research study leading to the article "Designing Microservice Systems Using Patterns: An Empirical Study on Quality Trade-Offs", presented in ICSA 2022's technical track. It includes materials used to conduct the study as well as aggregated and anonymized data produced in its context. Making this package available intends to foster transparency and to support researchers attempting to replicate the study. The package complies with the Research Object Reviewed (ROR) and Open Research Object (ORO) badges, awarded by the Artifact Evaluation Track at ICSA 2022, and is available under Creative Commons Attribution 4.0 International. The package is openly available in Zenodo [1] and the article is available in ICSA 2022's proceedings [2] and as a pre-print [3]. © 2022 IEEE.

Abstract
The promise of increased agility, autonomy, scalability, and reusability has made the microservices architecture a de facto standard for the development of large-scale and cloud-native commercial applications. Software patterns are an important design tool, and often they are selected and combined with the goal of obtaining a set of desired quality attributes. However, from a research standpoint, many patterns have not been widely validated against industry practice, making them not much more than interesting theories. To address this, we investigated how practitioners perceive the impact of 14 patterns on 7 quality attributes. Hence, we conducted 9 semi-structured interviews to collect industry expertise regarding (1) knowledge and adoption of software patterns, (2) the perceived architectural trade-offs of patterns, and (3) metrics professionals use to measure quality attributes. We found that many of the trade-offs reported in our study matched the documentation of each respective pattern, and identified several gains and pains which have not yet been reported, leading to novel insight about microservice patterns.

Abstract
Container orchestration tools supporting infrastructure-as-code allow new forms of collaboration between developers and operatives. Still, their text-based nature permits naive mistakes and is more difficult to read as complexity increases. We can find few examples of low-code approaches for defining the orchestration of containers, and there seems to be a lack of empirical studies showing the benefits and limitations of such approaches. We hypothesize that a complete visual notation for Docker-based orchestrations could reduce the effort, the error rate, and the development time. Therefore, we developed a tool featuring such a visual notation for Docker Compose configurations, and we empirically evaluated it in a controlled experiment with novice developers. The results show a significant reduction in development time and error-proneness when defining Docker Compose files, supporting our hypothesis. The participants also thought the prototype easier to use and useful, and wanted to use it in the future.

Abstract
The quality of the digital experiences delivered by engineers and their business success depends on empowering developers and operators with an effective method for continuously assessing a system's health, diagnosing possible issues, and recovering from service outages. In other words, monitoring is essential to ensure the quality of an application. However, monitoring best practices may not be apparent to everyone and, most of the time, are not sufficiently explained or documented to be learned quickly and communicated effectively. Therefore, practices usually lack formalisation and a standard structure that would make all of them easy to communicate and share among practitioners. To tackle this issue, this paper describes three proactive monitoring practices as design patterns: Liveness Endpoint, Readiness Endpoint and Synthetic Testing. Design patterns provide enough structure and detail to be easily reused by practitioners and have space to accommodate different needs and quirks depending on the usage context. The proposed patterns are based on existing literature and tools, stemming from industry best practices that are further detailed and adapted to design patterns. Relations to existing monitoring patterns are also analysed to point the reader to more patterns that complement the ones proposed in this work. © 2022 Owner/Author.

Abstract
As the benefits and applicability of microservice architectures become better understood by the software industry, and this architecture becomes increasingly more adopted for building stable, independent and scalable cloud applications, a new set of concerns have alerted developers regarding communication between the different microservices. A service mesh tries to address this issue by creating a clear separation of concerns between application logic and the infrastructure needed for the communication between the different services. This is accomplished by abstracting the cross-cutting concerns related with communication out of the internal services making it possible to be reused by the different services. Existing literature describes a service mesh pattern and a sidecar pattern. This paper leans on these patterns and proposes six patterns found by observing the, what is commonly called, good practices. The six patterns are service mesh, shared communication library, node agent, sidecar, service mesh team and control plane per cluster. © 2022 Owner/Author.