Carbon-Aware Microservice Deployment for Optimal User Experience on a Budget

Kevin Kreutz; Monica Vitali; Philipp Wiesner

REVIEW 4 major objections 7 minor 1 cited by

Carbon-Aware Microservice Deployment for Optimal User Experience on a Budget

T0 review · 4 major / 7 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 An optimizer that picks a microservice version and instance count every hour can keep an always-on service inside a carbon budget while improving user experience and revenue.

desk verdict A plausible carbon-aware microservice scheduler with a real gap: the paper never writes down the budget constraint, so the central claim is an assertion until the linked implementation supplies the missing model. read the letter →

arxiv 2506.21422 v1 pith:65MMTLT2 submitted 2025-06-26 cs.DC

Kevin Kreutz , Philipp Wiesner , Monica Vitali This is my paper

classification cs.DC

keywords GreenApplicationsServiceComputingEnergyEfficiencycarbon-awaredeploymentmicroserviceshourlycarbonbudgetQualityofExperiencerevenueoptimization

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

Interactive cloud services must be reachable at all times, so they cannot reduce emissions by shifting work to greener hours the way batch jobs can. This paper claims that the missing lever is deployment itself: an optimizer that each hour chooses which version of each microservice runs and how many instances serve it can stay within a prescribed carbon budget while maximizing user experience and revenue. In experiments with a five-microservice flight-booking application, the proposed Optimal Selection algorithm meets the budget under changing workloads and grid carbon intensities, whereas an always-on high-performance deployment overshoots it significantly. Compared with two simpler carbon-aware baselines, it achieves 5.44% higher quality of experience and 32.38% higher revenue on average. If correct, this would let operators of long-running services treat carbon as a hard hourly constraint without sacrificing experience or profit.

What carries the argument

The central mechanism is the annotated microservice model plus a per-hour carbon-to-energy conversion. Each microservice version carries an energy demand per instance, a request capacity, a QoE score, and, for optional microservices, a revenue contribution. The grid's carbon intensity converts the hourly carbon budget into an energy budget, and the Optimal Selection (OS) algorithm picks a version and instance count for each microservice whose combined energy fits that budget while maximizing a weighted sum of normalized QoE and revenue scores, with weights $\alpha$ and $\beta$ chosen by the application owner. Optional microservices may be switched off entirely, which is how the optimizer sheds load under tight budgets.

What would settle it

Measure actual hourly energy consumption of the instance types in Table 1 (t3.micro, t3.xlarge, g2.2xlarge) under the same request rates and microservice mix used in the experiments; if the measured energy per instance disagrees substantially with the fixed ED annotations, then a deployment the optimizer certifies as within budget can exceed the carbon budget during real operation.

Watch

Extended reading notes

Core claim

The central claim is that an hourly carbon budget can be enforced at the deployment layer for long-running, always-on microservice applications, and that doing so is not a pure cost: the same choice that respects the cap can raise QoE and revenue. Each microservice is annotated with versions (for instance, a low-power variant that drops a computationally demanding feature), an optional flag, an energy demand per instance, a per-instance request capacity, a QoE score, and a revenue contribution. The optimizer, called Optimal Selection (OS), selects a version and horizontal scale-out for every microservice so that the total hourly energy demand stays within the energy allowance implied by the carbon budget and the grid's current carbon intensity, while maximizing the weighted objective of Equation 1. In the Flight Booking testbed, OS keeps the application within budget across all tested workload and carbon-intensity conditions; the high-performance baseline violates the budget, and the simpler carbon-aware sequential and fixed-config policies underperform on budget utilization. Averaged over the experiments, OS reports 5.44% better QoE and 32.38% more revenue than those two carbon-aware baselines.

Load-bearing premise

The energy-demand figures attached to each microservice version and instance type are accurate and stable, and the historical workload data are reliable enough to divide the yearly carbon budget into correct hourly slices.

Editorial extensions

If this is right

With trustworthy energy-demand annotations, the same optimizer can be applied to any long-running microservice application, because the budget constraint is expressed only through per-version annotations.
Tighter hourly budgets push the optimizer to low-power versions and to switching off optional microservices, so the application degrades gracefully instead of exceeding its carbon cap.
Looser budgets let the optimizer spend the full allowance on higher-QoE versions and revenue-generating optional services, which is the source of the measured 5.44% QoE and 32.38% revenue gains.
Because carbon intensity varies hour by hour, the same reconfiguration step can follow a changing grid mix, converting a yearly carbon target into operational decisions each hour.

Reading between the lines

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

