Resilient Auto-Scaling of Microservice Architectures with Efficient Resource Management

Christoph Treude; Claudia Szabo; Hussain Ahmad; Markus Wagner

REVIEW 3 major objections 4 minor 36 references

Resilient Auto-Scaling of Microservice Architectures with Efficient Resource Management

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read A disruption-aware auto-scaler detects lost pods and reallocates CPU capacity, reducing overutilization by up to 57.2% and increasing allocated CPU by up to 51.1% versus the disruption-blind Smart HPA.

desk verdict A sensible architectural extension undermined by a load-bearing experimental flaw: the described pod-deletion procedure cannot produce persistent resource loss, and the reported Supply CPU numbers contradict the stated remaining capacity. read the letter →

arxiv 2506.05693 v1 pith:K5BEWVCE submitted 2025-06-06 cs.DC

Hussain Ahmad , Christoph Treude , Markus Wagner , Claudia Szabo This is my paper · ORCID

classification cs.DC

keywords microserviceshorizontalpodauto-scalingKubernetesresourcedisruptionsallocationself-adaptivesystemsCPUoverutilizationresilience

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

SecureSmart HPA is a proposed extension of a Kubernetes horizontal pod auto-scaler (HPA) that makes scaling decisions aware of resource loss caused by faults, attacks, or maintenance. The paper's central claim is that by detecting when live pods are missing, updating each service's capacity to match reality, and moving unused capacity from overprovisioned to underprovisioned services, an auto-scaler can keep CPU use closer to its target after a disruption. In load tests on an 11-service e-commerce benchmark microservice application run on Kubernetes, the authors report that SecureSmart HPA outperforms its disruption-blind predecessor Smart HPA at 25%, 50%, and 75% simulated resource wastage, with up to a 57.2% reduction in CPU overutilization and a 51.1% increase in CPU allocation. If true, this would matter because real microservice deployments face faults and attacks that currently leave auto-scalers planning against capacities they no longer have.

What carries the argument

The load-bearing mechanism is the resource-loss detection and reallocation loop carried by the Application Capacity Manager and Application Resource Manager. The capacity manager computes resource loss as $\text{IRC} - \text{CRC}$, where $\text{IRC} = \sum_i \text{ResReq}_i \times \max R_i$ and $\text{CRC} = \sum_i \text{ResReq}_i \times \text{pod}_i$, converts the loss to a severity percentage, and updates each microservice's maximum replicas to its live pod count. The resource manager then sorts underprovisioned services by unmet demand and overprovisioned services by surplus, transfers capacity from the most overprovisioned to the most underprovisioned, and issues scaled replica counts within the updated capacities. This loop is what lets scaling decisions track actual available resources after a disruption.

What would settle it

Record the live pod count of each microservice for the ten minutes after the disruption is injected; if the counts return to their pre-deletion values within seconds, the claimed 25%, 50%, and 75% wastage levels did not persist, and the measured overutilization reductions cannot be attributed to the simulated disruptions.

Watch

Extended reading notes

Core claim

The central claim is that an HPA can be made resilient to resource disruptions by adding a dedicated capacity-management layer between per-service scaling and application-level resource redistribution. The new layer compares each microservice's initial capacity (maximum replicas times per-replica CPU request) with its current capacity (live pods times request); any positive difference is treated as a disruption, and every service's maximum replica count is capped at its current live-pod count. A centralized resource manager then collects the deficits of underprovisioned services and the surplus of overprovisioned ones, sorts both lists by size, and transfers capacity from the largest surplus to the largest deficit. The authors report that this mechanism reduces CPU overutilization by up to 57.2% and increases CPU supply by up to 51.1% relative to Smart HPA across low, medium, and high disruption severities.

Load-bearing premise

The load-bearing premise is that deleting microservice pods creates a resource shortage that lasts for the rest of the load test; in Kubernetes, the ReplicaSet controller normally recreates deleted pods within seconds, and the paper does not say how that recreation was prevented.

Editorial extensions

If this is right

