# Life-cycle carbon assessment of by-design intermittent Fog services fully powered by renewable energy sources

Matteo Chancerel, Anne-Cécile Orgerie

► To cite this version:

Matteo Chancerel, Anne-Cécile Orgerie. Life-cycle carbon assessment of by-design intermittent Fog services fully powered by renewable energy sources. UCC 2025 - 18th IEEE/ACM International Conference on Utility and Cloud Computing, Dec 2025, Nantes, France. pp.1-10. hal-05365825

HAL Id: hal-05365825

https://hal.science/hal-05365825v1

Submitted on 14 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Life-cycle carbon assessment of by-design intermittent Fog
services fully powered by renewable energy sources

Matteo Chancerel

Anne-Cécile Orgerie

{anne-cecile.orgerie,matteo.chancerel}@irisa.fr

Univ Rennes, Inria, CNRS, IRISA

Rennes, France

ABSTRACT

To reduce their carbon footprint, some Fog operators power their
nodes with renewable energy combined with batteries to prevent
intermittency. Yet, often they do not consider the embodied carbon
footprint of the power infrastructure. Moreover, having 24h/7d
uptime for Fog services comes at a high embodied carbon cost and
do not favor the right to disconnect. In this paper, we model a
Fog infrastructure, geographically spread, powered by solar panels,
wind turbines and batteries for its whole life time. Its nodes are
turned off during the night and can be intermittent during the day.
We provide a theoretical framework to analyze the balance between
a satisfying uptime of the service, and a small carbon footprint. Our
simulation-based evaluation using real traces shows that reaching
95% of uptime during work hours rather than 99% divides by two
the size of the powering infrastructure, thus decreasing the carbon
footprint of the Fog and providing a usecase for combining both
environmental and social concerns of Fog users.

CCS CONCEPTS

* Computing methodologies → Distributed computing methodologies; * Computer systems organization → Cloud computing.

KEYWORDS

Fog, renewable energy sources, batteries, intermittent service, siz-
ing problem

1 INTRODUCTION

Since its birth, Cloud computing is attracting attention and users
with a massive cloudification of Internet services [43]. This tremen-
dous growth of Cloud services rely on hardware infrastructures,
namely data centers, that were at first using a centralized model
–i.e. few data centers in specific locations– and that are now spread-
ing towards the edge of communications networks linking them to
the users. These edge Cloud infrastructures do not replace large-
scale Cloud data center but extend their capacity especially in terms
of low latency. Before this geographical expansion, Cloud providers
were already consuming impressive amounts of electricity. Yet, this
consumption seems to further accelerate in the recent years. As an
example, according to their annual environmental reports, Google
data centers have reached 30.8 TWh in 2024 (annual electricity
consumption) [19]. Five years before, in 2020, they were consuming
14.4 TWh, thus doubling their consumption in the same period [19].

Facing this increase and in order to reduce their carbon footprint,
Cloud providers invest more and more in renewable energy sources,

Amazon being in 2024 “*the world's largest corporate purchaser of renewable energy for the fifth consecutive year*” [2]. Yet, these energy sources can be intermittent by nature (e.g., solar panels, wind turbines). Also, greening the electricity consumption during the use phase of these Cloud infrastructure may not reduce their overall footprint on their entire life cycle. Indeed, embodied carbon footprint (i.e. due to manufacturing) of servers and solar panels for instance, could dominate the overall carbon footprint depending on equipment refreshment rates [3].

At the opposite, few light-weight solar-powered infrastructures
have emerged to pave the road toward lighter, intermittent, local
Cloud infrastructures [4, 10]. These propositions mostly rely on
small servers or Fog nodes to deliver web services as it is the case
for the emblematic *Low-Tech Magazine* [10], a website hosted on a
small node powered by an on-site solar panel and a battery. This
website sometimes goes offline due to lack of power. While it could
be seen as a major drawback, we argue that it can be employed as
an advantage. Since several years, European Union companies and
countries are exploring the notion of “*the right to disconnect*”. In
2021, the European Parliament proposed recommendations on the
right to disconnect: “*the worker's right to disconnect from digital
tools, including information and communication technology (ICT),
for work purposes*” [14]. This recommendation inherits from the
European Pillar of Social Rights dealing with work-life balance and
healthy work environment [40]. Indeed, although bringing advan-
tages that may benefit to employees –like telework– the massive
digitalization of all sectors, fostered by Cloud technology, causes
major concerns regarding employees’ protection [40]. In this con-
text, Cloud infrastructures powered through intermittent renewable
energy sources could be used to deliver by-design intermittent ser-
vices only available during work hours. This is the idea we are
investigating in this paper.

We consider a light-weight Fog infrastructure, composed of few
small Fog nodes, geographically spread, and individually powered
through on-site renewable energy sources and energy storage de-
vices. We focus on a given Cloud service (e.g., mail server) available
only during work hours. The paper makes the following contribu-
tions:

(1) a theoretical framework to properly size the energy sources of the Fog infrastructure depending on a targeted level of quality of service

(2) a simulation-based evaluation of the framework based on
real Fog nodes' workload and energy production traces to
evaluate the performance of the proposed framework, both
in terms of performance and carbon footprint
(3) a thorough analysis on the influencing factors: the choice of renewable energy sources and their mix, the impact of devices' embodied carbon footprint, and the trade-off between service's uptime and Fog carbon footprint.

The rest of the paper is organized as follows. Section 2 introduces the state of the art and the motivation of the work. The proposed framework is detailed in Section 3. Section 4 presents the experimental conditions of the framework evaluation, while Section 5 provides an analysis of the simulation results. Section 6 discusses the limits and threats to validity. Finally, the conclusions and future work are presented in Section 7.

## 2 BACKGROUND AND STATE OF THE ART

Solutions to lower the CO₂ emissions of data centers have been widely studied in literature. Weppe et al. recently gave priorities to reduce emissions in data centers LCA (Life Cycle Assessment) [42]: (1) Reach energy-proportionality (2) Use low-carbon electricity (3) Extend servers lifetime

In the following, we detail techniques from the literature for each of these points.

### 2.1 Reaching energy-proportionality

For the first point, one of the most explored technique is called con-solidation. It consists of deploying the workload on the fewest nodes possible, to turn off idle servers. Indeed, the idle power consumption of servers is non-negligible, thus leading to no power proportional-ity with the server's load. Switching off unused servers allows to get closer to this proportionality since switched-off servers have a much lower power consumption than idle ones. Many resource management algorithms have been proposed to reach the fewest number of running nodes [12]. For instance, in the work of Lin et al. [28], the authors provide an optimal offline solution for a single data center and propose an online algorithm close to the optimal so-lution. This contribution targets a “business-as-usual” performance, meaning that each task is scheduled on a node whenever it is sub-mitted by a user. Other contributions explore trade-offs between energy consumption and performance (e.g., SLA violations, virtual machine migrations) [23]. Once optimization strategies, including consolidation, have been deployed to reach energy-proportionality, the GHG emissions of Cloud infrastructures can still be high if using fossil energies.