The paper leaves the energy-demand annotations static; a testable extension is a closed-loop controller that measures real energy use and updates those values before each hourly decision.
The objective's weights $\alpha$ and $\beta$ define an operator's trade-off between user experience and revenue, so mapping the Pareto frontier across budget levels would make the policy's business consequences explicit.
The optimizer as described stays within one region; adding a location choice per microservice would combine this deployment-level carbon control with spatial workload shifting.
Replicating the experiment on a larger, heterogeneous microservice graph would show whether the reported QoE and revenue advantages persist or are specific to the flight-booking topology.

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 core idea is sound: treat microservice version selection and horizontal scaleout as a discrete optimization under an hourly carbon budget, and test it on a realistic booking application. That is a genuine extension of the batch-workload carbon scheduling literature and of the group's earlier quality-adaptation work.

What the paper does well: it identifies the right levers for long-running services (version choice plus scaleout), writes down a weighted objective for QoE and revenue (Eq. 1), and compares against three plausible baselines. The experiment shows the high-performance baseline blowing the budget while the proposed OS stays within it, with a reported 5.44% QoE and 32.38% revenue improvement over the carbon-aware baselines. As a short workshop paper, that is a reasonable proof-of-concept.

The soft spots are substantial. The optimization problem is never stated. There is no decision-variable definition, no constraint inequality for the hourly carbon budget, and no formula linking version choice, instance count, energy demand, user count, and carbon intensity. Eq. 1 is just an unconstrained weighted sum. The text says OS 'ensures budget constraints are met,' but the model that does that is absent. The GitHub repo may contain the missing specification, but a paper cannot outsource its central model to a link. This is a load-bearing gap because the headline claim is exactly that the method satisfies the budget.

Second, the evaluation is thin. One synthetic application, hand-set annotations in Table 1, no sensitivity analysis on the energy-demand values, no error bars, no real workload trace. Varying uc and QoE is something, but the numbers are small. Since QoE and revenue are the very terms the objective maximizes, beating baselines on those metrics is expected; the question is whether the budget constraint is actually enforced, and the paper does not show that.

The paper is not broken. The direction is plausible and the authors know the literature. But as written it is under-specified. A strong acceptance would require the full formal problem statement and a sensitivity analysis on ED.

This will be useful to researchers in green cloud computing as a compact idea with a public implementation, and as a reading-group example of what a short paper must make explicit. I would send it to review rather than desk-reject, because the idea is worth referee feedback. The expected decision is major revision: specify the constraint and decision variables, add sensitivity analysis, and consider a trace evaluation or at least more parameter sweep.

Referee Report

4 major / 7 minor

Summary. The paper proposes a carbon-aware deployment strategy for microservice-based cloud applications. For each microservice, the approach selects a version (e.g., low-power, normal, high-performance) and, according to the abstract, a horizontal scaleout, with the goal of maximizing a weighted sum of user experience (QoE) and revenue while respecting an hourly carbon budget. The method is evaluated on a flight-booking example with five microservices, comparing the proposed Optimal Selection (OS) algorithm against three baselines: High Performance, Sequential Carbon-Aware, and Simple Carbon-Aware. The reported results show that OS satisfies the carbon budget and improves QoE by 5.44% and revenue by 32.38% relative to the carbon-aware baselines.

Significance. If fully specified and validated, the work addresses a relevant gap: most carbon-aware cloud research targets batch workloads with temporal or spatial shifting, whereas interactive microservices must remain continuously available. The idea of adapting microservice versions and optional features to hourly carbon budgets is timely and practically motivated. The paper provides a concrete annotated example and a public repository, which are strengths for reproducibility. However, as written, the central optimization model is under-specified: the decision variables and budget constraints are never formally defined, and the empirical evaluation relies on unvalidated energy-demand constants. These issues currently prevent the reader from verifying the paper's main claim that the approach satisfies budget constraints while maximizing QoE and revenue.

major comments (4)