If the measured gains hold, an HPA that corrects capacities after pod loss can keep CPU utilization closer to its threshold after disruptions at every tested severity.
At medium severity, the corrected capacities let the application use about half again as much CPU as the baseline, showing that disruption awareness prevents scaling attempts into unavailable resources.
Because the heuristics operate on resource demand and capacity rather than service-specific logic, they can be paired with other scaling policies and metrics such as response time.
At high severity, the system still stabilizes CPU utilization above the threshold but avoids the near-200% overutilization seen with the baseline.

Reading between the lines

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

Beyond the paper, the same detector could be extended to classify the cause of a pod shortfall, such as attack, fault, or routine scale-down, since the current logic treats any positive capacity gap as a disruption.
Beyond the paper, the greedy largest-deficit/largest-surplus matching in Algorithm 3 could be compared against other allocation policies to separate the benefit of capacity correction from the benefit of the matching rule.
Beyond the paper, publishing the raw pod-count or capacity traces after disruption would let readers verify that the simulated wastage persisted and would make the replication of the results direct.

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.

Desk Editor's Note

read the letter

The paper proposes SecureSmart HPA, a third layer on top of the authors' Smart HPA to detect resource loss and reallocate capacity during disruptions. That is a sensible idea, and the MAPE-K architecture is clearly laid out. The algorithms are readable, and the paper is honest about several limitations in Section V. Credit where due: the resource-redistribution heuristic is a natural extension, and the presentation is clean.

The problem is the experiment. The authors say they "randomly delete microservice pods" to create 25/50/75% resource wastage and that the system keeps running for another 9.5 minutes. In standard Kubernetes, a Deployment's ReplicaSet recreates deleted pods within seconds. Nothing in the paper says replica counts were scaled down, quotas imposed, or pod recreation blocked. So the described procedure would not yield a persistent resource loss. The current capacity (sum of ResReq_i * pod_i) would return to the initial value, and the disruption detector would see no loss.

This is not a minor gap. The headline numbers rest on it. There is also a concrete internal inconsistency: with 75% wastage (remaining capacity 1587.5 mCPU), Figure 4 reports Supply CPU of 2002.5 mCPU. Since Supply CPU is defined as the CPU allocated to current replicas, it cannot exceed the total requests of the remaining pods. Either the wastage was not applied as claimed, or the pods were recreated—both undermine the experiment.

The comparison against Smart HPA is also narrow: it is their own prior system, and the added detection layer is exactly the variable being tested. No error bars or significance tests are reported, and no code or data is shipped. These are secondary issues but would matter even after fixing the injection.

Who gets value from this? Someone working on disruption-aware auto-scaling might find the architecture a useful starting point, but only as a design sketch. As an empirical claim, the paper currently does not support its own conclusions.

Recommendation: send it to peer review, but with the expectation of major revision. The idea is worth engaging with; the current experimental validation is not. An editor should ask for a correct disruption-injection mechanism, a baseline that includes the standard Kubernetes HPA, and a check that reported Supply CPU never exceeds remaining capacity.

Referee Report

3 major / 4 minor

Summary. The paper proposes SecureSmart HPA, a three-layered hierarchical auto-scaler for Kubernetes microservice architectures that extends the authors' prior Smart HPA with a disruption-detection and capacity-adjustment layer. The manuscript describes algorithms for microservice-level scaling (Algorithm 1), disruption detection and severity estimation (Algorithm 2), and resource redistribution among overprovisioned and underprovisioned services (Algorithm 3). The evaluation uses the Online Boutique benchmark on AWS EKS under three injected disruption severities (25%, 50%, and 75% resource wastage) and reports that SecureSmart HPA reduces CPU overutilization by up to 57.2% and increases resource allocation by up to 51.1% compared with Smart HPA. The central claim is that a disruption-aware HPA can maintain microservices closer to their CPU target after resource loss and allocate usable CPU more effectively than a disruption-blind but resource-exchanging baseline.

Significance. If the empirical claims hold, the paper makes a useful contribution: it identifies a real limitation of Kubernetes-style HPAs (their blindness to resource loss caused by faults, attacks, or maintenance) and proposes a concrete, clearly specified architectural extension with a heuristic resource-redistribution mechanism. A strength of the manuscript is that the algorithms are described with enough precision to be reimplemented, and the evaluation repeats each load test 10 times. However, the experimental validity currently rests on an underspecified and internally inconsistent disruption-injection procedure. The paper's contribution is therefore conditional on a sound experimental demonstration; as written, the headline improvements are not supported by the reported data.

