GeoFaaS: An Edge-to-Cloud FaaS Platform

TL;DR

GeoFaaS tackles the lack of geographical context in edge-to-cloud FaaS by introducing a geo-aware, decentralized architecture that routes function requests to the nearest available node according to client location. The system combines a distributed GeoBroker-based DisGB, per-node FaaS servers (defaulting to tinyFaaS), and a GeoFaaS Bridge to enable transparent edge processing and cloud offloading when needed. The authors implement an open-source PoC in Kotlin and validate it through three experiments focusing on distance/latency, high-load offloading, and outage resilience, demonstrating low latency for edge nodes and robust offloading to the cloud under overload or failure. The work offers practical benefits for distributed serverless deployments by reducing network traffic and latency while maintaining fault tolerance, with future work on optimized function placement and server-selection policies.

Abstract

The massive growth of mobile and IoT devices demands geographically distributed computing systems for optimal performance, privacy, and scalability. However, existing edge-to-cloud serverless platforms lack location awareness, resulting in inefficient network usage and increased latency. In this paper, we propose GeoFaaS, a novel edge-to-cloud Function-as-a-Service (FaaS) platform that leverages real-time client location information for transparent request execution on the nearest available FaaS node. If needed, GeoFaaS transparently offloads requests to the cloud when edge resources are overloaded, thus, ensuring consistent execution without user intervention. GeoFaaS has a modular and decentralized architecture: building on the single-node FaaS system tinyFaaS, GeoFaaS works as a stand-alone edge-to-cloud FaaS platform but can also integrate and act as a routing layer for existing FaaS services, e.g., in the cloud. To evaluate our approach, we implemented an open-source proof-of-concept prototype and studied performance and fault-tolerance behavior in experiments.

Figures (6)

• Figure 1: The GeoFaaS system with two GeoFaaS nodes deployed on edge and one node deployed on the cloud. The Client at time $t_0$ is outside of edge service areas, so it communicates with cloud. When client moves to a new service area at $t_1$, the cloud node will hand off the client to a new node for further communication by its last responsible node.
• Figure 2: The GeoFaaS node architecture comprises three key components: GeoBroker, which enables location-aware pub/sub messaging, a local FaaS server and/or FaaS services running on external servers within the same data center, and the GeoFaaS Bridge, a middleware between the other components.
• Figure 3: Used service areas for edge brokers in experiments, illustrating client movement as described in section \ref{['subsubsec:distance']}.
• Figure 4: Each client's movement is followed by a function call, with response latencies plotted in blue (ms). The red line shows client-to-server distance (km), and vertical lines indicate switching to a new GeoFaaS node based on location updates. The client's movement is illustrated in \ref{['img:exp-map']}.
• Figure 5: Breakdown of processed requests: Edge responses ("Normal") and cloud responses ("Offload") across various number of parallel clients.