### 2.2 Using renewable energy sources

Using renewable energy sources to power data centers is the most explored option in literature to reduce their carbon footprint. Other options include carbon offset mechanisms, energy efficiency and waste heat recovery [5]. Many papers study data centers (partially) powered by renewable energy (mainly solar panels with Lithium-ion batteries) [17], and even some real experiments exist [18].

Parasol [18] is a small data center, powered by solar panels and batteries, and also plugged to the grid. It uses Greenswitch, a sched-uler that predicts workload and solar energy production, to deploy the workload on nodes.

Blink [36] is another small data center, powered by two solar panels and two wind turbines. It consists of 10 low-power nodes, that can transition from ON (8.6 W) to a sleep state (0.1 W), in only

1.6 seconds. This allows servers to “blink”, meaning alternating between ON and sleep to fit closely to the workload, and reach energy-proportionality. Blink is especially designed to deal with intermittent power.

Data Center Light [39] is a Swiss Cloud provider with the fol-lowing sustainable characteristics [38]: they use refurbished servers; they reuse an old factory hall instead of a new building; they claim to power their servers with 100% renewable energy (hydropower); they use passive cooling, by putting only one server per rack, and spacing racks;

they do not use batteries, and they buy new SSD and HDD for their refurbished servers. So even if they claim that they are zero carbon emission, it would be interesting to do a full LCA of their data center.

The Low-tech magazine [10] is a blog about low-tech. Since 2018, the website is hosted on a small server (Olimex A20 computer, consuming less than 2.5 W [9]) powered by a solar panel and a lead-acid battery, in Barcelona (Spain).

Inspired by the Low Tech Magazine, the Solar Protocol [4] intro-duces a distributed version of these solar-powered web servers. The idea is to deploy several servers spread all around the world. Each one is powered by a solar panel, plugged to a lead-acid battery. The protocol consists of directing web requests to the location having most sunshine in a follow-the-sun manner. The goal is not to have 100% uptime in each location, but to have a good uptime globally, for the website. In other words, at any moment, they do not want to have every server up, but at least one server up.

We could think that having several servers around the world allows to have smaller batteries, compared to having only one server. Yet, surprisingly, when we compare the solar protocol results to the Low-tech magazine figures, we see that they have the same size of solar panel (50 Watts-peak), but they use batteries three times bigger than the Low-tech magazine (22 Ah ×12V = 264 Wh, compared to 86.4 Wh). It would be interesting to see what it would give to have smaller batteries (or no battery) in that protocol. Their results indeed show that they need batteries to reach a good uptime, because there are moments when there is no sun, in any location [4]. Unfortunately, they do not provide the achieved uptime with their configuration, so we can not compare it to the Low-tech magazine.

Reaching electricity autonomy through on-site renewable energy sources (e.g., solar panels) is more difficult at the scale of a data center than for a single server or Fog node. Indeed, with the size of the data center comes more battery needs and the requirements for more complex strategies involving seasonal energy storage devices [17]. In this paper, we focus on small-size infrastructures gathering only few Fog nodes.

### 2.3 Extending servers lifetime

This research axis is more recent in literature than the two previous ones since extending hardware lifetime is often viewed as a cause of extra failures [31]. Yet, several recent contributions show that it is beneficial from a carbon footprint point of view and they propose ways to leverage applications' failure tolerance for exploiting old servers [41]. Samaye et al. [35] consider a solar-powered edge data center and they study the influence of server lifespan on the GHG emissions of this data center.
Deuxfleurs [11] is a French association that provide web services, such as email, static websites, videoconferencing. They refuse to buy brand new servers, and instead, they use old computers (from 2016–2017), hosted in the homes of members, that are in different cities. This allows to replicate the websites’ data on three machines in three different cities, so that even if there is a failure, they do not lose data, and the web hosting service is nearly never down. For the moment, they have nodes in Massy, Lille and Nantes, three French cities. They want to contribute to a sober Internet, but they take a critical look at optimization. They follow the principle given by Olivier Hamant [22]: robustness is the most important criterion, in an unpredictable world. That is why they have computers ON at each geographical site at any moment: to be able to replicate data, and to be resilient in case of power cut.

While these three techniques aim at reducing the carbon footprint of data centers, they are focusing on energy efficiency, and consequently, can lead to rebound effect [16]. In this paper, we go one step further than energy efficiency and we target sobriety by modifying users behavior in order to put energy limits. Indeed, the studied Fog infrastructure is, by design, interrupted during large period of time, when renewable energy sources are less abundant (i.e. during night time).

It is worth mentioning that there is a Swiss Cloud company that proposes a service named “7safecloud” [1], where they turn off the servers during the night. It is still possible to work offline, and the synchronization happens during the day. They do that to save energy, but also for security reasons: they say that most of cyberattacks happen during the night.

# 3 INTERMITTENT FOG MODEL

The network structure is inspired by Deuxfleurs [11].

Let Cities be a set of cities, where the nodes are present. There are several cities, for instance Bruxelles, Lille and Rennes. In each city, there is 1 Fog node. The services can run on each node, and data are backed up on each node. If a node runs out of energy (because the battery is empty, and there is no sun nor wind), the service is still available via the other cities. That means that the service is unavailable only if all cities run out of energy.

## 3.1 Fog infrastructure fully powered by renewable energy

### 3.1.1 Fog nodes.
For instance, the service can be a company mail server, with opening hours between $h_{start}$ and $h_{end}$. The nodes are shut down every night (after $h_{end}$), and turned on in the morning (at $h_{start}$). We assume that the power consumption of a node can be approximated by an affine function depending on its CPU usage, and idle power is approximately half of peak power [15]. Each node consumes between $P_{idle}$ and $P_{peak} = 2 \times P_{idle}$ when powered on.

For the modeling purpose, we opt for a time-slotted approach and given the granularity of the real traces used in the evaluation, without loss of generality, we consider time slots of 1 hour. For $0 \le h < 24$, let $c(h)$ denote the percentage of CPU usage at the hour $h$, and $E_{node}(h)$ be the energy needed to power the node at hour $h$. If $h_{start} \le h < h_{end}$, then $E_{node}(h) = (1-c(h)) \times P_{idle} + c(h) \times P_{peak} = (1 + c(h)) \times P_{idle}$. Else, $E_{node}(h) = 0$.

We consider two renewable energy sources: solar panels, denoted PV (for PhotoVoltaics), and Wind Turbines (WT).

### 3.1.2 Solar panels.
To model the production of solar power, we use data from PVGIS (PhotoVoltaic Geographical Information System [7]). It is an online tool that estimates the power produced by a solar panel, given a location.

We use the data from PVGIS which, for a given location, includes:

* the power produced by a PV with the best possible orientation and depending on the historical weather conditions.

* the wind-speed (from which we deduce the power produced by a wind turbine).

The system includes a solar charge controller, an inverter, and a Lithium-ion battery.