[Section 2, Eq. (1)] The paper never states the constrained optimization problem that the OS algorithm is claimed to solve. Eq. (1) is an unconstrained weighted sum over microservices of normalized QoE and revenue terms; it does not define the decision variables (which version is chosen for each microservice, nor the number of instances in the horizontal scaleout), and the 'Energy Budget' paragraph provides only a narrative description. No equation expresses the total hourly carbon as a function of version choice, instance count, per-request energy demand ED, user request count uc, and grid carbon intensity, and no budget inequality is given. Consequently, the assertion in Section 3 that OS 'ensuring budget constraints are met' is not checkable from the paper. Please state the full optimization problem, including the carbon accounting equation and the budget constraint.
[Table 1; Section 2] The ED values in Table 1 are fixed constants with no units, no measurement methodology, and no stated provenance. Budget compliance depends directly on these values, yet the paper provides no sensitivity analysis or validation against measured energy consumption. If actual energy per request or per instance deviates from these fixed annotations, the optimizer could either violate the stated carbon budget or unnecessarily sacrifice QoE. Because the central claim is budget satisfaction, the robustness of the results to the ED inputs must be demonstrated.
[Section 3, 'Experiments and Results'] The reported improvements of 5.44% in QoE and 32.38% in revenue are computed on exactly the quantities that the objective function in Eq. (1) maximizes. An optimizer is expected to outperform heuristic baselines on its own objective terms, so these figures are not independent evidence of correctness. The only independent validation would be budget compliance, and that compliance rests on the unvalidated ED values. The paper should add validation of budget adherence under realistic uncertainty in ED, and ideally evaluate on metrics not directly present in the objective.
[Section 3; Section 4; Abstract] The abstract and conclusion claim that the approach adapts to 'dynamic workloads and fluctuating energy mixes', but the experiment description in Section 3 only says that 'most parameters were kept fixed, while varying the values of uc and QoE'. No variation in carbon intensity or in workload over time is described, and Figure 3 shows only a single budget-setting scenario. Please either report the actual experimental conditions for dynamic workloads and carbon intensities or temper the claim to match what was tested.

minor comments (7)

[Table 1 caption] The caption contains a typo: 'microsevices' should be 'microservices'.
[Section 2, Application Architecture] The phrase 'Quality of the Experience' should be written as 'quality of experience' to match standard terminology and the abbreviation QoE.
[Figure 3] The y-axis label 'Carbon budget utilisation' is ambiguous; it should specify whether the values are a percentage of the yearly carbon budget or the hourly budget.
[References] Reference [13] is listed as 'CoRR (2023)' without an arXiv identifier, and reference [18] is listed as 'arXiv preprint (2024)' without a full arXiv ID. Please provide complete citation information.
[Section 3] The phrase 'The proposed algorithm ( Optimal Selection (OS) )' contains awkward extra spaces around 'Optimal Selection'; this should be formatted as 'Optimal Selection (OS)'.
[Throughout] Spelling is inconsistent: both 'optimisation' and 'optimization' are used. Please choose one convention.
[Equation (1)] The normalization terms, particularly the division by the number of microservices #ms and by revMax, are never defined. A brief explanation of revMax and the normalization rationale would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the QoE/revenue evaluation is a standard optimizer-versus-baseline comparison, and the paper's main gap is an unspecified budget constraint rather than a definitional loop.

full rationale

The paper's claimed derivation chain does not reduce a predicted quantity to an input by construction. Equation 1 defines the OS objective in terms of QoE and revenue, and Section 3 reports that OS outperforms three baselines on those same metrics; because the baselines do not optimize Equation 1, the comparison supplies a genuine, if expected, external reference, and the magnitudes of the reported 5.44% QoE and 32.38% revenue gains depend on the Table 1 annotations and experiment setup rather than following necessarily from the objective. The budget-satisfaction claim is not circular but is incompletely specified: Section 2 ('Energy Budget', 'Number of Users') describes budgets and workload narratively, and no equation states total hourly carbon as a function of version choice, instance count, ED, uc, q, and carbon intensity; the algorithm is merely 'designed to ... ensuring budget constraints are met'. That is an omitted specification, not a self-referential derivation. The self-citations ([15], [16], [17], [18]) are used for BPMN modeling and related work, not as load-bearing evidence, and no uniqueness theorem or imported ansatz is invoked. Accordingly, no circular step rises to the threshold defined in the review rules.

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

The central claim depends on hand-specified model parameters (ED, QoE, revenue, uc) and assumptions about workload forecasts and zero-cost version switching. These are not derived from data or external benchmarks, so the contribution is an optimization scheme over assumed inputs rather than a validated prediction.

free parameters (5)

alpha (α) = not specified
Weight for QoE in Eq. 1; chosen by the application owner, affects the trade-off between user experience and revenue.
beta (β) = not specified
Weight for revenue in Eq. 1; chosen by the application owner.
Energy demand (ED) per version = e.g., 13.0, 39.9, 305.4 from Table 1
Hand-set values for each microservice version and instance type; these directly determine whether the hourly carbon budget is met.
QoE and revenue per version = 0.5-1.0 QoE, 0-2 revenue from Table 1
Hand-set annotations; the objective and the reported improvements depend on these arbitrary values.
user capacity uc and transition probability q = 20000 or 50000; 0.5 or 0.1
Vary in experiments but are synthetic and not derived from measured data.

