Provuse: Platform-Side Function Fusion for Performance and Efficiency in FaaS Environments

This paper introduces Provuse, a transparent platform-side optimization for FaaS environments that automatically fuses independently deployed functions at runtime to eliminate redundant instances, thereby reducing end-to-end latency by an average of 26.33% and RAM usage by 53.57% without requiring any code changes from developers.

The Gist

Imagine you run a busy coffee shop called "Serverless Cafe."

In this cafe, customers (your apps) don't order a full meal at once. Instead, they order tiny, specific tasks: "Make me a latte," "Toast a bagel," "Chop some fruit." Each task is handled by a different, specialized barista (a Function).

The Problem: The "Double Billing" Chaos

Currently, here is how the cafe works:

1. A customer orders a Latte.
2. The Latte Barista makes the coffee.
3. But wait! The Latte Barista realizes they need Milk from the Milk Barista to finish the order.
4. The Latte Barista stops, calls the Milk Barista, waits for them to wake up, make the milk, and hand it over.
5. The Latte Barista then finishes the drink.

The Catch:

• Double Billing: You have to pay the Latte Barista for the whole time they are standing there waiting. You also have to pay the Milk Barista to wake up, make the milk, and go back to sleep. You are paying for two people to do a job that could be done by one.
• Slow Service: The customer has to wait for the Latte Barista to call the Milk Barista, wait for the Milk Barista to wake up, and then wait for the Latte Barista to finish. It's like sending a letter back and forth instead of just handing the ingredients to the person next to you.

This is the problem with FaaS (Function-as-a-Service) in the real world. When one piece of code calls another, it creates delays and wastes money because the system treats them as two separate, expensive events.

The Solution: Provuse (The "Smart Manager")

The paper introduces a new system called Provuse. Think of Provuse as a super-smart, invisible manager who watches the whole kitchen.

Instead of letting the baristas call each other across the room, Provuse notices a pattern: "Hey, the Latte Barista calls the Milk Barista 100 times a day. That's inefficient!"

What Provuse does:

1. The Merge: It quietly takes the Latte Barista and the Milk Barista and combines them into one super-barista.
2. The Fusion: This new super-barista has both the coffee machine and the milk steamer right next to each other. They don't need to call anyone; they just grab the milk and pour it instantly.
3. The Magic: The customer doesn't know anything changed. They still order a "Latte." But behind the scenes, the "Latte" and "Milk" tasks are now happening in the same person's hands, instantly.

How It Works (The "How-To")

The paper explains that Provuse doesn't ask the developers (the cafe owners) to rewrite their recipes. It happens automatically at the platform level (the cafe's management system).

• Watching the Phones: The system watches the "phones" (network connections) the baristas use. If it sees a barista picking up the phone to call another barista and waiting for an answer, it knows, "Aha! These two should be fused."
• The Construction Crew: A special tool (called the Merger) takes the two separate "kitchen stations" (containers), combines their tools and ingredients into one big station, and builds a new, faster workflow.
• The Switch: Once the new super-barista is ready, the system quietly switches the customers to them and sends the old, separate baristas home to save money.

The Results: Faster and Cheaper

The researchers tested this in two different types of cafes (a small edge cafe called tinyFaaS and a giant corporate kitchen called Kubernetes).

• Speed: The coffee was served 26% faster on average. The "waiting for the phone call" time was eliminated.
• Money: They used 53% less RAM (memory). Instead of paying for two baristas to be awake and ready, they only paid for one super-barista.
• No Code Changes: The best part? The developers didn't have to change a single line of code. The optimization happened automatically by the platform.

The Catch (Limitations)

Just like any good system, there are a few rules:

1. Trust: You can only fuse baristas who work for the same company. You wouldn't want to merge a rival coffee shop's barista into your kitchen (security risk).
2. Asynchronous Orders: If a barista just shouts "Make milk!" and keeps working without waiting for the answer, fusing them doesn't help much. This works best when one task immediately needs the result of another.
3. Language: Right now, this specific prototype mostly works with Python code (like a specific type of coffee bean), but the idea can be expanded to other languages later.

The Big Picture

Provuse is like a traffic cop for the cloud. It sees that cars (functions) are stopping at every intersection to talk to each other, causing traffic jams and wasting gas. So, it builds a tunnel that connects the two destinations directly.

The result? Your apps run faster, your cloud bill goes down, and you don't have to do any extra work to get there. It's a win for everyone except the "double billing" problem, which finally gets fired.

Technical Summary

Here is a detailed technical summary of the paper "Provuse: Platform-Side Function Fusion for Performance and Efficiency in FaaS Environments."

1. Problem Statement

Function-as-a-Service (FaaS) offers scalable, cost-efficient cloud execution but suffers from significant overheads in complex, multi-function applications. The primary issues addressed are:

• Double Billing: In synchronous workflows where one function calls another, users are billed for the execution time of both functions, including the idle wait time during the remote invocation.
• Latency and Resource Overhead: Every inter-function call incurs network latency, scheduling overhead, and the cost of initializing a new execution environment (cold starts or context switching).
• Developer Burden: Existing optimization techniques often require developers to manually refactor code, use specific annotations, or manage complex deployment configurations to merge functions, which contradicts the "serverless" abstraction.

2. Methodology: Provuse

The authors propose Provuse, a transparent, platform-side optimization framework that automatically fuses independently deployed functions at runtime without requiring code changes from the user.

Core Architecture

Provuse operates on provider-managed FaaS platforms where the provider controls the entry points and deployment artifacts. It introduces two tightly coupled components:

1. Function Handler:
   • Deployed alongside function code.
   • Monitors outbound socket connections from function instances.
   • Detects synchronous communication (blocking calls) where a function waits for a response from another function within the same platform.
   • Triggers the fusion process by sending a request to the Merger with relevant identifiers (function names, IPs, ports).
2. Merger:
   • Receives fusion requests and orchestrates the consolidation.
   • Process: It extracts the file systems of the two active function containers, merges them into a unified file system, and builds a new container image.
   • Conflict Resolution: It preserves original function identifiers to prevent file overwrites when merging code.
   • Deployment: Deploys the new combined container, routes traffic to it, and terminates the original separate containers once the new instance is healthy.

Implementation Details

• Languages: The Function Handler is implemented in Python, while the Merger is implemented in Rust for efficiency.
• Platforms: The system was implemented and tested on two distinct environments:
  • tinyFaaS: A lightweight, edge-oriented FaaS platform.
  • Kubernetes: A standard container orchestration framework (used as a basis for platforms like Knative).
• Transparency: The fusion logic is entirely invisible to the developer. The platform handles the detection, merging, and traffic redirection automatically.

3. Key Contributions

• Platform-Side Automation: Unlike previous work that relied on application-side annotations or static analysis, Provuse performs fusion dynamically at runtime based on actual invocation patterns.
• Dual-Environment Validation: The approach is demonstrated to be compatible with both lightweight edge runtimes (tinyFaaS) and complex cloud orchestration systems (Kubernetes).
• Elimination of Double Billing: By inlining function calls within a single execution unit, the system removes the redundant billing associated with synchronous inter-function communication.
• Language Agnosticism: While the prototype currently supports Python, the underlying mechanism (socket monitoring and container merging) is language-agnostic.

4. Experimental Results

The authors evaluated Provuse using two benchmark applications (TREE and IOT) across both tinyFaaS and Kubernetes environments, comparing a "Vanilla" deployment against the "Function Fusion" deployment.

Key Metrics:

• Latency Reduction:
  • Average Improvement: 26.33% reduction in end-to-end median latency across all benchmarks.
  • Specifics:
    • IOT on tinyFaaS: Reduced from 807ms to 574ms (28.9% improvement).
    • IOT on Kubernetes: Reduced from 815ms to 551ms (32.4% improvement).
    • TREE on tinyFaaS: Reduced from 452ms to 350ms (22.6% improvement).
• Resource Efficiency (RAM):
  • Average Improvement: 53.57% reduction in mean RAM usage.
  • Specifics:
    • IOT: ~57% reduction in RAM.
    • TREE: ~50% reduction in RAM.
• Stability: The results showed consistent improvements with stable latency distributions, proving that the fusion process does not introduce volatility.

5. Significance and Future Work

Significance:

• Transparent Optimization: Provuse proves that infrastructure-level optimizations can yield substantial performance and cost gains without altering developer workflows.
• Cost Efficiency: It directly addresses the economic inefficiency of "double billing" in serverless workflows, making composed FaaS applications more viable for production.
• Scalability: The ability to reduce the number of concurrent function instances lowers the overall resource footprint of the platform.

Limitations & Future Directions:

• Trust Domain: Fusion requires functions to be in the same trust domain (same user/account) due to the reduced isolation of colocating code.
• Workload Suitability: Applications that are already highly asynchronous or non-blocking may see limited benefits, as the optimization targets synchronous blocking calls.
• Container Support: The current prototype supports "bring-your-own-function-code" but not "bring-your-own-container." Future work aims to support hybrid models where user-defined containers can still be optimized by the platform.
• Language Support: While the design is agnostic, the current prototype is limited to Python; extending this to other languages is a straightforward next step.

In conclusion, Provuse demonstrates that automatic, platform-side function fusion is a highly effective strategy for reducing latency and resource consumption in serverless systems, offering a path toward more efficient and cost-effective FaaS environments.