### 3.1.3 Wind turbines.
To model the production of power with wind turbines, we use windspeed data at 10 meters, also given by PVGIS [7]. The small wind turbine we use is 6 meters tall, so we use the following formula [33] to know the windspeed at 6 meters, with $\alpha = 1/7$, $u$ the windspeed at $z = 6$ m, and $u_r$ the windspeed at $z_r = 10$ m:

$$ \frac{u}{u_r} = \left( \frac{z}{z_r} \right)^{\alpha} $$

Then, we use this formula [13] to know the power generated:

$$ P(u) = P_r \times \begin{cases} 0 & u < v_c, \\ \frac{u^3 - v_c^3}{v_c^3 - v_r^3} & v_c \le u \le v_r, \\ \frac{1}{v_r} & v_r \le u < v_f, \\ 0 & v_f \le u. \end{cases} $$

We use the following values:

* the cut-in speed, $v_c = 3$ m/s [44], is the minimum windspeed to rotate the turbine.

* the rated speed, $v_r = 14$ m/s, is the speed after which the turbine rotates at a constant speed. We take an average of the values given in [13] (11 – 17 m/s).

* the cut-out speed, $v_f = 25$ m/s, is the speed above which the turbine stops rotating to protect itself.

* $P_r$ is the rated power of the turbine, which can vary according to the scenario.

### 3.1.4 Energy storage devices.
We use the abbreviation ESD for Energy Storage Devices, referring to batteries. As previously, we use a timeslot of one hour. Let $N$ be the number of timeslots. Let $T = [t_1, t_N]$ be the interval of timeslots. Let $c$ be a city in Cities. Let $E_{gen_c}(t)$ denote the energy generated by the renewable energy sources, and $E_{node_c}(t)$ denote the energy needed by the node, to be able to treat the workload. Let $E_{avail_c}(t)$ denote the energy ‘available’; with no battery, $E_{avail_c}(t) = E_{gen_c}(t)$. With a battery, $E_{avail_c}(t)$ is $E_{gen_c}(t)$ plus or minus what has been transferred to/from the battery.

We take nearly the same model of the battery as in [27]. We take Lithium-ion battery because they are widely used, and because of their density: they can store more energy than lead-acid batteries of the same volume.

Each variable is in Watt-hours (Wh). ESD$_{size}$ is the size of the battery. Let $\eta = 80\%$ be the Depth of Discharge; this means that we can only use 80 % of the real capacity, we can not empty the battery
below 20% of its charge. $C_{max} = \eta \times ESD_{size}$ is the amount that we can discharge from a battery fully charged.

Let $\lambda = 0.25 \times ESD_{size}$ be the maximum amount that we can charge in 1 hour, and $\mu = 5 \times \lambda$ be the maximum amount that we can discharge in 1 hour (both in Watt-hours). Let $C(t)$ be the charge level of the battery at time $t$. We start with a battery fully charged: $C(0) = C_{max}$. Let $\tau(t)$ be the amount of energy transferred in or out of the battery. It is always positive.

Hereafter, we describe the battery management algorithm depending on the possible situations:

(1) If $E_{gen_c}(t) \ge E_{node_c}(t)$, more energy is produced than needed, we can store it in the battery. Note that some energy is lost during the charge, that is why we multiply the transferred energy by $\sigma$, the energy efficiency. $C(t) = C(t-1) + \sigma \times \tau(t)$ and $E_{avail_c}(t) = E_{gen_c}(t) - \tau(t)$, with

$$ \tau(t) = \min \begin{cases} E_{gen_c}(t) - E_{node_c}(t) \\ \lambda \\ C_{max} - C(t-1) \end{cases} $$

$E_{gen_c}(t) - E_{node_c}(t)$ is the amount of energy produced and not consumed by the node. $\lambda$ is the maximum amount of energy that we can charge during one hour. $C_{max} - C(t-1)$ is the maximum amount of energy that we can charge, because we reach 100% of charge<fnref n="1" />.

(2) If $E_{gen_c}(t) < E_{node_c}(t)$, not enough energy is produced, so we would like to transfer energy from the battery to the node, only if we can transfer enough energy to power the node (else, it would be wasting the energy of the battery). Let $\tau(t)$ be the energy that we want to transfer:

$$ \tau(t) = \min \begin{cases} E_{node_c}(t) - E_{gen_c}(t) \\ \mu \\ C(t-1) \end{cases} $$

$E_{node_c}(t) - E_{gen_c}(t)$ is the amount of energy needed, the gap we want to fill. $\mu$ is the maximum amount of energy that we can discharge during one hour. $C(t-1)$ is all the energy available in the battery. There are 2 cases:

(a) If $E_{gen_c}(t) + \tau(t) = E_{node_c}(t)$, we can 'fill the gap', so $C(t) = C(t-1) - \tau(t)$ and $E_{avail_c}(t) = E_{gen_c}(t) + \tau(t)$.

(b) If $E_{gen_c}(t) + \tau(t) < E_{node_c}(t)$, it means that even if we discharge the maximum amount of power available in the battery, we will not have enough power to meet the workload. Instead, we charge the battery, like in case (1).

$$ \tau(t) = \min \begin{cases} E_{gen_c}(t) \\ \lambda \\ C_{max} - C(t-1) \end{cases} $$

We have $C(t) = C(t-1) + \sigma \times \tau(t)$ and $E_{avail_c}(t) = E_{gen_c}(t) - \tau(t)$.

## 3.2 Quality of service metrics

For each scenario, we mainly study two metrics:

* the percentage of uptime of the service during work hours.

* the embodied CO₂ of the infrastructure, in kgCO₂e/year.

This allows to compare scenarios, and to try to find the best infrastructure, trying to maximize the uptime, while minimizing the embodied carbon.

### 3.2.1 Percentage of uptime of the web service.
For each city $c$ in Cities, let $up_c = \{t \in [t_1, t_N] | E_{avail_c}(t) \ge E_{node_c}(t)\}$. This is the set of every moment when the node is up in that city.

Let $0 \le h_{start} < h_{end} < 24$. Let $H = [h_{start}, h_{end}]$ denote the interval of opening hours of the web service. Note that $h_{end}$ is excluded. Remember that $T = [t_1, t_N]$ is the interval of timestamps. Each timestamp has an attribute $t hour \in [0, 24]$, giving the hour of the day. Let $T^H = \{t \in T | t hour \in H\}$ denote the set of the timestamps during opening hours. For a set $S$, let $|S|$ denote its cardinal. To fix the ideas, here is an example over the year 2021: if $H = [7, 19]$, meaning that opening hours are 7am-7pm, $|H| = 12$. $|T| = 365 \times 24$ (it contains all timestamps over one year), $|T^H| = 365 \times 12$. The first timestamp in $T$ corresponds to January 1st, 2021, at 1am, while the first timestamp in $T^H$ corresponds to the same day at 7am.

Let $up_c^H = up_c \cap T^H$. $|up_c^H|$ is equal to the number of timeslots during opening hours when the node is up. We define $p_{up_c^H} = \frac{|up_c^H|}{|T^H|}$, the percentage of uptime of the node, in that particular city.

