Pith. sign in

REVIEW 4 major objections 5 minor 56 references

Resilience Evaluation of Kubernetes in Cloud-Edge Environments via Failure Injection

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper argues that cloud-edge Kubernetes deployments are the more stable choice when network delay or partition faults dominate, while pure cloud deployments are more resilient under bandwidth throttling and network loss, and it backs…

desk verdict Useful engineering, unsupported headline numbers: the 80%/47% claims need a derivation and a fairer baseline before the main finding can be trusted. read the letter →

arxiv 2507.16109 v1 pith:7WFQZTJW submitted 2025-07-21 cs.DC

Zihao Chen , Mohammad Goudarzi , Adel Nadjaran Toosi This is my paper · ORCID
classification cs.DC
keywords Kubernetescloud-edgecomputingresilienceevaluationfaultinjectionchaosengineeringmicroservicesz-scorenormalizationperformanceanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to turn deployment advice for Kubernetes in cloud-edge settings from folklore into measurement: it builds an orchestration framework that injects pod, node, and network faults under realistic load, and runs it across cloud-only and cloud-edge clusters running both a monolithic and a microservices application. The central empirical claim is that the better deployment depends on the dominant failure mode. Under injected network delay and partition faults, cloud-edge deployments keep response times far more stable, reported as 80% superior response stability; under bandwidth throttling and network loss, cloud deployments show 47% better resilience. If true, this gives operators a quantitative rule: prefer the edge when latency disruptions dominate, prefer the cloud when throughput constraints dominate. The paper also releases what it calls the first comprehensive resilience dataset for hybrid cloud-edge Kubernetes, spanning 11,965 fault-injection scenarios.

What carries the argument

The load-bearing mechanism is the measurement and normalization pipeline, not any single fault. The framework orchestrates fault injection through Chaos Mesh custom resources, workload generation through Locust, health checks, and recovery through a five-phase workflow, then compares deployments using dual metrics: absolute average response time and a z-score of response time, $z = (x-\mu)/\sigma$, where the baseline mean $\mu$ and standard deviation $\sigma$ are taken from measurements at 25% fault intensity. The z-score is what converts raw latency numbers into a claimed stability advantage, and the paper's resilience conclusions rest on the variance of these normalized distributions across cloud versus cloud-edge deployments.

What would settle it

Re-run the z-score normalization with an undisturbed cluster (no injected fault) as the baseline instead of the 25% intensity measurements. If the reported 80% stability advantage for cloud-edge under delay and partition, or the 47% cloud advantage under bandwidth, shrinks below statistical significance or reverses sign, the central claim is an artifact of the normalization baseline. A complementary check is to repeat the network-loss experiments while logging successful and failed requests separately, since the paper notes survivorship bias at 100% loss.

Watch

Extended reading notes

Core claim

The authors claim to have found a resilience inversion between cloud and cloud-edge Kubernetes deployments that absolute response-time averages hide. Measured with z-score normalization, edge deployments remain within about 1 standard deviation of their baseline under network delay and partition faults while cloud deployments stretch to 3-6 standard deviations, which they report as 80% superior response stability for latency-sensitive faults. Under bandwidth limitation and partial network loss, the pattern reverses: cloud z-scores stay near 0-0.6 standard deviations while edge medians exceed 1 standard deviation, a 47% resilience advantage for the cloud under throughput-constrained faults. The paper argues this inversion follows from architecture: edge services use shorter local paths and local caches, so delay and partition hit them less, while cloud networks have higher aggregate bandwidth and redundant paths, so throughput throttling hurts them less.

Load-bearing premise

The headline percentages assume that the 25% fault-intensity measurements used to set the z-score baseline represent normal operation; if that perturbed baseline is not a fair reference, the reported stability advantages could be artifacts of normalization rather than intrinsic deployment properties.

Editorial extensions