major comments (3)

[Section IV-A6 and Algorithm 2] The disruption-injection procedure as described cannot sustain the claimed wastage levels. The text states that disruptions are injected by deleting microservice pods to achieve 25%, 50%, and 75% resource wastage. In a standard Kubernetes Deployment, the ReplicaSet controller recreates deleted pods within seconds, so "podi" and hence the Current Resource Capacity calculated in Algorithm 2 would return to the pre-deletion values. The paper does not state that replica counts were scaled down, that a resource quota or node drain was used, or that pod recreation was otherwise prevented. Without a persistent reduction in "podi", the severity scenarios in Table II do not hold for the 9.5-minute post-injection observation window, and the evaluation would measure normal operation rather than disrupted operation. Please specify the actual mechanism used and provide evidence that "podi" remained reduced throughout the observation window.
[Section IV-B1, Fig. 4(a), and Table II] The reported Supply CPU at High severity is internally inconsistent with the stated remaining capacity. Table II fixes the remaining resource at High severity at 1587.5 mCPU (25% of the 6350 mCPU total), and Table I defines Supply CPU as the CPU resources allocated to the current replicas. Yet Fig. 4(a) reports SecureSmart HPA Supply CPU of 2002.50 mCPU at High severity. Since the current replicas' total requests cannot exceed the remaining capacity, this value should be at most 1587.5 mCPU unless the resource-exchange mechanism creates physical CPU resources, which it cannot. Please reconcile the metric definitions, the wastage arithmetic, and the reported values; the same inconsistency also affects the interpretation of the Medium and High severity comparisons in Fig. 6.
[Section IV-B and Fig. 6] The performance comparisons supporting the abstract's headline claims (57.2% reduction in CPU overutilization and 51.1% increase in resource allocation) are reported without any measure of variability. Section IV-B states that each load test was repeated 10 times and average results were computed, but no error bars, standard deviations, confidence intervals, or significance tests are provided. Because the claims are relative improvements over a baseline in a public-cloud environment, the absence of dispersion information makes it impossible to assess whether the observed differences are robust. Please report per-trial distributions or statistical tests for the key metrics in Figs. 4 and 6.

minor comments (4)

[Section IV-A6] The random deletion procedure is underspecified: no random seed is given, and no algorithm is described for ensuring that the randomly selected microservices and replica counts sum exactly to the target wastage levels of 25%, 50%, and 75%. Without this, the severity labels may be approximate.
[Section IV-B1] The sentence 'The final 741.00 mCPU represents the residual resource just before the 5.5-minute mark' is at odds with the surrounding paragraph, which describes post-disruption behavior; please clarify the time window over which each evaluation metric is averaged.
[Algorithm 2] The notation "podi" is introduced in the algorithm header, but the prose refers to 'the total number of available pods for each microservice in real-time'; please clarify whether this is an instantaneous count or an average over the observation window.
[Section V] The threats-to-validity section states that Smart HPA outperforms the Kubernetes baseline HPA, but this paper makes no direct comparison with the Kubernetes default HPA; please clarify that the baseline for the claimed improvements is the authors' own Smart HPA, and consider adding a direct default-HPA comparison or explicitly motivating its omission.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported improvements are measured outcomes, with no fitted parameter or self-citation chain forcing the result.

full rationale

SecureSmart HPA's headline claims are empirical results of load tests, not derivations from fitted inputs. Algorithm 2 defines disruption as a reduction in pod count (ResLoss = IRC - CRC), and Section IV-A6 injects disruptions by deleting pods; this is a controlled stimulus observed by a detector over the same physical quantity, which is an experimental setup rather than a circular reduction. The reported improvements in CPU overutilization and Supply CPU over Smart HPA are measured outputs of the resource-redistribution heuristic in Algorithm 3 under that stimulus; no parameter is fitted to the target metric and no equation makes the improvement equal to an input by construction. Self-citations to the authors' Smart HPA [12] provide the baseline system and configuration, but the comparison is executed and measured in the present paper, and the prior result that Smart HPA outperforms the Kubernetes HPA is cited only as contextual motivation, not as the proof of the claimed 57.2%/51.1% improvements. The disruption-injection procedure may raise experimental-validity concerns (e.g., Kubernetes pod recreation and the High-severity Supply CPU value exceeding the stated remaining capacity), but those concerns concern correctness and reproducibility, not circularity.

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

