Konflux: Optimized Function Fusion for Serverless Applications

TL;DR

The paper tackles the problem of identifying optimal function fusion configurations for serverless applications, which is impractical to explore directly in cloud environments due to cost and scale. It introduces Konflux, a local FaaS emulation platform that brute-forces all fusion setups by representing applications as DAGs and benchmarking across resource limits, enabling cost-aware performance analysis. The study reveals that only a subset of fusion configurations are optimal and that pricing models markedly influence which configurations prevail, with instance-based pricing often yielding a single dominant pattern. The work provides open-source tooling, demonstrates substantial latency and cost improvements over unfused baselines, and offers guidance for future resource-allocation strategies and scalable fusion optimization in real-world FaaS deployments.

Abstract

Function-as-a-Service (FaaS) has become a central paradigm in serverless cloud computing, yet optimizing FaaS deployments remains challenging. Using function fusion, multiple functions can be combined into a single deployment unit, which can be used to reduce cost and latency of complex serverless applications comprising multiple functions. Even in small-scale applications, the number of possible fusion configurations is vast, making brute-force benchmarking in production both cost- and time-prohibitive. In this paper, we present a system that can analyze every possible fusion setup of complex applications. By emulating the FaaS platform, our system enables local experimentation, eliminating the need to reconfigure the live platform and significantly reducing associated cost and time. We evaluate all fusion configurations across a number of example FaaS applications and resource limits. Our results reveal that, when analyzing cost and latency trade-offs, only a limited set of fusion configurations represent optimal solutions, which are strongly influenced by the specific pricing model in use.

Figures (9)

• Figure 1: Without Function Fusion the synchronous call of Task A to Task B results in an idle time for Function 1, which is the sum of the execution duration, network latency, and warm/cold function start latency of the synchronously called Task B. With Function Fusion that idle time is used for the local execution of Task B, eliminating the need for an additional instance and the network overhead.
• Figure 2: Konflux architecture overview. The client communicates with a gateway, which forwards requests to functions running inside docker. The gateway relays control messages to a controller, which starts and stops docker instances. A centralized collector collects metrics from all components.
• Figure 3: The TREE application has a synchronous and asynchronous call chain that splits following the execution of task A. While the tasks A, B, C, and D are called synchronously with moderate computational load, the tasks E, F, and G are called asynchronous with heavy computational load.
• Figure 4: The PARALLEL-LINEAR application is initially invoked, and calls B and D asynchronously, which themselves each have another asynchronous call with their respective following functions C and E.
• Figure 5: Benchmarking results from the TREE-FG application displayed over normalized costs (according to a traditional pricing model) to normalized latency. The optimization path of the Fusionize approach with minimal resources is highlighted, demonstrating the efficiency in relation to all possible fusion group setups and the importance of optimized resource allocation.