assumptions (4)

domain assumption Each microservice version has a fixed, known energy demand (ED) per hour, independent of runtime conditions and co-location effects.
Table 1 lists ED values; the optimization uses these to enforce the budget, but no measurement or sensitivity analysis is provided.
domain assumption The carbon budget is allocated hourly based on expected workload derived from previous years.
Section 2 'Energy Budget' states the budget is dynamically split hourly according to expected workload; if the forecast is wrong, budget violations occur.
ad hoc to paper User experience (QoE) and revenue are each additive across microservices and can be combined linearly with weights α and β as in Eq. 1.
The objective function is introduced without empirical or theoretical justification that this additive linear form represents true QoE or revenue.
domain assumption Optional microservices can be turned off without affecting the core workflow, and versions can be switched at runtime without cost.
The model assumes switching or disabling microservices has zero transition cost and no correctness impact; this is not stated or validated.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Carbon-Aware Microservice Deployment for Optimal User Experience on a Budget." pith.science (2026). https://pith.science/paper/65MMTLT2

@misc{pith2026250621422,
  author       = {Pith},
  title        = {Pith review of: Carbon-Aware Microservice Deployment for Optimal User Experience on a Budget},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/65MMTLT2}},
  note         = {Machine review of arXiv:2506.21422}
}

read the original abstract

The carbon footprint of data centers has recently become a critical concern. So far, most carbon-aware strategies have focused on leveraging the flexibility of scheduling decisions for batch processing by shifting the time and location of workload executions. However, such approaches cannot be applied to service-oriented cloud applications, since they have to be reachable at every point in time and often at low latencies. We propose a carbon-aware approach for operating microservices under hourly carbon budgets. By choosing the most appropriate version and horizontal scaleout for each microservice, our strategy maximizes user experience and revenue while staying within budget constraints. Experiments across various application configurations and carbon budgets demonstrate that the approach adapts properly to changing workloads and carbon intensities.

Figures

Figures reproduced from arXiv: 2506.21422 by the authors.

**Figure 1.** Overview of the Approach In the proposed approach, we apply the concept of hourly budgets of carbon emissions or time-based renewable energy certificates [9, 14] to microservice architectures. We propose an algorithm able to continuously reconfigure the microservice deployment according to the current budget, the energy mix of the electricity grid, and the workload. We show that our approach can satisfy the budge… view at source ↗

**Figure 2.** Flight Booking application in BPMN Microservice Versions Optional Instance-Type ED q uc QoE rev Flight Search Low Power no t3.micro 13.0 0.5 20000 or 5000 0.5 or 0.1 0 Normal t3.xlarge 39.9 0.7 20000 or 5000 0.75 or 0.3 0 High Performance g2.2xlarge 305.4 0.9 20000 or 5000 1 0 Weather Information Off yes 0.0 0.9 0 0 Normal t3.micro 13.0 1.0 20000 or 5000 1 0.2 Flight Booking Low Power no t3.micro 13.0 0.5 20000 or 5… view at source ↗

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

A Survey on Task Scheduling in Carbon-Aware Container Orchestration
cs.SE 2025-08 conditional novelty 4.0 of 10

A systematic survey categorizing carbon-aware Kubernetes scheduling algorithms along hardware/software and energy/carbon axes, with a proposed taxonomy.

Reference graph

Works this paper leans on

18 extracted references · 16 canonical work pages · cited by 1 Pith paper

[1]

Amazon. 2023. Amazon Sustainability Report. https://sustainability. aboutamazon.com/2023-amazon-sustainability-report.pdf

work page 2023
[2]

Tayebeh Bahreini, Asser Tantawi, and Alaa Youssef. 2022. An Approximation Algorithm for Minimizing the Cloud Carbon Footprint through Workload Sched- uling. In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD) . 522–531. https://doi.org/10.1109/CLOUD55607.2022.00075

arXiv 2022
[3]

European Commission. 2024. Rolling Plan for ICT standardisation. https://joinup.ec.europa.eu/collection/rolling-plan-ict-standardisation/ict- environmental-impact-rp2024

work page 2024
[4]

Ministerial Declaration. 2021. A Green and Digital Transformation of the EU

work page 2021
[5]

Ministerial Declaration. 2023. European Trading System Directive. https://eur- lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02003L0087-20230605

work page 2023
[6]

Constanze Fetting. 2020. The European green deal. ESDN Report, December 2, 9 (2020)

work page 2020
[7]

Google. 2024. Environmental Report. https://www.gstatic.com/gumdrop/ sustainability/google-2024-environmental-report.pdf