We run the same web service on multiple nodes in different cities. If a node is down, the service can still run on other nodes. The quantity we want to know is $p_{up_{total}}^H$, the percentage of opening hours when the web service is up.

In terms of set, $up_{total}^H = \cup_{c \in \text{Cities}} up_c^H$, because the service is up when at least one city is up.

We finally define $p_{up_{total}}^H = \frac{|up_{total}^H|}{|T^H|}$.

The percentage of downtime can be defined symmetrical, or simply as $p_{down_{total}}^H = 1 - p_{up_{total}}^H$.

### 3.2.2 CO₂ Life-cycle.
To find the embodied carbon of the infrastructure ($total_{CO₂/yr}$, in kgCO₂e/year), we use the following variables and equations.

(1) without battery: $total_{CO₂/yr} = PV_{CO₂/yr} + WT_{CO₂/yr}$

(2) with batteries:

$$ total_{CO₂/yr} = (PV_{CO₂/yr} + WT_{CO₂/yr}) * BOS_{ratio} + ESD_{CO₂/yr} \quad (1) $$

For $Ren \in \{PV, WT\}$:

* $Ren_{CO₂/yr} = Ren_{peak} * Ren_{CO₂/Wp} / Ren_{lifetime}$

* $Ren_{CO₂/yr}$ is the embodied carbon of the renewable energy source per year.

* $Ren_{peak}$ is the rated power of the energy source, in Watt-peak (Wp). This represents the maximum energy produced by the energy source, in the best meteorological conditions. It will vary with the size of the panel.

* $Ren_{CO₂/Wp}$ is the embodied carbon of the energy source on the whole lifetime, per Watt-peak.

* $Ren_{lifetime}$ is the lifetime of the turbine or the panel.

<footnote n="1">¹Technically, it never reaches 100%, because of the energy efficiency $\sigma$, but it comes very close.</footnote>
Most solar panels come from China [24]. For a panel manufactured in China in 2020 [26], we found a carbon footprint of $PV_{CO_2/Wp} = 1,105$ gCO₂e/Wp, and a lifetime of $PV_{lifetime} = 30$ years.

We use the data of a small wind turbine named Piggott, which is open source [34]. Zajicek et al. [44] made the LCA of a 400 Wp Piggott WT. They give a lifetime of $WT_{lifetime} = 20$ years, and a carbon footprint of 494 kgCO₂e on the whole life-cycle (craddle-to-grave).

As it is often the case in LCA, we make the assumption that it is linear, to define $WT_{CO_2e/Wp} = 494/400 = 1.235$ kgCO₂e/Wp (on the whole lifetime).

For the battery, $BOS_{ratio}$ is a variable that takes into account the carbon footprint of the Balance Of System (BOS) for a battery: cables, inverter, charge controller. BOS accounts for $p = 5\%$ of the carbon footprint of the photovoltaic system [32]. That is why $BOS_{ratio} = 100/(100-p)$.

For the embodied carbon of lithium-ion battery, we use the numbers of Gutsch and Leker [21]. They give the number of $ESD_{CO_2/kWh} = 64.5$ kgCO₂e/kWh on the cell level.

In the conclusion they say: "[Global Warming Potential] might increase by 20 to 35% if 1 kWh of lithium-ion battery on pack level rather than cell level is set as reference". That is why we multiply the result by $r_{pack/cell} = 135\%$. The battery lifetime is 8 years [20].

$ESD_{CO_2/yr} = ESD_{CO_2/kWh} * ESD_{size} * r_{pack/cell}/ESD_{lifetime}$

Remark that we do not take into account the carbon footprint of the nodes, for two reasons: First, we want to compare different sizes of panels, turbines or batteries, but we do not compare scenarios with different nodes (PCs vs servers, for example). Secondly, some initiatives like Deuxfleurs [11] and Sunflower [8], use old computers as servers, instead of buying new servers. In this case, the embodied carbon footprint may be considered as already “amortized”. And in any case, with a fixed number of servers (i.e. our case), this embodied cost is fixed and equal for all the scenarios.

Yet, to give an order of magnitude, here are the carbon footprint of 3 different nodes, for 3 different scales: a Raspberry PI 4, a PC, and a real server. The numbers are taken from [30]. The difference between their study and this one, is the electricity mix, because we use 100% renewable energy. That is why we subtract the usage emissions from the total, and divide by the lifetime (5 years [30]), thus using a classical allocation model per year [35]. We find those numbers:

* $RPi_{CO_2} = 2.9$ kgCO₂e/year for 5 years,

* $PC_{CO_2} = 58.9$ kgCO₂e/year for 5 years,

* $server_{CO_2} = 160.6$ kgCO₂e/year for 5 years.

# 4 EXPERIMENTAL SETUP

We are inspired by Deuxfleurs for the scenario. That is why we chose Bruxelles, Lille and Rennes, because they had nodes in those cities (even if today some nodes have moved in other cities). Their nodes are heterogeneous, but to simplify we suppose that all nodes are of the same type. Deuxfleurs gave us mail traces that come from a M73 Tiny with Celeron G1840T. They told us that the consumption of this computer is 11.5 W when idle. This is the number we take for our experiment (except for Figure 3, as explained later).

To summarize:

* Cities: Bruxelles, Lille, Rennes.

<figure><img src="image_2.png" /><figcaption>Figure 1: Power consumption of 1 PC for 4 days of workload: on top, with the original workload and on the bottom, for the modified version. The CPU usage varies between 0.23% and 29.1% in this latter case.</figcaption></figure>

* nodes: PCs M73 Tiny, with Celeron G1840T.

* node power when idle: 11.5 W

* opening-hours: 7am-7pm

* starting: 2021-01-01 for 365 days

For $p \in \{90, 95, 99\}$, we try to answer the following question: What is the minimal embodied carbon footprint of the infrastructure to reach $p\%$ of uptime?

## 4.1 Fog service

To model the workload, we use CPU traces of a mail server, over one month (June 2025), coming from Deuxfleurs [11]. It gives for each hour, the percentage of usage of the CPU.

We change this trace given by Deuxfleurs, to have a trace over 12h (from 7am to 7pm). We shift the workload of the night during the day, assuming that what people would normally do during the night, they will do it during the opening hours, before the nodes are shut down. This is possible because the CPU usage is always under 50%. For $0 \le h < 24$, let $c_{24}(h)$ denote the real trace (over 24h) at the hour $h$. Then the modified trace (over 12h) at the hour $h$ is given by:

$$c_{12}(h) = \begin{cases} c_{24}(h) + c_{24}(h-7) & \text{if } 7 \le h < 14, \\ c_{24}(h) + c_{24}(h+5) & \text{if } 14 \le h < 19, \\ 0 & \text{else.} \end{cases}$$

See Figure 1 to see the difference between the original workload, and the modified one. One can observe that when servers are turned off during the nights (bottom part), the total energy consumption is roughly divided by 2 compared to the always on case (top part), and thus it allows to reduce the panel, turbine and battery sizes.

