1. Introduction
Function as a service hides servers from the programmer. Code is uploaded as small stateless functions, the platform starts instances when requests arrive, and the bill follows execution time (Baldini et al., 2017; Jonas et al., 2019). The same abstraction is now offered outside the data centre. Open-source frameworks that run on Kubernetes can be installed on gateways and micro data centres close to sensors and users, which is where the edge computing literature has long argued that latency-sensitive work belongs (Shi et al., 2016).
A deployment that spans edge and cloud is heterogeneous in every respect that matters for energy. An ARM single-board computer draws a few watts and executes a function slowly. A cloud server draws two orders of magnitude more, finishes sooner, and shares its idle power among many tenants. Between them lies a wireless or wide-area link whose use costs energy at both ends. A scheduler that ignores these differences can meet every latency target and still waste most of the energy it spends.
This article proposes a scheduler design that treats energy as the quantity to be minimised and latency as a constraint, together with a protocol for testing such a scheduler fairly. It is a methodological contribution. No prototype has been built and no measurements are reported; the claims made are about how the problem should be structured and what evidence would settle whether the design works.
2. Background
Three bodies of work supply the parts of the design: studies of how serverless platforms behave, the energy literature on servers and data centres, and research on offloading between devices, edge and cloud.
2.1. Serverless execution and where its energy goes
A function invocation is served either by a warm instance that is already loaded or by a cold start, in which a sandbox is created, the runtime is initialised and the code is fetched. Measurement studies of commercial platforms found cold starts to be slow and variable and showed that providers keep idle instances alive for minutes to avoid them (Wang et al., 2018). Lightweight virtual machine monitors such as Firecracker shortened sandbox creation considerably (Agache et al., 2020), but runtime and dependency loading remain. A production trace analysis by Shahrad et al. (2020) showed that most functions are invoked rarely, so a fixed keep-alive window holds memory for instances that are seldom reused, and it proposed windows adapted to each function's invocation pattern. Warm instances are not free in energy terms: they occupy memory and prevent the host from being consolidated or put into a low-power state.
2.2. Power behaviour of servers and small devices
Barroso and Hölzle (2007) observed that servers draw a large share of their peak power when idle and argued for energy-proportional machines. Fan et al. (2007) showed that a simple model, idle power plus a term that grows with processor utilisation, predicts the power of a server well enough for provisioning. These two results explain why consolidation saves energy in data centres and underlie the allocation heuristics of Beloglazov et al. (2012), which pack virtual machines onto few hosts and switch the others off. Frequency scaling, the other classical lever, yields less on recent hardware than it once did because static power has grown relative to dynamic power (Le Sueur and Heiser, 2010). Small edge boards behave differently: their idle power is low in absolute terms, but so is their throughput, and energy per request depends strongly on the workload.
2.3. Offloading and metering
The mobile edge computing literature frames offloading as a comparison between the energy of computing locally and the energy of transmitting the input and waiting for the answer, subject to a delay bound (Mao et al., 2017). The same comparison applies to a function that could run on the gateway where its trigger arrives or on a distant server. Applying it needs measurements. On Intel processors the running average power limit interface exposes energy counters for the package and memory (David et al., 2010), and models built on utilisation counters can apportion host power among co-located tenants (Kansal et al., 2010). Boards without such counters must be metered externally at the supply.
3. The Proposed Scheduler
The scheduler is conceived as an extension of the placement component of a Kubernetes-based function platform, since Kubernetes is the common substrate of edge and cloud clusters (Burns et al., 2016). It consists of four components, summarised in Table 1, that operate in a loop around every invocation.
| Component | Input | Output | Basis |
|---|---|---|---|
| Node power model | Idle power, peak power, current utilisation of each node | Marginal power of adding one invocation | Fan et al., 2007 |
| Function profile | Past execution times and payload sizes per hardware class | Expected duration and transfer volume | Shahrad et al., 2020 |
| Transfer cost estimate | Link type and payload size between trigger and node | Energy of moving input and result | Mao et al., 2017 |
| Placement rule | Energy estimates and latency deadline | Chosen node for the invocation | Beloglazov et al., 2012 |
| Keep-alive policy | Inter-arrival history, standby power, cold-start energy | Time to retain a warm instance | Shahrad et al., 2020 |
| Metering feedback | Counter or supply readings after execution | Corrected profile and model parameters | Kansal et al., 2010 |
3.1. Node power model
Each node is described by its idle power, its power at full load and a utilisation-to-power curve fitted once during commissioning. The quantity the scheduler needs is marginal: the additional energy the node will draw if it accepts one more invocation. On a node that is already active this is the dynamic power attributable to the function multiplied by its expected duration. On a node that would otherwise be idle or asleep, the cost of waking it and keeping it awake must be added. Charging idle power only to the invocation that causes it is what steers work towards machines that are already busy, the serverless analogue of consolidation.
3.2. Function profiles
For every function the scheduler keeps, per class of hardware, a running summary of execution time, memory footprint, input and output size, and cold-start duration. New functions have no history, so their first invocations are spread across hardware classes deliberately to populate the profile. Profiles are keyed by function version, since a new deployment can change behaviour completely, and they are updated after each execution from the metering feedback described below.
3.3. Placement rule
When a request arrives, the scheduler lists the nodes that hold or can start an instance of the function. For each it estimates completion time as queueing delay plus cold-start time, if no warm instance exists, plus execution and transfer time. Nodes whose estimate exceeds the function's deadline are discarded. For the remainder it estimates energy as the sum of marginal compute energy, cold-start energy where applicable, and transfer energy at both ends of the link. The request goes to the node with the lowest estimate. If no node meets the deadline, the fastest is chosen and the violation is logged. The rule is greedy and local by design: it runs on the request path and must cost far less than the function it places.
Figure 1 shows the loop formed by these steps. Its final arc matters as much as the decision itself, because the estimates are only as good as the profiles and power curves behind them.
3.4. Keep-alive policy
After an invocation completes, the instance may be retained. Retaining it costs standby energy, which is the memory it pins plus any share of idle power it prevents the node from shedding. Releasing it risks a cold start whose energy is known from the profile. The policy keeps the instance for as long as the expected cold-start energy avoided, given the function's observed inter-arrival distribution, exceeds the standby energy spent. This is the histogram-based idea of Shahrad et al. (2020) with energy substituted for memory as the cost. On a battery or solar-powered edge node the standby term is weighted more heavily than on a mains-powered server.
4. Evaluation Protocol
A scheduler of this kind is easy to make look good against a weak baseline or a favourable workload. The protocol below is intended to prevent that, and follows the general discipline of experimental design for computer systems set out by Jain (1991).
The testbed should contain at least three hardware classes, for example an ARM board, a small x86 edge server and a cloud-class server, joined by links whose bandwidth and delay are controlled. Workloads should combine a published function benchmark suite such as SeBS (Copik et al., 2021), which covers compute-bound, input-output-bound and multimedia functions, with invocation patterns replayed from a public production trace so that the mix of frequent and rare functions is realistic. Synthetic constant-rate load alone is not sufficient, since keep-alive policies are trivial under it.
Four baselines are needed: the platform's default scheduler; a latency-greedy policy that always picks the fastest node; a cloud-only and an edge-only placement; and the proposed placement rule with a fixed keep-alive window, which isolates the contribution of the adaptive policy. Energy should be metered for whole nodes at the supply, with on-chip counters used as a cross-check where available, and the energy of network equipment should be either measured or declared out of scope.
Results should be reported as energy per successful invocation alongside the tail of the latency distribution and the fraction of deadlines missed, never as energy alone. Each configuration should be repeated enough times to give confidence intervals, and the trace, function code, power curves and scheduler configuration should be published with the results. Where the carbon intensity of the supply differs between sites or over time, a second analysis may weight energy by carbon, in the manner explored for delay-tolerant cloud workloads by Wiesner et al. (2021).
5. Limitations and What Remains to Be Shown
The design has not been implemented, and several of its assumptions could fail in practice. The power model assumes that the energy of co-located functions adds up, which interference in caches and memory bandwidth can violate. The profiles assume that past executions predict future ones, which holds poorly for functions whose running time depends on their input. The greedy rule ignores the effect of one placement on later ones and may fragment load across nodes that a global optimiser would have emptied. Whether these simplifications cost much energy is exactly what the evaluation protocol is meant to reveal.
The serverless model also limits what any scheduler can do. Functions that exchange large state through remote storage spend their energy on data movement however well they are placed, a structural weakness of the model identified by Hellerstein et al. (2019). Finally, the protocol measures operational energy only. Manufacturing energy of edge hardware, cooling overheads and the energy of the wider network fall outside it and should be acknowledged as such in any report that uses it.
6. Conclusion
Energy-aware scheduling of serverless functions across edge and cloud can be built from results that are individually well established: additive power models, per-function profiles, the offloading comparison and adaptive keep-alive. This article has combined them into a scheduler design that minimises estimated energy under a latency deadline and has specified how such a design should be tested. The design remains a proposal until it is implemented and measured, and the protocol is offered so that this can be done in a form others can check.
Conflict of interest
To be declared by the author(s) before publication.
Funding
To be declared by the author(s) before publication.