Cloud-native software-delivery pipelines increasingly rely on Policy-as-Code (PaC) to automate security, compliance, and governance enforcement. Although Policy-as-Code is widely adopted within Continuous Integration (CI) pipelines and Kubernetes admission-control frameworks, governance requirements are often implemented independently, potentially increasing maintenance effort and creating opportunities for policy drift. Despite the growing adoption of Policy-as-Code, comparatively little empirical evidence exists regarding the reuse of a shared policy-definition layer across complementary enforcement stages within the software-delivery lifecycle. This paper presents and empirically evaluates a reusable multi-stage Policy-as-Code enforcement model based on a shared policy-definition layer implemented using the Open Policy Agent (OPA) framework and its Rego policy language. Rather than proposing a new Policy-as-Code technology, the study investigates whether a shared policy-definition layer can support consistent policy enforcement across Continuous Integration validation and Kubernetes admission control. The model was evaluated using Conftest and OPA Gatekeeper through a structured experimental study comprising 29 Kubernetes manifests, 37 experimental scenarios, eight Kubernetes resource types, and 261 policy assertions covering representative cloud-native workload-governance requirements. Within the evaluated dataset, all intentionally introduced insecure configurations were correctly identified without observed false positives or false negatives. The shared policy-definition layer was successfully reused across both validation stages, while Kubernetes admission control mitigated all evaluated CI bypass scenarios by providing an independent deployment-time enforcement boundary. The results demonstrate that a shared policy-definition layer can support consistent policy enforcement across complementary enforcement stages while enabling policy reuse without requiring duplicate policy implementations within the evaluated environment. More broadly, the study contributes empirical evidence supporting policy reuse as a governance strategy for cloud-native software delivery and provides a reproducible foundation for future investigations involving larger datasets, broader governance-policy portfolios, alternative Policy-as-Code ecosystems, and production-scale deployments.
L. Nogueira, Alice Resende· Computers· 0 citations
Fault tolerance is a fundamental requirement of distributed systems, and actor-based runtimes provide a widely adopted approach for building resilient and highly concurrent applications. Although several actor ecosystems offer mechanisms for supervision, failure detection, and recovery, comparative studies frequently focus on performance metrics rather than fault-tolerance behaviour. This paper presents a language-independent benchmarking framework for evaluating fault tolerance in actor-based runtimes. The framework was implemented using three representative ecosystems: Elixir/BEAM, Scala/Akka, and Go/Proto.Actor. A distributed chat-based benchmark application was used to measure throughput, reconnection latency, and failure-detection latency under recurring transient failures. All implementations followed an equivalent architecture and were executed under identical experimental conditions. The study deliberately targets a single, well-defined fault model: the supervised crash recovery of in-memory, effectively stateless actor services, in which chat actors are abruptly terminated and restarted by their supervisors while clients rediscover and reconnect to them. Stateful recovery (actor state, mailbox contents, in-flight or persistent messages), as well as multi-node network effects, are explicitly out of scope. Accordingly, the benchmark characterises supervised crash–recovery behaviour for largely stateless actor services rather than providing a comprehensive evaluation of actor-based fault tolerance. The results reveal distinct trade-offs among the evaluated ecosystems. Elixir achieved the highest throughput and the lowest throughput variability under fault conditions, while Scala/Akka consistently provided the lowest reconnection and failure-detection latencies, particularly at large scale. Go/Proto.Actor remained competitive in throughput-oriented scenarios but showed greater degradation in recovery-related metrics as concurrency increased. The results indicate that no single runtime dominates all evaluated dimensions of recovery behaviour. Beyond the runtime comparison, this work contributes a reproducible benchmarking framework that provides a foundation for future empirical studies of actor-based runtime recovery under controlled fault conditions.