## 4.2 Renewable energy production

On PVGIS, in the section Hourly Data, here are the parameters that we select: On the map, we click on the city we want. We select the database SARAH3 (if possible), else ERA5, because the first one
is more precise than the other, but not available everywhere. We use 2021 data. Mounting type: fixed, we select *Optimize slope and azimuth*, which gives the best orientation for a fixed panel. We select Crystalline Silicon PV, with 14% of system loss, and installed peak power = 1 kWp (the peak power will be changed in the code, to explore different sizes). Then we download the data in csv.

# 5 EVALUATION

## 5.1 Small example

Figure 2 shows an example provided by our framework for a 4-days experiment. It displays the uptime periods for 3 cities, and the state of the service (up when at least one city is up, down when every city is down). The power is generated by a 100 Wp solar panel and a 200 Wp wind turbine, and is stored in a 50 Wh battery. The node is a PC, consuming 11.5 W when idle.

The workload is in transparent-red, the power generated is in transparent-blue. The purple is a mix of red and blue, meaning that the node has been powered with the generated power: the node is up. When there is not enough power, the workload is in light-red: the node is down. The generated power can be split in 3 parts: 1) the part that is stored in the battery (in light-green), 2) the part that powers the node (in purple), 3) and the extra-part that is unused (in blue, above the workload).

We can see that during the third night some power is generated, this is due to the wind turbine. The stripes that appear on the fourth day in Rennes is due to little power production, and little battery charge; At the first hour (7am), there is enough power in the battery to power the node. At 8am, there is not enough power in the battery to power the node, even with the power generated by the panel, so this power charges the battery. And because of that, at 9am there is enough power in the battery to 'fill the gap' between the small power produced and the power needed by the node.

## 5.2 Employing both solar panels and wind turbines

To obtain the result of Figure 3, we slightly change the scenario, by using real servers instead of PCs, because the PCs need only 11 – 23 W, and the smallest Piggott wind turbine has a power of 200 Wp. Thus, we use a server that consumes 201 Watts when idle [30]. This is just to scale the power needed, and match better with the wind turbine sizes. As previously, there is one server in each of the three cities.

First, we remark that the wind turbines are not useful, according to the criteria we choose (only embodied CO₂), and the three cities we took. It means that for the same carbon footprint, it is always better to have a bigger solar panel and a bigger battery, than to have a smaller panel and a turbine.

On the graph, each point corresponds to an infrastructure, that is a triplet (PVsize, WTsize, ESDsize). The common point of all those infrastructures is that their embodied CO₂ is the same: 68 kgCO₂e/year. For each point, the solar panel size is given by the x-axis. The wind turbine size is given by the label of the curve. The battery size is implicit, its value is forced by the 2 others, to give a carbon footprint of 68 kgCO₂e/year. This value is chosen to reach 90% of uptime in at least one configuration (dotted line on Figure 3). Indeed, remember Equation 1 in Section 3.2.2. It can be rewritten as a linear equation

<figure><img src="image_3.png" /><figcaption>Figure 2: Overall and per site (for Bruxelles, Lille and Rennes) uptime. For each city, we see the workload and generated power, plus the battery charge. On the bottom subplot, we can see the total uptime. The service is down only when all cities are down.</figcaption></figure>

<figure><img src="image_4.png" /><figcaption>Figure 3: Total percentage of uptime between 7am and 7pm, for different infrastructures, all with embodied CO₂ = 68 kgCO₂e/year. In this Figure only we use servers that consume 201 Watts when idle.</figcaption></figure>
<figure><img src="image_5.png" /><figcaption>Figure 4: Percentage uptime between 7am and 7pm, of the service.</figcaption></figure>

$total_{CO_2} = A * X + B * Y + C * Z$, with (X, Y, Z) the aforementioned triplet. If $total_{CO_2}$. X and Z are given, then the value of Y is forced.

The values of WT\_size are chosen according to the Tripalium manual [37], a handbook that teaches how to build a Piggott wind turbine. They give 6 different sizes, we take the 2 smallest (200 and 350 Wp). We chose the values of PV\_size by trying different sizes, with a gap of 5 Wp. We see that the infrastructure that enables the longest uptime is the highest point, and it corresponds to $PV_{size} = 1300$ Wp, $WT_{size} = 0$ Wp, ESD\_size = 1638$ Wh (the size of the battery is not written on the picture, but can be deduced from the other values).

We made an exploration of the various parameters, and for each of them we noticed that the highest point had its $WT_{size} = 0$, meaning that it is always better to use solar panel and battery only.

## 5.3 Obtaining 90% uptime with minimal embodied cost

That is why, in the next experiments, we do not use wind turbines anymore and we only vary 2 parameters: the size of the solar panel, and the size of the battery. Now we come back to PCs consuming 11.5 Watts when idle, because this is what Deuxfleurs use.

On Fig. 4, each point corresponds to a tuple ($PV_{size}$, ESD\_size), but they have different carbon footprint, given by the legend of the graph. The solar panel size is given by the x-axis, the battery size is implicit, and its value can be found in the Table 1.

This shows that for this scenario *the minimal carbon footprint to reach 90% uptime is* 3.1 kgCO₂e/year. It can be achieved with a 60 Wp solar panel, and a 72 Wh battery. When we compare this footprint with the embodied carbon of a brand new PC (58.9 kgCO₂e/year), we see that *the PC has an impact 19 times bigger!* That is why it is important to extend the lifetime of the nodes, and why it is good to reuse old servers, instead of buy new ones. Deuxfleurs took this approach, and it would be interesting in a future work to estimate the embodied carbon of refurbished nodes, which mainly includes the transportation from their former place to their new usage location.

Remark that there are 2 configurations that reaches 90% uptime, we chose the one with the smallest battery. That is because CO₂ is

only one criteria, but Lithium-ion batteries have other environmental impacts, that makes us think that we should minimize their utilization and size. This still needs to be proven by doing the same work with other parameters among the 16 criteria of Life-Cycle Assessment. Also, there is not a unique configuration for the same uptime, sometimes two of them work, the only difference is an increase of the capacity of the battery, and a decrease of the size of the panel. If we had chosen the configuration with a bigger battery and a smaller panel, it would lead to different graphics and figures.

## 5.4 Percentage of uptime for a given carbon footprint

Figure 5 shows the percentage of uptime that can be reached for different embodied carbon. The data of each point, along with the size of the panel and battery, are given in Table 2. Note that the last value (99.73%) corresponds to 364/365, which means that the website would be down only one day over the whole year.