If this is right

  • Under network delay or partition fault regimes, operators should prefer cloud-edge placement when predictable response times matter more than peak speed.
  • Under bandwidth throttling or partial network loss, cloud deployment should be preferred when stable throughput is the priority.
  • Microservices pay for modularity with higher tail latency and failure rates; the dataset quantifies this gap and suggests longer client timeouts for microservices.
  • Scaling the cluster from 4 to 8 nodes reduces mean and P95 response times and lowers experiment failure rates in both deployment modes.
  • The public dataset can serve as a baseline for future Kubernetes resilience studies without rerunning 11,965 fault-injection scenarios.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the baseline used for z-score normalization is itself a perturbed state (25% fault intensity), the 80% and 47% figures should be read as relative stability under already-degraded conditions, not as absolute resilience margins; a reader comparing SLOs should re-derive the comparison with a clean baseline.
  • The same dual-metric methodology could be applied to service meshes or multi-cloud topologies to see whether the resilience inversion is specific to Kubernetes or a general property of distributed placement.
  • The simulated edge conditions (200 ms latency, 10% loss) may understate real edge heterogeneity; testing on physical edge devices could reveal whether the patterns hold when compute and storage constraints interact with network faults.
  • Separating failed requests from successful ones in the 100% network-loss regime would remove the survivorship bias noted in the paper and yield a cleaner resilience metric.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. This paper presents a framework for automated fault injection and load testing of Kubernetes clusters in pure-cloud and cloud-edge configurations. The framework orchestrates Chaos Mesh fault injection with Locust workloads and is used to run 11,965 experiments across two cluster sizes, monolithic and microservices applications, and several fault types at four intensity levels, collecting response-time and error data. Based on z-score normalized response times, the authors report that under network delay and partition faults the cloud-edge deployment shows greater response stability, while under bandwidth limitation and network loss the cloud deployment is more stable. The paper claims quantitative results: 80% superior response stability for cloud-edge and 47% better resilience for cloud under bandwidth limits, and it positions a dataset of roughly 30 GB and 57 million requests as a first-of-its-kind contribution. The framework code is said to be publicly available on GitHub, while the dataset is currently in a private repository.

Significance. If the quantitative results were properly derived, this would be a useful empirical benchmark for deployment decisions in cloud-edge Kubernetes. The main strengths are the scale of the fault-injection study (nearly 12,000 scenarios), the direct comparison of monolithic versus microservices architectures under identical faults, the open-source framework code, and the use of both absolute and normalized metrics. However, the paper's central numerical claims are not substantiated in the results section, and the chosen normalization baseline is questionable; these issues must be resolved before the findings can be accepted as quantitative guidance.