The central claim rests on the experimental scenario, which assumes a persistent resource loss after pod deletion and a transferable notion of CPU capacity. Both are domain assumptions not independently validated in the paper.

free parameters (2)

CPU utilization threshold (RMT) = 50%
Used as the target for scaling decisions and to compute CPU overutilization; inherited from Smart HPA, but a hand-chosen value that directly influences the overutilization metric.
Maximum replicas per service (maxR) = 5
Sets the total resource capacity (6350 mCPU) and the scaling limits; this configuration is stated to be the most favorable for Smart HPA, and changes in maxR would alter the measured improvements.

assumptions (4)

domain assumption Deleting microservice pods results in a sustained reduction in available resources with no pod recreation by the Kubernetes control plane.
Section IV-A6 injects disruptions by randomly deleting pods and assumes the remaining capacity stays at the target wastage level; normal ReplicaSet behavior would recreate pods, so this assumption is unstated and load-bearing.
domain assumption CPU capacity can be apportioned between microservices by adjusting maximum replica counts and desired replica counts.
Algorithm 3 redistributes resource amounts conceptually, but Kubernetes allocates CPU per container and does not transfer capacity from one deployment to another; the physical realization is not specified.
domain assumption The Online Boutique benchmark and the 15-minute ramp-and-sustain load profile represent realistic operational conditions.
Section V acknowledges this as a threat; results may not generalize to other applications or workloads.
domain assumption CPU utilization threshold of 50% and maximum 5 replicas per service constitute a fair and representative configuration.
These values are inherited from Smart HPA for comparison, but their effect on the relative improvement is not analyzed.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Resilient Auto-Scaling of Microservice Architectures with Efficient Resource Management." pith.science (2026). https://pith.science/paper/K5BEWVCE

@misc{pith2026250605693,
  author       = {Pith},
  title        = {Pith review of: Resilient Auto-Scaling of Microservice Architectures with Efficient Resource Management},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K5BEWVCE}},
  note         = {Machine review of arXiv:2506.05693}
}

read the original abstract

Horizontal Pod Auto-scalers (HPAs) are crucial for managing resource allocation in microservice architectures to handle fluctuating workloads. However, traditional HPAs fail to address resource disruptions caused by faults, cyberattacks, maintenance, and other operational challenges. These disruptions result in resource wastage, service unavailability, and HPA performance degradation. To address these challenges, we extend our prior work on Smart HPA and propose SecureSmart HPA, which offers resilient and resource-efficient auto-scaling for microservice architectures. SecureSmart HPA monitors microservice resource demands, detects disruptions, evaluates resource wastage, and dynamically adjusts scaling decisions to enhance the resilience of auto-scaling operations. Furthermore, SecureSmart HPA enables resource sharing among microservices, optimizing scaling efficiency in resource-constrained environments. Experimental evaluation at varying disruption severities, with 25%, 50%, and 75% resource wastage, demonstrates that SecureSmart HPA performs effectively across different levels of disruptions. It achieves up to a 57.2% reduction in CPU overutilization and a 51.1% increase in resource allocation compared to Smart HPA, highlighting its ability to deliver resilient and efficient auto-scaling operations in volatile and resource-constrained environments.

Figures

Figures reproduced from arXiv: 2506.05693 by the authors.