<table><caption>Table 2: Maximum uptime that can be reached for a given carbon footprint, and the associated infrastructure size (panel and battery).</caption><thead><tr><th>kgCO<sub>2</sub>e/year</th><th>uptime</th><th>PV size</th><th>battery size</th></tr></thead><tbody><tr><td>1</td><td>59.36%</td><td>20 W</td><td>20 Wh</td></tr><tr><td>2</td><td>81.83%</td><td>40 W</td><td>41 Wh</td></tr><tr><td>3</td><td>89.66%</td><td>55 W</td><td>80 Wh</td></tr><tr><td>4</td><td>93.26%</td><td>75 W</td><td>101 Wh</td></tr><tr><td>5</td><td>95.43%</td><td>90 W</td><td>140 Wh</td></tr><tr><td>6</td><td>97.17%</td><td>100 W</td><td>196 Wh</td></tr><tr><td>7</td><td>98.22%</td><td>115 W</td><td>235 Wh</td></tr><tr><td>8</td><td>99.04%</td><td>130 W</td><td>274 Wh</td></tr><tr><td>9</td><td>99.47%</td><td>140 W</td><td>330 Wh</td></tr><tr><td>10</td><td>99.61%</td><td>155 W</td><td>369 Wh</td></tr><tr><td>11</td><td>99.73%</td><td>190 W</td><td>336 Wh</td></tr></tbody></table>

<table><caption>Table 1: Data of each point of the Figure 4. For each curve, the data corresponding to the maximum uptime is in bold.</caption><thead><tr><th>kgCO<sub>2</sub>e/year</th><th>PV size</th><th>battery size</th><th>uptime</th></tr></thead><tbody><tr><td>3.0</td><td>40 Wp</td><td>133 Wh</td><td>85.48%</td></tr><tr><td>3.0</td><td>45 Wp</td><td>116 Wh</td><td>87.67%</td></tr><tr><td>3.0</td><td>50 Wp</td><td>98 Wh</td><td>88.90%</td></tr><tr><td><strong>3.0</strong></td><td><strong>55 Wp</strong></td><td><strong>80 Wh</strong></td><td><strong>89.66%</strong></td></tr><tr><td>3.0</td><td>60 Wp</td><td>62 Wh</td><td>89.57%</td></tr><tr><td>3.0</td><td>65 Wp</td><td>45 Wh</td><td>88.47%</td></tr><tr><td>3.0</td><td>70 Wp</td><td>27 Wh</td><td>85.53%</td></tr><tr><td>3.1</td><td>40 Wp</td><td>142 Wh</td><td>85.39%</td></tr><tr><td>3.1</td><td>45 Wp</td><td>125 Wh</td><td>88.08%</td></tr><tr><td>3.1</td><td>50 Wp</td><td>107 Wh</td><td>89.34%</td></tr><tr><td>3.1</td><td>55 Wp</td><td>89 Wh</td><td>90.09%</td></tr><tr><td><strong>3.1</strong></td><td><strong>60 Wp</strong></td><td><strong>72 Wh</strong></td><td><strong>90.07%</strong></td></tr><tr><td>3.1</td><td>65 Wp</td><td>54 Wh</td><td>89.70%</td></tr><tr><td>3.1</td><td>70 Wp</td><td>36 Wh</td><td>87.31%</td></tr></tbody></table>
<figure><img src="image_6.png" /><figcaption>**Figure 5:** Percentage of uptime (between 7am and 7pm) that can be reached for a given embodied carbon footprint.</figcaption></figure>

Another way to represent it, and to 'zoom' in the top-right corner, is to plot the downtime with a logscale axis; 90% uptime corresponds to 10% downtime, 99% up corresponds to 1% down, and 99.9% up corresponds to 0.1% down. This can be seen on Figure 6.

<figure><img src="image_7.png" /><figcaption>**Figure 6:** Minimum achievable downtime (x-axis is common to both subplots, and is logscale). For instance, to have 10% downtime, we need at least 3.1 kgCO₂e/year, and the upper plot provides the corresponding battery and solar panel sizes (75 Wp panel, 95 Wh battery).</figcaption></figure>

We can see that the bottom curve seems linear, which would mean that the embodied carbon is exponential with the inverse of the downtime. In fact, this is not exactly true, because there is a limit: 0% downtime can be reached with big enough infrastructure, whose embodied carbon is not infinite. We found that with a 130 Wp panel and a 797 Wh battery, the embodied footprint is 13.7 kgCO₂e/year,

and the uptime over the whole year is 100%. Surprisingly, this is because in the city of Rennes, the uptime is also 100%, and it is difficult to find a smaller infrastructure, where every city's uptime is strictly less than 100%, but the total uptime is 100%.

## 5.5 Dealing with the autumn-winter period

The previous results provide figures for the whole year analysis. Yet, solar panels production depend not only on the hour of the day but also on the day of the year. Thus, we study 2 scenarios:

* "full-year", is over 365 days, over the whole year 2021 (Jan. 1st - Dec. 31st).

* "autumn-winter", is over 5 months: from October 1st, 2021 to February 28th, 2022, this is the most critical period of the year for the PV production. The shortest day of the year is December 21st, and we take roughly 2 months before and after.

Figure 7 summarizes the results for both scenario, and for each percentage in {90, 95, 99}. Figures 8 and 9 show the sizes of the solar panel and the battery to obtain the corresponding carbon footprint.

We can see that in autumn and winter, it requires a bigger battery and panel to reach the same percentage than during the whole year, mostly because days are shorter, so we need a bigger battery to power the node from 7am to sunrise, and from sunset to 7pm, and a bigger panel to fill the battery. Surprisingly, even in winter, our simulations also showed that wind turbines are not useful. Even with only one city, the one with the least sun irradiance (Bruxelles), we get the same result. That is why we stay with batteries and solar panels only in this section.

On Figure 7, there is a wide range of carbon footprint, from 3.1 kgCO₂e/year to nearly the triple (9.6), for different performance and uptime. We also see that reaching 90% in autumn-winter takes a bigger footprint than reaching 95% on the whole year. This means that if we take the infrastructure corresponding to 90% in autumn-winter, we have more than 95% uptime on average on the whole year. And we can expect a much better uptime in the summer.

On Figure 8, for 90% uptime, we see a jump of +75% between the two scenarios (60 Wp to 105 Wp). This shows that a quite bigger panel is needed to have the same uptime in winter, and we may wonder if it is necessary.

In the same way, on Figure 9, for 95% uptime, we can see a jump of +137% between full-year and autumn-winter scenarios (95 Wh to 225 Wh). And for the full-year scenario, there is a +169% jump (95 Wh to 256 Wh) between 95% and 99% uptime.

It seems that the battery of 95 Wh is a good size, because it can reach 95% uptime over the whole year, and when we want to increase this uptime, we get a much bigger battery capacity.

On Figure 10, one can see that the longest blackout period last 10 hours, which means that every day of the year, there is at least one hour of uptime, even in winter (reminder: in a day there are 12 hours of opening schedule (7am-7pm)).

# 6 DISCUSSION

To decide which infrastructure to take, one should first define what is the minimal uptime they find acceptable. For instance, if we consider a uniform requests' time distribution, 90% uptime means that the website is down once in 10 times, 95% means it is down
<figure><img src="image_8.png" /><figcaption>Figure 7: Minimal embodied carbon to reach a desired uptime, for both scenarios.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Figure 8: Solar panel size corresponding to the embodied carbon of Fig. 7</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Figure 9: Battery capacity corresponding to the embodied carbon of Fig. 7</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Figure 10: Cumulative Distribution Function of the length of the down periods, with the “full-year” scenario, when reaching 90% uptime. For instance, more than 92% of the blackouts last less than 6 hours.</figcaption></figure>

