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.

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.

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.

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).

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.

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.

To be declared by the author(s) before publication.

To be declared by the author(s) before publication.