work page 2024
[8]

Conor Kelly, Eleni Mangina, and Antonio Ruzelli. 2011. Putting a CO2 figure on a piece of computation. In 11th International Conference on Electrical Power Quality and Utilisation. 1–7. https://doi.org/10.1109/EPQU.2011.6128960

work page arXiv 2011

Show all 18 references

[9]

Michael Kelly and David Gonzalez. 2023. The Role of Hourly EAC Markets in Facilitating the Clean Energy Transition . Technical Report. Google

2023
[10]

Justin J Meza, Thote Gowda, Ahmed Eid, Tomiwa Ijaware, Dmitry Chernyshev, Yi Yu, Md Nazim Uddin, Rohan Das, Chad Nachiappan, Sari Tran, et al . 2023. Defcon: Preventing Overload with Graceful Feature Degradation. In17th USENIX Symposium on Operating Systems Design and Implemen...

2023
[11]

Microsoft. 2024. How can we advance sustainability? 2024 Environmental Sus- tainability Report. https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/ RW1lMjE

2024
[12]

Tobias Piontek, Kawsar Haghshenas, and Marco Aiello. 2023. Carbon emission- aware job scheduling for Kubernetes deployments.The Journal of Supercomputing (06 2023), 1–21. https://doi.org/10.1007/s11227-023-05506-7

2023 doi
[13]

Thanathorn Sukprasert, Abel Souza, Noman Bashir, David E Irwin, and Prashant J Shenoy. 2023. Quantifying the benefits of carbon-aware temporal and spatial workload shifting in the cloud. CoRR (2023)

2023
[14]

Maud Texier. 2022. Timely progress towards around-the-clock carbon-free energy. Google. https://cloud.google.com/blog/topics/sustainability/t-eacs-help-drive- around-the-clock-carbon-free-energy

2022
[15]

Monica Vitali. 2022. Towards greener applications: enabling sustainable-aware cloud native applications design. In International Conference on Advanced Infor- mation Systems Engineering. Springer, 93–108

2022
[16]

Monica Vitali, Paul Schmiedmayer, and Valentin Bootz. 2023. Enriching Cloud- native Applications with Sustainability Features. In 2023 IEEE International Con- ference on Cloud Engineering (IC2E) . IEEE, 21–31

2023
[17]

Philipp Wiesner, Ilja Behnke, Dominik Scheinert, Kordian Gontarska, and Lauritz Thamsen. 2021. Let’s Wait Awhile: How Temporal Workload Shifting Can Reduce Carbon Emissions in the Cloud. In 22nd International Middleware Conference . ACM. https://doi.org/10.1145/3464298.3493399

2021
[18]

Philipp Wiesner, Dennis Grinwald, Philipp Weiß, Patrick Wilhelm, Ramin Khalili, and Odej Kao. 2024. Quality Time: Carbon-Aware Quality Adaptation for Energy- Intensive Services. arXiv preprint (2024)

2024

Pith tools

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

[1] [1]

Amazon. 2023. Amazon Sustainability Report. https://sustainability. aboutamazon.com/2023-amazon-sustainability-report.pdf

work page 2023

[2] [2]

Tayebeh Bahreini, Asser Tantawi, and Alaa Youssef. 2022. An Approximation Algorithm for Minimizing the Cloud Carbon Footprint through Workload Sched- uling. In 2022 IEEE 15th International Conference on Cloud Computing (CLOUD) . 522–531. https://doi.org/10.1109/CLOUD55607.2022.00075

arXiv 2022

[3] [3]

European Commission. 2024. Rolling Plan for ICT standardisation. https://joinup.ec.europa.eu/collection/rolling-plan-ict-standardisation/ict- environmental-impact-rp2024

work page 2024

[4] [4]

Ministerial Declaration. 2021. A Green and Digital Transformation of the EU

work page 2021

[5] [5]

Ministerial Declaration. 2023. European Trading System Directive. https://eur- lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02003L0087-20230605

work page 2023

[6] [6]

Constanze Fetting. 2020. The European green deal. ESDN Report, December 2, 9 (2020)

work page 2020

[7] [7]

Google. 2024. Environmental Report. https://www.gstatic.com/gumdrop/ sustainability/google-2024-environmental-report.pdf

work page 2024

[8] [8]

Conor Kelly, Eleni Mangina, and Antonio Ruzelli. 2011. Putting a CO2 figure on a piece of computation. In 11th International Conference on Electrical Power Quality and Utilisation. 1–7. https://doi.org/10.1109/EPQU.2011.6128960

work page arXiv 2011