**Figure 3.** Load Test for Benchmark Application. an e-commerce platform that enables users to browse items, manage shopping carts, and complete purchases ( [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

**Figure 4.** Performance of SecureSmart HPA Across Varying Disruption Severity Levels. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗

Figures from the paper (2 more)

**Figure 6.** Figure 6: Comparison between SecureSmart HPA and Smart HPA. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

**Figure 7.** Figure 7: SecureSmart HPA vs. Smart HPA: CPU Utilization Comparison during Load Test. [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 35 canonical work pages

[1]

Proactive resource management for cloud of services environments,

G. Marques, C. Senna, S. Sargento, L. Carvalho, L. Pereira, and R. Matos, “Proactive resource management for cloud of services environments,” Future Generation Computer Systems , vol. 150, pp. 90–102, 2024

work page 2024
[2]

Microservice vulnerability analysis: A literature review with empirical insights,

R. K. Jayalath, H. Ahmad, D. Goel, M. S. Syed, and F. Ullah, “Microservice vulnerability analysis: A literature review with empirical insights,” IEEE Access, 2024

work page 2024
[3]

Towards Deep Learning Enabled Cybersecurity Risk Assessment for Microservice Architectures

M. Abdulsatar, H. Ahmad, D. Goel, and F. Ullah, “Towards deep learning enabled cybersecurity risk assessment for microservice architectures,” arXiv preprint arXiv:2403.15169 , 2024

work page Pith review arXiv 2024
[4]

Docker: Accelerated container application development

Docker, “Docker: Accelerated container application development.” https: //www.docker.com (Accessed: Nov. 12, 2024)

work page 2024
[5]

Kubernetes: A container orchestration platform

Kubernetes, “Kubernetes: A container orchestration platform.” https: //kubernetes.io (Accessed: Nov. 15, 2024)

work page 2024
[6]

Openshift container platform

R. Hat, “Openshift container platform.” https://www.redhat.com/en/ technologies/cloud-computing/openshift/container-platform (Accessed: Nov. 15, 2024)

work page 2024
[7]

Docker swarm: A container orchestration platform

D. Swarm, “Docker swarm: A container orchestration platform.” https: //docs.docker.com/engine/swarm (Accessed: Nov. 15, 2024)

work page 2024
[8]

Hierarchical scaling of microservices in kubernetes,

F. Rossi, V . Cardellini, and F. L. Presti, “Hierarchical scaling of microservices in kubernetes,” in IEEE Int. Conf. on Autonomic Computing and Self-organizing Systems (ACSOS) , pp. 28–37, IEEE, 2020

work page 2020

Show all 36 references

[9]

Horizontal pod autoscaling in kubernetes for elastic container orchestration,

T.-T. Nguyen, Y .-J. Yeom, T. Kim, D.-H. Park, and S. Kim, “Horizontal pod autoscaling in kubernetes for elastic container orchestration,” Sensors, vol. 20, no. 16, p. 4621, 2020

2020
[10]

Coordinating fast concurrency adapting with autoscaling for slo-oriented web applications,

J. Liu, S. Zhang, Q. Wang, and J. Wei, “Coordinating fast concurrency adapting with autoscaling for slo-oriented web applications,” IEEE Trans. on Parallel and Distributed Systems , vol. 33, pp. 3349–3362, 2022

2022
[11]

Showar: Right-sizing and efficient scheduling of microservices,

A. F. Baarzi and G. Kesidis, “Showar: Right-sizing and efficient scheduling of microservices,” in ACM Symposium on Cloud Computing (SoCC), pp. 427–441, 2021

2021
[12]

Smart HPA: A resource- efficient horizontal pod auto-scaler for microservice architectures,

H. Ahmad, C. Treude, M. Wagner, and C. Szabo, “Smart HPA: A resource- efficient horizontal pod auto-scaler for microservice architectures,” in 21st Int. Conf. on Software Architecture (ICSA) , pp. 46–57, 2024

2024
[13]

Failure diagnosis in microservice systems: A comprehensive survey and analysis,

S. Zhang, S. Xia, W. Fan, B. Shi, X. Xiong, Z. Zhong, M. Ma, Y . Sun, and D. Pei, “Failure diagnosis in microservice systems: A comprehensive survey and analysis,” arXiv preprint arXiv:2407.01710 , 2024

2024 arXiv
[14]

Exploiting miscoordination of microservices in tandem for effective ddos attacks,

A. Bremler-Barr, M. Czeizler, H. Levy, and J. Tavori, “Exploiting miscoordination of microservices in tandem for effective ddos attacks,” in IEEE INFOCOM, pp. 231–240, 2024

2024
[15]

Proactive autoscaling for cloud- native applications using machine learning,

N. Marie-Magdelaine and T. Ahmed, “Proactive autoscaling for cloud- native applications using machine learning,” in IEEE Global Communi- cations Conf. (GLOBECOM) , pp. 1–7, 2020

2020
[16]

Self-adaptation in microservice archi- tectures: a case study,

S. R. Boyapati and C. Szabo, “Self-adaptation in microservice archi- tectures: a case study,” in 26th Int. Conf. on Engineering of Complex Computer Systems (ICECCS) , pp. 42–51, 2022

2022
[17]

Horizontal auto-scaling in edge computing environment using online machine learning,

T. P. da Silva, A. F. R. Neto, T. V . Batista, F. A. Lopes, F. C. Delicato, and P. F. Pires, “Horizontal auto-scaling in edge computing environment using online machine learning,” in IEEE Int. Conf. on Dependable, Autonomic and Secure Computing , pp. 161–168, 2021

2021
[18]

Towards resource- efficient reactive and proactive auto-scaling for microservice architectures,

H. Ahmad, C. Treude, M. Wagner, and C. Szabo, “Towards resource- efficient reactive and proactive auto-scaling for microservice architectures,” Journal of Systems and Software , vol. 225, p. 112390, 2025

2025
[19]

Atom: Model-driven autoscaling for microservices,

A. U. Gias, G. Casale, and M. Woodside, “Atom: Model-driven autoscaling for microservices,” in IEEE 39th Int. Conf. on Distributed Computing Systems (ICDCS) , pp. 1994–2004, IEEE, 2019

1994
[20]

Delivering elastic containerized cloud applications to enable devops,

C. Barna, H. Khazaei, M. Fokaefs, and M. Litoiu, “Delivering elastic containerized cloud applications to enable devops,” in IEEE/ACM 12th Int. Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), pp. 65–75, IEEE, 2017

2017
[21]

Elascale: autoscaling and monitoring as a service,

H. Khazaei, R. Ravichandiran, B. Park, H. Bannazadeh, A. Tizghadam, and A. Leon-Garcia, “Elascale: autoscaling and monitoring as a service,” arXiv preprint arXiv:1711.03204 , 2017

2017 arXiv
[22]

Autonomic decentralized microservices: The gru approach and its evaluation,

E. D. Nitto, L. Florio, and D. A. Tamburri, “Autonomic decentralized microservices: The gru approach and its evaluation,” Microservices: Science and Engineering , pp. 209–248, 2020

2020
[23]

Geo-distributed efficient deployment of containers with kubernetes,

F. Rossi, V . Cardellini, F. L. Presti, and M. Nardelli, “Geo-distributed efficient deployment of containers with kubernetes,” Computer Commu- nications, vol. 159, pp. 161–174, 2020

2020
[24]

Machine learning- based auto-scaling for containerized applications,

M. Imdoukh, I. Ahmad, and M. G. Alfailakawi, “Machine learning- based auto-scaling for containerized applications,” Neural Computing and Applications, vol. 32, pp. 9745–9760, 2020

2020
[25]

Self-adaptive threshold-based policy for microservices elasticity,

F. Rossi, V . Cardellini, and F. L. Presti, “Self-adaptive threshold-based policy for microservices elasticity,” in 28th Int. Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), pp. 1–8, IEEE, 2020

2020
[26]

On patterns for decentralized control in self-adaptive systems,

D. Weyns, B. Schmerl, V . Grassi, S. Malek, R. Mirandola, C. Prehofer, J. Wuttke, J. Andersson, H. Giese, and K. M. Göschka, “On patterns for decentralized control in self-adaptive systems,” in Software Engineering for Self-Adaptive Systems II: Int. Seminar, Dagstuhl Castle, G...

2013
[27]

Microscaler: Cost-effective scaling for microservice applications in the cloud with an online learning approach,

G. Yu, P. Chen, and Z. Zheng, “Microscaler: Cost-effective scaling for microservice applications in the cloud with an online learning approach,” IEEE Trans. on Cloud Computing , vol. 10, no. 2, pp. 1100–1116, 2020

2020
[28]

Amazon web services (aws)

Amazon, “Amazon web services (aws).” https://www.amazon.com (Accessed: Nov. 24, 2024)

2024
[29]

Amazon elastic kubernetes service (eks)

Amazon, “Amazon elastic kubernetes service (eks).” https://aws.amazon. com/eks (Accessed: Dec. 10, 2024)

2024
[30]

Python parallel processing and multiprocessing: A rivew,

Z. A. Aziz, D. N. Abdulqader, A. B. Sallow, and H. K. Omer, “Python parallel processing and multiprocessing: A rivew,” Academic Journal of Nawroz University, vol. 10, no. 3, pp. 345–354, 2021

2021
[31]

Online boutique

Google, “Online boutique.” https://github.com/GoogleCloudPlatform/ microservices-demo (Accessed: Dec. 10, 2024)

2024
[32]

Benchmark requirements for microservices architecture research,

C. M. Aderaldo, N. C. Mendonça, C. Pahl, and P. Jamshidi, “Benchmark requirements for microservices architecture research,” in1st Int. Workshop on Establishing the Community-Wide Infrastructure for Architecture- Based Software Engineering (ECASE) , pp. 8–13, IEEE, 2017

2017
[33]

gym-hpa: Efficient auto-scaling via reinforcement learning for complex microservice-based applications in kubernetes,

J. Santos, T. Wauters, B. V olckaert, and F. De Turck, “gym-hpa: Efficient auto-scaling via reinforcement learning for complex microservice-based applications in kubernetes,” in NOMS IEEE/IFIP Network Operations and Management Symposium , pp. 1–9, IEEE, 2023

2023
[34]

pHPA: A proactive autoscaling framework for microservice chain,

B. Choi, J. Park, C. Lee, and D. Han, “pHPA: A proactive autoscaling framework for microservice chain,” in 5th Asia-Pacific Workshop on Networking (APNet), pp. 65–71, 2021

2021
[35]

Automated testing and resilience of microservice’s network-link using istio service mesh,

R. R. Karn, R. Das, D. R. Pant, J. Heikkonen, and R. Kanth, “Automated testing and resilience of microservice’s network-link using istio service mesh,” in 31st Conf. of Open Innovations Association (FRUCT) , pp. 79– 88, IEEE, 2022

2022
[36]

Load testing tool

Locust, “Load testing tool.” https://locust.io (Accessed: Dec. 12, 2024). 11

2024

Pith tools

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

[1] [1]

Proactive resource management for cloud of services environments,

G. Marques, C. Senna, S. Sargento, L. Carvalho, L. Pereira, and R. Matos, “Proactive resource management for cloud of services environments,” Future Generation Computer Systems , vol. 150, pp. 90–102, 2024

work page 2024

[2] [2]

Microservice vulnerability analysis: A literature review with empirical insights,

R. K. Jayalath, H. Ahmad, D. Goel, M. S. Syed, and F. Ullah, “Microservice vulnerability analysis: A literature review with empirical insights,” IEEE Access, 2024

work page 2024

[3] [3]

Towards Deep Learning Enabled Cybersecurity Risk Assessment for Microservice Architectures

M. Abdulsatar, H. Ahmad, D. Goel, and F. Ullah, “Towards deep learning enabled cybersecurity risk assessment for microservice architectures,” arXiv preprint arXiv:2403.15169 , 2024

work page Pith review arXiv 2024

[4] [4]

Docker: Accelerated container application development

Docker, “Docker: Accelerated container application development.” https: //www.docker.com (Accessed: Nov. 12, 2024)

work page 2024

[5] [5]

Kubernetes: A container orchestration platform

Kubernetes, “Kubernetes: A container orchestration platform.” https: //kubernetes.io (Accessed: Nov. 15, 2024)

work page 2024

[6] [6]

Openshift container platform

R. Hat, “Openshift container platform.” https://www.redhat.com/en/ technologies/cloud-computing/openshift/container-platform (Accessed: Nov. 15, 2024)

work page 2024

[7] [7]

Docker swarm: A container orchestration platform

D. Swarm, “Docker swarm: A container orchestration platform.” https: //docs.docker.com/engine/swarm (Accessed: Nov. 15, 2024)

work page 2024

[8] [8]

Hierarchical scaling of microservices in kubernetes,

F. Rossi, V . Cardellini, and F. L. Presti, “Hierarchical scaling of microservices in kubernetes,” in IEEE Int. Conf. on Autonomic Computing and Self-organizing Systems (ACSOS) , pp. 28–37, IEEE, 2020

work page 2020