major comments (4)
  1. [Abstract; §4.4; §5] The central quantitative claims—80% superior response stability under network delay/partition and 47% better resilience under bandwidth limitations—appear only in the Abstract and the Conclusion. The results section presents qualitative statements (e.g., Table VII's 'preferred deployment' column) and z-score ranges (e.g., §4.4.4: cloud medians reaching 3.0σ and whiskers extending to 6σ, edge within ±1σ), but no formula or calculation shows how the 80% and 47% figures are derived. Please provide the exact computation for both percentages (metric, aggregation, baseline, and fault intensities used), or remove the percentages from the Abstract and Conclusion if they cannot be substantiated.
  2. [§4.4.1, Eq. (1)] The z-score baseline is not a no-fault baseline. The text states that 'Baselines are established using 25% fault intensity measurements,' so z=0 refers to a cluster already under a nonzero fault load. Because the edge environment is configured with 200 ms base latency, ±10% jitter, and 10% packet loss (§4.1, Table III), its response-time variance at 25% fault intensity is plausibly larger than the cloud's. Normalizing by this noisier edge baseline compresses edge z-scores, so the reported contrast (edge always within ±1σ while cloud reaches 3–6σ) could arise from the baseline choice rather than from intrinsic deployment resilience. Please use measurements from an undisturbed cluster as μ and σ, or present the analysis in absolute terms (e.g., raw response-time increase) alongside the normalized values.
  3. [§4.4.3–§4.4.5] The resilience comparisons are based on qualitative descriptions of z-score distributions (e.g., 'peak z-scores reaching 1.5σ versus cloud's 0.5σ' in §4.4.3), but no sample sizes, confidence intervals, or significance tests are reported. The term 'z-variance' in Table VII is never defined, and the figures do not show error bars. Without this information, the reader cannot determine whether the reported cloud-versus-edge differences are distinguishable from run-to-run noise, particularly since the results aggregate across applications, cluster sizes, thread counts, and timeout settings. Please add per-condition summary statistics and a statistical test or effect-size measure.
  4. [§2.3, Table I, §3.1] The claimed framework capabilities exceed what is implemented and evaluated. Table I marks 'Our Work' as supporting control-plane fault injection, and §2.3 says the framework 'uniquely combines control-plane fault injection with integrated workload generation'; however, §3.1's Injection Controller describes only Chaos Mesh integration, with 'extensibility provisions' for other tools, and no control-plane fault experiment (e.g., etcd or API-server disruption) appears in §4. The Abstract similarly lists Gremlin and ChaosBlade as combined platforms, while §4.2 states 'Our fault injection leverages Chaos Mesh.' These claims should be brought in line with the actual implementation, or supplemented by experiments using the advertised tools.
minor comments (5)
  1. [§4.3, Table VI] The four experiment counts in Table VI sum to 11,964, not 11,965 as stated throughout the paper; please reconcile this discrepancy.
  2. [Author Contributions] The Author Contributions section says 'The author independently conducted all aspects of this study,' but the title lists three authors; please clarify the contribution statement for all authors.
  3. [Table VI, footnote] The footnote defines failure rate as 'number of failed experiments ÷ total experiment' (with what appears to be a missing word 'count'), which measures the proportion of experiments that failed rather than a request-level failure rate; please clarify the definition and keep it consistent with the dataset description in §4.3.
  4. [§4.3, Appendix B] The dataset is described as a key contribution, but §4.3 states that it is hosted in a private repository and Appendix B says it is not included and must be requested by email; please provide a concrete data-availability plan, such as an anonymous access link or an archival repository, for review and eventual publication.
  5. [Figures 5–7] The z-score distribution plots would be easier to interpret with sample sizes and clear per-intensity labels; currently the reader cannot infer how many experiments underlie each distribution.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the resilience claims are empirical measurements from fault-injection experiments, not derivations from their own inputs.

full rationale

The paper is an empirical fault-injection study, not a formal derivation. The central claims about cloud-edge versus cloud resilience are presented as measured outcomes of 11,965 fault-injection experiments on two Kubernetes clusters (Sections 4.1-4.4). The z-score normalization in Eq. (1) is a data-processing choice for cross-environment comparison; it does not define the conclusion. The baseline mean and standard deviation are taken from 25% fault-intensity measurements (Section 4.4.1), which is a reference-point choice that may affect interpretability, but it does not make the later comparisons equivalent to the input by construction: the z-scores at other intensities are empirical observations, not fitted values. The 80% and 47% figures appear only in the abstract and conclusion and are not derived in the results section (Sections 4.4-4.5); this is an internal-consistency/reproducibility weakness, not circularity. Self-citations (e.g., refs. [14], [16], [20], [21], [24], [26]) appear only in background and related-work contexts and are not load-bearing for the experiment or its conclusions. The paper explicitly acknowledges generalizability limitations (Section 5: 'Several limitations constrain our findings' generalizability, including controlled virtualized environments...'), which is a validity caveat, not a circular step. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no known result is merely renamed. The empirical measurements are grounded in external tools (Chaos Mesh, Locust), external benchmark applications (Sock Shop, Image Detection), and public infrastructure, so the derivation chain is self-contained.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claims rest on experimental setup choices rather than mathematical derivations. The most consequential choice is the z-score baseline at 25% fault intensity, the simulated edge parameters, and the assumption that injected faults and synthetic load represent production conditions. No new entities are postulated.

free parameters (3)
  • z-score baseline fault intensity = 25%
    Section 4.4.1 sets the baseline mean and standard deviation for normalization from measurements at 25% fault intensity rather than an undisturbed cluster, which directly affects the stability comparison.
  • edge network impairment parameters = 200 ms latency +/- 10%, 10% packet loss
    Section 4.1.1 selects these values to simulate edge conditions based on claimed real-world measurements, but no source is cited, and they define what counts as a cloud-edge environment.
  • fault intensity to latency mapping = 25% to 100 ms, 100% to 1000 ms
    Section 4.2.1 maps fault intensity percentages to concrete network delay values by hand, affecting the shape of the response curves.
assumptions (4)
  • domain assumption Chaos Mesh fault injection produces failures equivalent to real production incidents
    The entire study assumes injected container kills, network delays, and bandwidth throttling faithfully represent real failure modes; the paper does not validate this against production incidents.
  • domain assumption Locust-generated HTTP traffic represents realistic production workloads
    The load generation system is used as a proxy for real user traffic, but no validation against production workload traces is presented.
  • domain assumption Virtual machines with simulated network impairments adequately represent edge nodes
    Section 4.1.1 uses VMs with 200 ms latency and 10% loss to emulate edges; the authors acknowledge in Section 5 that this limits generalizability.
  • ad hoc to paper The 25% fault intensity condition is a statistically valid baseline
    Section 4.4.1 defines the normalization baseline using perturbed measurements, a choice specific to this paper that directly shapes the headline stability results.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Resilience Evaluation of Kubernetes in Cloud-Edge Environments via Failure Injection." pith.science (2026). https://pith.science/paper/7WFQZTJW

@misc{pith2026250716109,
  author       = {Pith},
  title        = {Pith review of: Resilience Evaluation of Kubernetes in Cloud-Edge Environments via Failure Injection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7WFQZTJW}},
  note         = {Machine review of arXiv:2507.16109}
}
read the original abstract

Kubernetes has emerged as an essential platform for deploying containerised applications across cloud and edge infrastructures. As Kubernetes gains increasing adoption for mission-critical microservices, evaluating system resilience under realistic fault conditions becomes crucial. However, systematic resilience assessments of Kubernetes in hybrid cloud-edge environments are currently limited in research. To address this gap, a novel resilience evaluation framework integrates mainstream fault injection tools with automated workload generation for comprehensive cloud-edge Kubernetes testing. Multiple fault injection platforms, including Chaos Mesh, Gremlin, and ChaosBlade are combined with realistic traffic simulation tools, enabling automated orchestration of complex failure scenarios. Through this framework, comprehensive experiments are conducted that systematically target node-level, pod-level, and network failures across cloud and cloud-edge environments. The first comprehensive resilience dataset for hybrid cloud-edge Kubernetes deployments is created, comprising over 30 GB of performance data from 11,965 fault injection scenarios including response times, failure rates, and error patterns. Analysis reveals that cloud-edge deployments demonstrate 80% superior response stability under network delay and partition conditions, while cloud deployments exhibit 47% better resilience under bandwidth limitations, providing quantitative guidance for architectural decision-making in cloud-edge deployments.

Figures

Figures reproduced from arXiv: 2507.16109 by the authors.

Figure 1
Figure 1. Layered architecture of the proposed resilience evaluation framework, including the orchestrator, experiment controllers, [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Internal design of core framework components (UML class diagram). [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. UML sequence diagram of the framework’s five-phase cloud-edge Kubernetes resilience experiment, illustrating the [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: , this application typifies modern cloud-native designs with distributed, loosely-coupled services. While offering scalability and fault isolation, it introduces complex inter-service dependencies and risks of cascading failures [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Resilience Metrics under Network Bandwidth Limitation [PITH_FULL_IMAGE:figures/full_fig_p012_5.png]
Figure 6
Figure 6. Figure 6: Resilience Metrics under Network Delay and Partition Faults [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Resilience Metrics under Network Loss Faults [PITH_FULL_IMAGE:figures/full_fig_p014_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

56 extracted references · 45 canonical work pages

  1. [1]

    Network-aware container placement in cloud-edge kubernetes clusters,

    A. Marchese and O. Tomarchio, “Network-aware container placement in cloud-edge kubernetes clusters,” in 2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid) , 2022, pp. 859–865

    work page 2022

  2. [2]

    Load-balancing of kubernetes- based edge computing infrastructure using resource adaptive proxy,

    Q.-M. Nguyen, L.-A. Phan, and T. Kim, “Load-balancing of kubernetes- based edge computing infrastructure using resource adaptive proxy,” Sensors, vol. 22, no. 8, p. 2869, Apr 2022

    work page 2022

  3. [3]

    Cncf annual survey 2021,

    Cloud Native Computing Foundation (CNCF), “Cncf annual survey 2021,” https://www.cncf.io/reports/cncf-annual-survey-2021/, 2022, ac- cessed: 2024-05-04

    work page 2021

  4. [4]

    Deep reinforcement learning- based scheduling for optimizing system load in fog computing,

    W. Zhang, M. Li, and L. Chen, “Deep reinforcement learning- based scheduling for optimizing system load in fog computing,” Future Generation Computer Systems , vol. 150, pp. 1–14, 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S0167739X23003862

    work page 2023

  5. [6]

    Boosting microservice re- silience: An evaluation of istio’s impact on kubernetes clusters under chaos,

    S. Singh, C. H. Muntean, and S. Gupta, “Boosting microservice re- silience: An evaluation of istio’s impact on kubernetes clusters under chaos,” in 2024 9th International Conference on Fog and Mobile Edge Computing (FMEC), 2024, pp. 245–252

    work page 2024

  6. [7]

    Impacttracer: Root cause local- ization in microservices based on fault propagation modeling,

    R. Xie, J. Yang, J. Li, and L. Wang, “Impacttracer: Root cause local- ization in microservices based on fault propagation modeling,” in 2023 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2023, pp. 1–6

    work page 2023

  7. [8]

    Mutiny! how does kubernetes fail, and what can we do about it?

    M. Barletta, M. Cinque, C. Di Martino, Z. T. Kalbarczyk, and R. K. Iyer, “Mutiny! how does kubernetes fail, and what can we do about it?” in 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) , 2024, pp. 1–14

    work page 2024

  8. [9]

    Reliability evaluation of microservices and monolithic architectures,

    A. B. Raharjo, P. K. Andyartha, W. H. Wijaya, Y . Purwananto, D. Pur- witasari, and N. Juniarta, “Reliability evaluation of microservices and monolithic architectures,” in 2022 International Conference on Com- puter Engineering, Network, and Intelligent Multimedia (CENIM), 2022, pp. 1–7

    work page 2022

Show all 56 references
  1. [10]

    The role of microservice approach in edge computing: Opportunities, challenges, and research directions,

    M. D. Hossain, T. Sultana, S. Akhter, M. I. Hossain, N. T. Thu, L. N. Huynh, G.-W. Lee, and E.-N. Huh, “The role of microservice approach in edge computing: Opportunities, challenges, and research directions,” ICT Express, vol. 9, no. 6, pp. 1162–1182, 2023

    2023

  2. [11]

    The emergence of edge computing,

    M. Satyanarayanan, “The emergence of edge computing,” Computer, vol. 50, no. 1, pp. 30–39, 2017

    2017

  3. [12]

    An overview on edge computing research,

    K. Cao, Y . Liu, G. Meng, and Q. Sun, “An overview on edge computing research,” IEEE Access, vol. 8, pp. 85 714–85 728, 2020

    2020

  4. [13]

    Edge computing: Vision and challenges,

    W. Shi, J. Cao, Q. Zhang, Y . Li, and L. Xu, “Edge computing: Vision and challenges,” IEEE Internet of Things Journal , vol. 3, no. 5, pp. 637–646, 2016

    2016

  5. [14]

    FLight: A lightweight federated learning framework in edge and fog computing,

    W. Zhu, M. Goudarzi, and R. Buyya, “FLight: A lightweight federated learning framework in edge and fog computing,” arXiv preprint , vol. cs.DC, no. arXiv:2308.02834, Aug. 2023, version 1, submitted 5 Aug 2023. [Online]. Available: https://arxiv.org/abs/2308.02834

    2023 arXiv

  6. [15]

    Resource management in mobile edge computing: A comprehensive survey,

    X. Zhang and S. Debroy, “Resource management in mobile edge computing: A comprehensive survey,” vol. 55, no. 13s, jul 2023. [Online]. Available: https://doi.org/10.1145/3589639

    2023 doi

  7. [16]

    An empirical study on edge-to-cloud continuum for smart applications: Performance, design patterns, and key factors,

    N. Chen, A. N. Toosi, B. Javadi, D. Alqahtani, M. S. Aslanpour, and M. Xu, “An empirical study on edge-to-cloud continuum for smart applications: Performance, design patterns, and key factors,” in 2024 IEEE International Conference on Edge Computing and Communica- tions (EDGE)...

    2024

  8. [17]

    Kubernetes scheduling: Taxonomy, ongoing issues and challenges,

    C. Carri ´on, “Kubernetes scheduling: Taxonomy, ongoing issues and challenges,” ACM Comput. Surv. , vol. 55, no. 7, dec 2022. [Online]. Available: https://doi.org/10.1145/3539606

    2022 doi

  9. [18]

    Csfrl: A reinforcement learning technology enabled computing power scheduling framework based on kubernetes,

    W. Cheng, Y . Xu, Q. Xu, H. Zhang, X. Li, and X. Shao, “Csfrl: A reinforcement learning technology enabled computing power scheduling framework based on kubernetes,” in 2023 IEEE 34th Annual Interna- tional Symposium on Personal, Indoor and Mobile Radio Communica- tions (PIMRC...

    2023

  10. [19]

    K8ssim: A simulation tool for kubernetes schedulers and its applications in scheduling algorithm optimization,

    S. Wen, R. Han, K. Qiu, X. Ma, Z. Li, H. Deng, and C. Liu, “K8ssim: A simulation tool for kubernetes schedulers and its applications in scheduling algorithm optimization,” Micromachines, vol. 14, no. 3, p. 651, 2023. [Online]. Available: https://doi.org/10.3390/mi14030651

    2023 doi

  11. [20]

    Resource management in edge and fog computing using fogbus2 framework,

    M. Goudarzi, Q. Deng, and R. Buyya, “Resource management in edge and fog computing using fogbus2 framework,” arXiv preprint arXiv:2108.00591, 2021. [Online]. Available: https://doi.org/10.48550/ arXiv.2108.00591

    2021 doi arXiv

  12. [21]

    Tf-ddrl: A transformer-enhanced distributed drl technique for scheduling iot applications in edge and cloud computing environments,

    Z. Wang, M. Goudarzi, and R. Buyya, “Tf-ddrl: A transformer-enhanced distributed drl technique for scheduling iot applications in edge and cloud computing environments,” arXiv preprint arXiv:2410.14348 ,

    arXiv

  13. [22]

    Root cause analysis for microservices based on causal inference: How far are we?

    L. Pham, H. Ha, and H. Zhang, “Root cause analysis for microservices based on causal inference: How far are we?” in 2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE) , 2024, pp. 706–718

    2024

  14. [23]

    Gremlin: Systematic resilience testing of microservices,

    V . Heorhiadi, S. Rajagopalan, H. Jamjoom, M. K. Reiter, and V . Sekar, “Gremlin: Systematic resilience testing of microservices,” in 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), 2016, pp. 57–66

    2016

  15. [24]

    µ-ddrl: A qos-aware distributed deep reinforcement learning technique for service offloading in fog computing environments,

    M. Goudarzi, M. A. Rodriguez, M. Sarvi, and R. Buyya, “ µ-ddrl: A qos-aware distributed deep reinforcement learning technique for service offloading in fog computing environments,” arXiv preprint arXiv:2310.09003, 2023. [Online]. Available: https://doi.org/10.48550/ arXiv.2310.09003

    2023 doi arXiv

  16. [25]

    Architectural resilience in cloud, fog and edge systems: A survey,

    V . Prokhorenko and M. Ali Babar, “Architectural resilience in cloud, fog and edge systems: A survey,” IEEE Access , vol. 8, pp. 28 078–28 095, 2020

    2020

  17. [26]

    Reinfog: A drl empowered framework for resource management in edge and cloud computing environments,

    Z. Wang, M. Goudarzi, and R. Buyya, “Reinfog: A drl empowered framework for resource management in edge and cloud computing environments,” arXiv preprint arXiv:2411.13121 , 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2411.13121

    2024 doi arXiv

  18. [27]

    A study on the aging and fault tolerance of microservices in kubernetes,

    J. Flora, P. Gonc ¸alves, M. Teixeira, and N. Antunes, “A study on the aging and fault tolerance of microservices in kubernetes,” IEEE Access, vol. 10, pp. 132 786–132 799, 2022

    2022

  19. [28]

    Chaos engineering,

    A. Basiri, N. Behnam, R. de Rooij, L. Hochstein, L. Kosewski, J. Reynolds, and C. Rosenthal, “Chaos engineering,” IEEE Software , vol. 33, no. 3, pp. 35–41, May/Jun 2016

    2016

  20. [29]

    Cloud failure prediction based on traditional machine learning and deep learning,

    T. N. Tengku Asmawi, A. Ismail, and J. Shen, “Cloud failure prediction based on traditional machine learning and deep learning,” J. Cloud Comput. , vol. 11, no. 1, Sep. 2022. [Online]. Available: https://doi.org/10.1186/s13677-022-00327-0

    2022 doi

  21. [30]

    Resilience in edge computing: Challenges and concepts,

    D. Ergenc ¸, A. Memedi, M. Fischer, and F. Dressler, “Resilience in edge computing: Challenges and concepts,” Found. Trends Netw. , vol. 14, no. 4, p. 254–340, May 2025. [Online]. Available: https://doi.org/10.1561/1300000074

    2025 doi

  22. [31]

    Orcas: Efficient resilience benchmarking of microservice architectures,

    A. van Hoorn, A. Aleti, T. F. D ¨ullmann, and T. Pitakrat, “Orcas: Efficient resilience benchmarking of microservice architectures,” in 2018 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW), 2018, pp. 146–147

    2018

  23. [32]

    The netflix simian army,

    Netflix, “The netflix simian army,” http://techblog.netflix.com/2011/07/ netflix-simian-army.html, 2011, netflix TechBlog, Jul. 2011

    2011

  24. [33]

    Service-level fault injection testing,

    C. S. Meiklejohn, A. Estrada, Y . Song, H. Miller, and R. Padhye, “Service-level fault injection testing,” in Proceedings of the ACM Symposium on Cloud Computing, ser. SoCC ’21. New York, NY , USA: Association for Computing Machinery, 2021, p. 388–402. [Online]. Available: htt...

    2021

  25. [34]

    Can my microservice tolerate an unreliable database? resilience testing with fault injection and visualization,

    M. Assad, C. S. Meiklejohn, H. Miller, and S. Krusche, “Can my microservice tolerate an unreliable database? resilience testing with fault injection and visualization,” in Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceed...

    2024

  26. [35]

    Microfi: Non-intrusive and prioritized request-level fault injection for microservice applications,

    H. Chen, P. Chen, G. Yu, X. Li, and Z. He, “Microfi: Non-intrusive and prioritized request-level fault injection for microservice applications,” IEEE Trans. Dependable Secur. Comput. , vol. 21, no. 5, p. 4921–4938, Sep. 2024. [Online]. Available: https://doi.org/10.1109/TDSC.2...

    2024 doi

  27. [36]

    Microres: Versatile resilience profiling in microservices via degradation dissemination indexing,

    T. Yang, C. Lee, J. Shen, Y . Su, C. Feng, Y . Yang, and M. R. Lyu, “Microres: Versatile resilience profiling in microservices via degradation dissemination indexing,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2...

    2024

  28. [37]

    Towards a fault taxonomy for microservices-based applications,

    F. Silva, V . Lelli, I. Santos, and R. Andrade, “Towards a fault taxonomy for microservices-based applications,” in Proceedings of the XXXVI Brazilian Symposium on Software Engineering , ser. SBES ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 247–256. ...

    2022

  29. [38]

    Chaos mesh – open source chaos engineering platform for kubernetes,

    Chaos Mesh Project, “Chaos mesh – open source chaos engineering platform for kubernetes,” https://chaos-mesh.org, 2019, cNCF Sandbox project, originally by PingCAP, launched 2019

    2019

  30. [39]

    Litmuschaos – open source cloud-native chaos engineering platform,

    LitmusChaos Project, “Litmuschaos – open source cloud-native chaos engineering platform,” https://litmuschaos.io, 2018, cNCF Incubation project, originally by MayaData, open-sourced 2018

    2018

  31. [40]

    Chaosblade: An open source chaos engineering tool,

    A. Group, “Chaosblade: An open source chaos engineering tool,” https: //github.com/chaosblade-io/chaosblade, 2019, accessed: 2025-05-21

    2019

  32. [41]

    Chaos toolkit: Chaos engineering for every- one,

    R. Miles and contributors, “Chaos toolkit: Chaos engineering for every- one,” https://github.com/chaostoolkit/chaostoolkit, 2016, accessed: 2025- 05-21

    2016

  33. [42]

    Powerfulseal: A tool for test- ing kubernetes resilience,

    B. Renski and the PowerfulSeal team, “Powerfulseal: A tool for test- ing kubernetes resilience,” https://github.com/powerfulseal/powerfulseal, 2020, accessed: 2025-05-21

    2020

  34. [43]

    chaoskube: Chaos engineering for kubernetes by ran- dom pod deletion,

    M. Hausenblas, “chaoskube: Chaos engineering for kubernetes by ran- dom pod deletion,” https://github.com/linki/chaoskube, 2016, accessed: 2025-05-21

    2016

  35. [44]

    A fault injection platform for learning aiops models,

    F. Bagehorn, J. Rios, S. Jha, R. Filepp, L. Shwartz, N. Abe, and X. Yang, “A fault injection platform for learning aiops models,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering , ser. ASE ’22. New York, NY , USA: Association for ...

    2023

  36. [45]

    Iotrepair: Flexible fault handling in diverse iot deployments,

    M. Norris, Z. B. Celik, P. Venkatesh, S. Zhao, P. McDaniel, A. Sivasubramaniam, and G. Tan, “Iotrepair: Flexible fault handling in diverse iot deployments,” ACM Trans. Internet Things , vol. 3, no. 3, Jul. 2022. [Online]. Available: https://doi.org/10.1145/3532194

    2022 doi

  37. [46]

    A study on chaos engineering for improving cloud software quality and reliability,

    S. De, “A study on chaos engineering for improving cloud software quality and reliability,” in 2021 International Conference on Disruptive Technologies for Multi-Disciplinary Research and Applications (CENT- CON), vol. 1, 2021, pp. 289–294

    2021

  38. [47]

    Chaos engineering in the wild: Findings from github,

    J. Owotogbe, I. Kumara, D. D. Nucci, D. A. Tamburri, and W.-J. van den Heuvel, “Chaos engineering in the wild: Findings from github,” 2025, submitted on 19 May 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2505.13654

    2025 doi arXiv

  39. [48]

    Chaos engineering in cloud-native applications: A resilience-driven approach to modern software systems,

    S. Sile, S. Shekhar, A. Flourish, and R. Khurana, “Chaos engineering in cloud-native applications: A resilience-driven approach to modern software systems,” December 2023

    2023

  40. [49]

    Swarm storm: An automated chaos tool for docker swarm applications,

    T. Higgins, D. N. Jha, and R. Ranjan, “Swarm storm: An automated chaos tool for docker swarm applications,” in Proceedings of the 33rd International Symposium on High-Performance Parallel and Distributed Computing , ser. HPDC ’24. New York, NY , USA: Association for Computing ...

    2024

  41. [50]

    Chaos engineering: A multi-vocal literature review,

    J. Owotogbe, I. Kumara, W.-J. V . D. Heuvel, and D. A. Tamburri, “Chaos engineering: A multi-vocal literature review,” 2024, submitted on 2 Dec

    2024

  42. [51]

    Continuous observability assurance in cloud-native applications,

    M. C. Borges and S. Werner, “Continuous observability assurance in cloud-native applications,” in 22nd IEEE International Conference on Software Architecture (ICSA’25) - Poster Track, 2025, arXiv:2503.08552 [cs.SE]. [Online]. Available: https://doi.org/10.48550/arXiv.2503.08552

    2025 doi arXiv

  43. [52]

    Available: https://doi.org/10.48550/arXiv.2412.01416

    [Online]. Available: https://doi.org/10.48550/arXiv.2412.01416

    doi arXiv

  44. [53]

    Fogbus2: a lightweight and distributed container-based framework for integration of iot- enabled systems with edge and cloud computing,

    Q. Deng, M. Goudarzi, and R. Buyya, “Fogbus2: a lightweight and distributed container-based framework for integration of iot- enabled systems with edge and cloud computing,” in Proceedings of the International Workshop on Big Data in Emergent Distributed Environments, ser. BiD...

    2021

  45. [54]

    A review of resilience testing in microservices architectures: Implementing chaos engineering for fault tolerance and system reliability,

    A. B. Mailewa, A. Akuthota, and T. M. D. Mohottalalage, “A review of resilience testing in microservices architectures: Implementing chaos engineering for fault tolerance and system reliability,” in 2025 IEEE 15th Annual Computing and Communication Workshop and Conference (CCW...

    2025

  46. [55]

    Investigating the impact of data normalization methods on predicting electricity consumption in a building using different artificial neural network models,

    Y .-S. Kim, M. K. Kim, N. Fu, J. Liu, J. Wang, and J. Srebric, “Investigating the impact of data normalization methods on predicting electricity consumption in a building using different artificial neural network models,” Sustainable Cities and Society , vol. 118, p. 105570, 2...

    2025

  47. [56]

    Sock shop demo - a microservice-based e- commerce demo for kubernetes,

    OCP Power Demos, “Sock shop demo - a microservice-based e- commerce demo for kubernetes,” https://github.com/ocp-power-demos/ sock-shop-demo, 2022, accessed: 2025-05-24

    2022

  48. [2024]

    Available: https://doi.org/10.48550/arXiv.2410.14348

    [Online]. Available: https://doi.org/10.48550/arXiv.2410.14348

    doi arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.