Serverless computing started in the cloud, but it’s not staying there. A recent special issue in Ad Hoc Networks explores how researchers are combining edge computing with serverless architectures, and the results suggest we’re about to see a fundamental shift in how distributed applications work.
The research, led by teams from institutions across India, Australia, and the United States, focuses on ad hoc networks—those temporary, decentralized networks that pop up in disaster zones, remote areas, or anywhere traditional infrastructure fails. These environments need real-time responsiveness, but they can’t rely on distant cloud servers to provide it.
The Latency Problem
Traditional serverless functions run in centralized data centers. When you invoke an AWS Lambda function, your request travels to the nearest AWS region, gets processed, and returns. That round trip might take 50-200 milliseconds depending on your location. For many applications, this latency is perfectly acceptable.
But consider emergency response scenarios. First responders coordinating rescue operations can’t wait for data to travel hundreds of miles to a cloud server and back. Industrial IoT systems monitoring critical equipment need millisecond response times. Autonomous vehicles making split-second decisions certainly can’t afford cloud round trips.
The research highlights this fundamental tension: serverless offers incredible scalability and operational simplicity, but centralized execution creates latency bottlenecks that make it unsuitable for time-sensitive applications.
Edge-Native Functions
The proposed solution moves serverless execution to the network edge. Instead of functions running in distant data centers, they execute on edge servers, cellular base stations, or even powerful edge devices close to where the data originates.
This isn’t just about deploying existing serverless platforms closer to users. The researchers describe “edge-native” functions designed specifically for edge environments. These functions must handle resource constraints, intermittent connectivity, and the dynamic nature of edge infrastructure.
Unlike cloud functions that assume abundant resources and reliable connectivity, edge-native functions need to be efficient by design. They must gracefully handle situations where the edge node they’re running on suddenly loses connectivity or gets overwhelmed by local demand.
Ad Hoc Network Applications
The research focuses particularly on ad hoc networks because they represent an extreme test case for edge-native serverless. In disaster response, temporary networks might consist of drones, satellite uplinks, and portable base stations that constantly change topology as rescue teams move through affected areas.
Traditional approaches to this problem involve pre-deploying applications on all possible devices or relying on centralized coordination that becomes a single point of failure. Edge-native serverless offers a third option: functions that can migrate between edge nodes as network conditions change, automatically placing computation where it’s most needed.
The researchers describe scenarios where functions for routing optimization, resource allocation, and coordination tasks move dynamically through the ad hoc network, always executing close to the data they need to process.
Commercial Reality Check
While the academic research explores extreme scenarios, commercial edge serverless platforms are already emerging. Cloudflare Workers runs JavaScript functions at edge locations worldwide. Fastly’s Compute@Edge offers similar capabilities. AWS Lambda@Edge and Azure Functions on IoT Edge bring serverless to content delivery networks and IoT deployments.
These platforms typically focus on simpler use cases than the academic research: content personalization, API optimization, and basic request processing. But they’re proving that edge-native serverless can work at scale with real production workloads.
The commercial platforms also reveal practical constraints the research must address. Edge nodes have limited storage and compute capacity compared to cloud data centers. Network partitions are common. Debugging distributed edge functions is significantly more complex than troubleshooting centralized cloud functions.
Orchestration Challenges
Perhaps the most complex aspect of edge-native serverless is orchestration. Cloud serverless platforms like AWS Lambda can rely on sophisticated backend systems for function scheduling, resource management, and monitoring. At the edge, these orchestration systems must be distributed and resilient to network failures.
The research proposes several approaches to edge function orchestration. One involves hierarchical coordination where regional controllers manage clusters of edge nodes. Another uses peer-to-peer protocols where edge nodes coordinate directly without centralized control.
Both approaches face trade-offs between coordination overhead and system resilience. More coordination means better resource utilization but higher network overhead and more failure points. Less coordination reduces complexity but can lead to suboptimal function placement and resource usage.
Security at the Edge
Edge environments complicate security models significantly. Cloud serverless platforms benefit from the physical and network security of major data centers. Edge nodes often run in less controlled environments with limited security infrastructure.
The researchers note that edge-native functions need new security approaches. Traditional perimeter-based security doesn’t work when functions might execute on temporary nodes with unknown trust levels. The research suggests using function-level security, cryptographic attestation, and dynamic trust models based on node behavior and network conditions.
This security complexity represents one of the biggest barriers to widespread edge serverless adoption. Organizations comfortable deploying functions to AWS Lambda might hesitate to run the same code on edge nodes they don’t directly control.
Performance Reality
The research includes performance analysis showing significant latency improvements for edge-native functions compared to cloud-based execution. In their test scenarios, edge functions reduced response times by 60-80% compared to traditional cloud serverless.
However, these improvements come with caveats. Edge nodes typically have less computational power than cloud servers, so CPU-intensive functions might actually run slower at the edge despite the reduced network latency. The optimal deployment strategy depends on whether an application is latency-bound or compute-bound.
The research also reveals that edge function performance varies significantly based on edge node capabilities and network conditions. This variability makes performance prediction and SLA management much more challenging than with cloud serverless platforms.
The Path Forward
Edge-native serverless isn’t ready to replace cloud functions for most applications. The orchestration complexity, security challenges, and performance variability make it suitable primarily for specific use cases where latency is critical and the application can handle the distributed system complexity.
But the research suggests this will change as edge infrastructure matures. 5G networks, edge computing platforms, and improved orchestration systems are making edge-native serverless more practical for mainstream applications.
The academic research serves as a roadmap for what becomes possible when serverless computing breaks free from centralized data centers. As edge infrastructure improves and orchestration systems mature, we’ll likely see more applications that simply couldn’t exist with cloud-only serverless architectures.
For now, edge-native serverless represents an important evolution in distributed computing. It’s pushing serverless beyond the cloud and into environments where real-time responsiveness matters more than infinite scalability. That shift might redefine what we expect from serverless computing entirely.