once in 20 times, and 99% means it is down once in 100 times. When targeting a given uptime value, one should consider the most constrained period of the year (as in our “autumn-winter” scenario). Indeed, uptime periods are unevenly distributed throughout the year as illustrated on Figure 7.

We consider a given period of work hours (i.e. 7am-7pm), but we could instead change the opening hours to get closer with the sunset and the sunrise at a given location. Similarly, in the evaluation, we consider only three locations on the same timezone to keep with the idea of a local low-power infrastructure with a replication factor of only 3. Yet, our model is more generic and these parameters can be varied. The evaluation takes advantage of real CPU usage traces that do not saturate the PCs' capacities (below 30%). For more loaded servers, switching off the nodes may cause bottlenecks when powering them on again. Yet, low resource utilization is a recurring issue in Cloud data centers [6, 25, 29].

The wind turbine production model in the evaluation is founded on the Piggott model [44]. Yet, it is worth mentioning that, wind turbines and solar panels may have varying efficiency in practice. For instance, in Blink [36], they observe that their 400 Wp turbine generates only 40 W at maximum. Similarly, their 65 Wp solar panel generates 30 W at maximum. For the solar panel, we found the framework on the PVGIS model, that takes this efficiency into

account. Indeed, the highest value given in August (during summer) is less than 700 W with a 1000 Wp panel.

The fact that wind turbines do not seem to be required is valid because servers are in France. But when we try a city with little sun irradiance (Reykjavik, Iceland, with $880\,\text{kWh/m}^2/\text{year}$), we obtain results where wind turbines can be beneficial.

## 7 CONCLUSION AND FUTURE WORK

Cloud and Fog infrastructures are currently requiring tremendous amounts of electricity globally. In an effort to lower their carbon footprint, they resort more and more to renewable energy sources such as solar panels or wind turbines. Several precursor infrastructures, like the Low Tech Magazine [10] and the Solar Protocol [4], experiment the deployment of operational web services on local low-power Fog nodes powered through renewable energy sources and energy storage devices. Yet, to avoid oversized energy devices, they tolerate disruption when no power is available due to weather conditions. In this paper, we explore one step further such infrastructures by imposing disruption during non-working hours, thus following recommendations on the right to disconnect. We provided a theoretical framework that allows to size the required infrastructure (i.e. Fog nodes, solar panels, batteries) depending on a desired service uptime and a targeted carbon footprint, including the embodied carbon footprint of the infrastructure. Our simulation-based results exploiting real traces show that for such an infrastructure, wind turbines are only beneficial if the solar irradiance is very low, and only solar panels should be considered for both criteria, the uptime ratio and the embodied carbon footprint. The results also show that targeting a 95% of uptime instead of more than 99% of uptime divides the required battery and solar panel sizes by two, thus significantly improving the sustainability of the infrastructure.

Embodied carbon is only one environmental criteria and servers uptime is only one worker social protection criteria. In future work, we aim at studying other parameters (water consumption, abiotic resources depletion, etc.) among the 16 criteria of Life-Cycle Assessment. This may show that wind turbines could be beneficial for some criteria, and that battery size should be further reduced for limiting the infrastructure environmental impacts.

## ACKNOWLEDGMENTS

This work received funding from the France 2030 program, managed by the French National Research Agency under grant agreement No.
ANR-23-PECL-0003. The authors would like to thank DeuxFleurs people for sharing their usage traces and for the insightful discussions.

## REFERENCES

[1] 7solution. 2025. 7safecloud. https://7solution.ch/solutions/7safecloud. Last accessed on October 29nd, 2025.

[2] Amazon. 2025. Sustainability Report 2024. https://sustainability.aboutamazon.com/2024-amazon-sustainability-report.pdf.

[3] Rabih Bashroush. 2018. A Comprehensive Reasoning Framework for Hardware Refresh in Data Centers. *IEEE Transactions on Sustainable Computing* 3, 4 (2018), 209–220.

[4] Tega Brain, Alex Nathanson, and Benedetta Piantella. 2022. Solar protocol: Exploring energy-centered design. In *Workshop on Computing within Limits 2022. LIMITS*.

[5] Zhiwei Cao, Xin Zhou, Han Hu, Zhi Wang, and Yonggang Wen. 2022. Toward a Systematic Survey for Carbon Neutral Data Centers. *IEEE Communications Surveys & Tutorials* 24, 2 (2022), 895–936.

[6] Yue Cheng, Ali Anwar, and Xuejing Duan. 2018. Analyzing Alibaba's Co-located Datacenter Workloads. In *IEEE International Conference on Big Data (Big Data)*. 292–297.

[7] European commission. 2024. Photovoltaic Geographical Information System. https://re.jrc.ec.europa.eu/pvg_tools/en/. Last accessed on July 22nd, 2025.

[8] Cyprien de Barros. 2025. Sunflower. Your Belgian Sovereign Cloud. https://sunflower-cloud.com. Last accessed on September 2nd, 2025.

[9] Kris De Decker. 2018. How to build a low-tech website? https://solar.lowtechmagazine.com/2018/09/how-to-build-a-low-tech-website/. Last accessed on September 19th, 2025.

[10] Kris De Decker. 2018. LOW←TECH MAGAZINE This is a solar-powered website, which means it sometimes goes offline. https://solar.lowtechmagazine.com. Last accessed on September 19th, 2025.

[11] Deuxfleurs. 2021. Deuxfleurs. Fabriquons un internet convivial. https://deuxfleurs.fr. Last accessed on July 22nd, 2025.

[12] Alexandre H. T. Dias, Luiz H. A. Correia, and Neumar Malheiros. 2021. A Systematic Literature Review on Virtual Machine Consolidation. *Comput. Surveys* 54, 8 (2021).

[13] Elise Dupont, Rembrandt Koppelaar, and Hervé Jeanmart. 2018. Global available wind energy with physical and energy return on investment constraints. *Applied Energy* 209 (2018), 322–338.

[14] European Parliament. 2021. European Parliament resolution of 21 January 2021 with recommendations to the Commission on the right to disconnect (2019/2181(INL)). https://www.europarl.europa.eu/doceo/document/TA-9-2021-0021_EN.html.

[15] Xiaobo Fan, Wolf-Dietrich Weber, and Luiz André Barroso. 2007. Power provisioning for a warehouse-sized computer. In *34th International Symposium on Computer Architecture (ISCA 2007)*, June 9-13, 2007, San Diego, California, USA, Dean M. Tullsen and Brad Calder (Eds.). ACM, 13–23. https://doi.org/10.1145/1250662.1250665

[16] Blair Fix. 2024. A Tour of the Jevons Paradox: How Energy Efficiency Backfires. *Real-World Economics Review* 108 (Supplement) (2024), 40–64.

[17] Wedan Emmanuel Gnibga, Anne Blavette, and Anne-Cécile Orgerie. 2024. Renewable Energy in Data Centers: The Dilemma of Electrical Grid Dependency and Autonomy Costs. *IEEE Transactions on Sustainable Computing* 9, 3 (2024), 315–328.

[18] Inigo Goiri, William Katsak, Kien Le, Thu D. Nguyen, and Ricardo Bianchini. 2013. Parasol and GreenSwitch: managing datacenters powered by renewable energy. In *International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS)*. 51–64.

[19] Google. 2025. Environmental Report 2025. https://www.gstatic.com/gumdrop/sustainability/google-2025-environmental-report.pdf.

[20] Moritz Gutsch and Jens Leker. 2022. Global warming potential of lithium-ion battery energy storage systems: A review. *Journal of Energy Storage* 52 (2022), 105030.

[21] Moritz Gutsch and Jens Leker. 2024. Costs, carbon footprint, and environmental impacts of lithium-ion batteries–From cathode active material synthesis to cell manufacturing and recycling. *Applied energy* 353 (2024), 122132.

[22] Olivier Hamant. 2023. *Antidote au culte de la performance: la robustesse du vivant.* Gallimard.

[23] Najet Hamdi and Walid Chainbi. 2019. A survey on energy aware VM consolidation strategies. *Sustainable Computing: Informatics and Systems* 23 (2019), 80–87. https://doi.org/10.1016/j.suscom.2019.06.003

[24] IEA. 2022. Special Report on Solar PV Global Supply Chains. https://www.iea.org/reports/solar-pv-global-supply-chains. Last accessed on October 22nd, 2025.

[25] Congfeng Jiang, Yitao Qiu, Weisong Shi, Zhefeng Ge, Jiwei Wang, Shenglei Chen, Christophe Cérin, Zujie Ren, Guoyao Xu, and Jiangbin Lin. 2022. Characterizing Co-Located Workloads in Alibaba Cloud Datacenters. *IEEE Transactions on Cloud Computing* 10, 4 (2022), 2381–2397.

[26] Abee Ali Khan, Christian Reichel, Pamela Molina, Lorenz Friedrich, Dilara Maria Subasi, Holger Neuhaus, and Sebastian Nold. 2024. Global warming potential of photovoltaics with state-of-the art silicon solar cells: Influence of electricity mix, installation location and lifetime. *Solar Energy Materials and Solar Cells* 269 (2024), 112724.

[27] Yunbo Li. 2017. *Resource allocation in a Cloud partially powered by renewable energy sources*. Ph. D. Dissertation. Ecole nationale supérieure Mines-Télécom Atlantique.

[28] Minghong Lin, Adam Wierman, Lachlan LH Andrew, and Eno Thereska. 2012. Dynamic right-sizing for power-proportional data centers. *IEEE/ACM Transactions on Networking* 21, 5 (2012), 1378–1391.

[29] Huan Liu. 2011. A Measurement Study of Server Utilization in Public Clouds. In *IEEE Int. Conf. on Dependable, Autonomic and Secure Computing*. 435–442.

[30] Philippe Loubet, Adrien Vincent, Annabelle Collin, Corinne Dejous, Anthony Ghiotto, and Christophe Jego. 2023. Life cycle assessment of ICT in higher education: a comparison between desktop and single-board computers. *The International Journal of Life Cycle Assessment* 28, 3 (2023), 255–273.

[31] Sara Mcallister, Fiodar Kazhamiaka, Daniel S. Berger, Rodrigo Fonseca, Kali Frost, Aaron Ogus, Maneesh Sah, Ricardo Bianchini, George Amvrosiadis, Nathan Beckmann, and Gregory R. Ganger. 2025. A Call for Research on Storage Emissions. *SIGENERGY Energy Informatics Review* 4, 5 (2025), 67–75.

[32] Vincenzo Muteri, Maurizio Cellura, Domenico Curto, Vincenzo Franzitta, Sonia Longo, Marina Mistretta, and Maria Laura Parisi. 2020. Review on life cycle assessment of solar photovoltaic panels. *Energies* 13, 1 (2020), 252.

[33] Ernest W Peterson and Joseph P Hennessey Jr. 1978. On the use of power laws for estimates of wind power potential. *Journal of Applied Meteorology and Climatology* 17, 3 (1978), 390–394.

[34] Hugh Piggott. 2003. How to build a wind turbine. https://www.scoraigwind.com/pirate%20oldies/Hugh%20Piggott%20Axial-flow%20PMG%20wind%20turbine%20May%202003.pdf. Last accessed on October 29th, 2025.

[35] Ismael Samaye, Georges Ouffoué, and Abdoulaye Gamatié. 2025. Life Cycle Assessment of Edge Data Centers: Case Study in Presence of Renewable Energy and Refurbished Servers. *ACM Journal on Computing and Sustainable Societies* 3, 2 (2025).

[36] Navin Sharma, Sean Barker, David Irwin, and Prashant Shenoy. 2011. Blink: managing server clusters on intermittent power. In *Proceedings of the sixteenth international conference on Architectural support for programming languages and operating systems*. 185–198.

[37] Réseau Tripalium. 2023. Le Manuel "Construire une éolienne". https://www.tripalium.org/manuel. Last accessed on October 29th, 2025.

[38] Ungleich. 2019. How to run a really green datacenter. https://ungleich.ch/en-us/cms/blog/2019/06/28/how-run-really-green-datacenter. Last accessed on October 22nd, 2025.

[39] Ungleich. 2025. Data Center Light. https://datacenterlight.ch. Last accessed on October 22nd, 2025.

[40] Marta Urbane. 2023. The impact of digitalization on the working time in the EU: legal considerations of the right to disconnect. In *IEEE International Conference on Technology and Entrepreneurship (ICTE)*. 14–19.

[41] Jaylen Wang, Udit Gupta, and Akshitha Sriraman. 2023. Characterizing Datacenter Server Generations for Lifetime Extension and Carbon Reduction. In *Workshop on NetZero Carbon Computing*.

[42] Olivier Weppe, David Bekri, Thibaut Marty, Loïc Guibert, Louise Aubet, Jean-Christophe Prévotet, Maxime Pelcat, and Sebastien Rumley. 2025. Carbon Topography Representation: Improving Impacts of Data Center Lifecycle. *ACM SIGENERGY Energy Informatics Review* 5, 2 (2025), 41–47.

[43] Dunhui Yu, Jian Wang, Bo Hu, Jianxiao Liu, Xiuwei Zhang, Keqing He, and Liang-Jie Zhang. 2011. A Practical Architecture of Cloudification of Legacy Applications. In *IEEE World Congress on Services*. 17–24.

[44] Larissa Jazicek, Markus Drapalik, Iris Kral, and Wolfgang Liebert. 2023. Energy efficiency and environmental impacts of horizontal small wind turbines in Austria. *Sustainable Energy Technologies and Assessments* 59 (2023), 103411.