Advancing Serverless Workﬂow Efﬁciency: Integrating Functional

Programming Constructs and DAG-Based Execution

Nimr

od F

oldv

ari

and Florin Cr

aciun

Faculty of Mathematics and Computer Science, Babes-Bolyai University, Cluj-Napoca, Romania

Keywords:

Serverless Computing, Workﬂow Optimization, Directed Acyclic Graphs, Partial Execution, Function

Orchestration, Cold Start.

Abstract:

Serverless computing, also known as the Function-as-a-Service (FaaS) paradigm, has become a cornerstone of

modern cloud-based applications, enabling developers to build and execute workﬂows by composing server-

less functions. However, current serverless platforms are limited by constrained orchestration and function

composition capabilities, which reduce their expressiveness and performance. To address these limitations,

this paper introduces three enhancements to Apache OpenWhisk: native support for currying, continuation,

and Directed Acyclic Graphs (DAGs). These enhancements are designed to improve the expressiveness of

serverless workﬂows, reduce latency, and enable partial execution of dynamic workﬂows as soon as data be-

comes available.

1 INTRODUCTION

Serverless computing has become a popular paradigm

for building and deploying native cloud applica-

tions. With serverless, developers can focus solely

on writing code without worrying about provision-

ing or managing servers (Jonas et al., 2019). Cloud

providers such as AWS Lambda, Azure Functions,

and Google Cloud Functions handle all the infrastruc-

ture management and scaling automatically.

One of the key advantages of serverless comput-

ing is its cost effectiveness. Users only pay for the

computation time their code is running, down to the

millisecond. However, serverless architecture also

faces notable performance bottlenecks, the cold start

problem being the most signiﬁcant.

When a serverless function is invoked for the ﬁrst

time after a period of inactivity, or when the cloud

provider scales out new instances, there is a delay

in launching the execution environment. This delay,

known as a cold start, can range from a few millisec-

onds to several seconds, depending on various factors

such as the language runtime, function package size,

and the chosen cloud provider platform (Lin and Glik-

son, 2019).

The cold start latency can become a signiﬁcant

https://orcid.org/0009-0008-3531-0478

https://orcid.org/0000-0003-0335-8369

performance bottleneck in complex serverless work-

ﬂows involving multiple chained functions (Shahrad

et al., 2020). If a workﬂow consists of multiple

functions, each experiencing a cold start, the cumu-

lative latency can be substantial, leading to a poor

user experience (Jonas et al., 2019). Equation (1)

shows the total duration of such a serverless work-

ﬂow, where n is the number of functions in the work-

ﬂow, Cold Start

is the cold start latency for the i

function, and Exec Time

is the execution time of the

function.

workﬂow duration

∑

i=1

Cold Start

∑

i=1

Exec Time

(1)

Addressing the cold start problem is crucial for en-

suring reliable and efﬁcient serverless workﬂows, as it

can signiﬁcantly impact the overall performance and

user experience of serverless applications. It is essen-

tial to ﬁnd other orchestration possibilities beyond the

existing solutions, with the aim of improving server-

less workﬂows and reducing latency time.

We present an expressive orchestration language

for controlling function scheduling and composition.

To maximize scheduling optimization opportunities,

we propose that this language be interpreted directly

by OpenWhisk’s scheduler. Additionally, we intro-

duce a function composition style inspired by con-

cepts such as currying and continuation — functional

Földvári, N. and Cr

aciun, F.

Advancing Serverless Workﬂow Efﬁciency: Integrating Functional Programming Constructs and DAG-Based Execution.

DOI: 10.5220/0013428200003950

In Proceedings of the 15th International Conference on Cloud Computing and Services Science (CLOSER 2025), pages 239-246

ISBN: 978-989-758-747-4; ISSN: 2184-5042

239

constructs designed to be intuitive and familiar to de-

velopers.

The rest of this paper is organized into the follow-

ing sections. In 2, we discuss challenges in serverless

workﬂow orchestration, other approaches to orches-

tration and function composition, and present our mo-

tivation for enhancement in Apache OpenWhisk. In 3

we describe our enhancements, explaining the neces-

sity of their introduction and illustrating them with

examples. In 4, we present how our approach fulﬁlls

the serverless trilemma (Baldini et al., 2017b) and a

preliminary evaluation of our prototype, demonstrat-

ing its beneﬁts and performance improvements. In 5,

we discuss limitations and future research directions,

and ﬁnally conclude in 6.

2 BACKGROUND AND RELATED

WORK

Serverless computing has gained traction as a

paradigm that abstracts infrastructure management,

allowing developers to focus on application logic.

However, existing serverless platforms face limita-

tions in workﬂow orchestration, particularly in modu-

larity, latency optimization, and managing complex

dependencies. Addressing these shortcomings re-

quires introducing features such as currying, contin-

uation, and Directed Acyclic Graph (DAG) execu-

tion. The DAG should be described using a domain-

speciﬁc language (DSL) that allows a programmer to

deﬁne the relationships between the inputs and out-

puts of multiple serverless functions in a workﬂow.

This DSL would be interpreted directly by the server-

less platform. Additionally, native support for curry-

ing and continuation is also lacking in current solu-

tions. This section explores relevant works and their

limitations, highlighting the need for these enhance-

ments.

2.1 Challenges in Serverless Workﬂow

Orchestration

Traditional serverless platforms primarily rely on

control-ﬂow orchestration, where workﬂows are ex-

ecuted sequentially based on predeﬁned dependen-

cies (Baldini et al., 2017b). While straightforward,

this approach struggles with complex workﬂows and

lacks constructs for modularization, reuse, and dy-

namic task suspension and resumption, leading to in-

efﬁciencies in parallel task execution and increased

latency.

2.2 Advancements in Serverless

Orchestration

Recent research efforts, such as DataFlower,

Pheromone, Triggerﬂow, DFlow, DAGit, and

Wukong, have introduced innovative paradigms to

overcome the limitations of traditional serverless or-

chestration. However, these approaches exhibit trade-

offs in expressiveness, dependency management, and

workﬂow composition, particularly in their support

for DAG execution, currying, continuation, and lan-

guage ﬂexibility—key features of our proposed solu-

tion. Below, we analyze key platforms and frame-

works, highlighting their strengths and limitations in

relation to our proposed enhancements (DAGs, curry-

ing, and continuation). Table 1 summarizes this com-

parison.

DataFlower (Li et al., 2024) adopts a decentral-

ized data-ﬂow approach, where workﬂows are rep-

resented as dynamic data-ﬂow graphs. It decou-

ples computation and communication using Function

Logic Units (FLUs) and Data Logic Units (DLUs),

enabling overlapping computation and data transfer

to improve throughput. This model is particularly ef-

fective for large-scale workﬂows, where overlapping

operations can signiﬁcantly reduce latency. How-

ever, while DataFlower’s decentralized architecture

improves parallelism, it introduces complexity due to

the need for separate Function Logic Units (FLUs)

and Data Logic Units (DLUs), which require explicit

coordination between computation and communica-

tion components. Notably, it lacks native support

for functional constructs like currying, limiting incre-

mental processing of partial data.

Pheromone (Yu et al., 2022), on the other hand, in-

troduces a data-centric approach by using data buck-

ets to trigger functions based on data availability. This

paradigm simpliﬁes orchestration and reduces latency

through shared-memory object stores for rapid data

exchange. However, while Pheromone signiﬁcantly

enhances performance with its data-centric design,

it currently supports only C++ functions, limiting

language ﬂexibility, and its optimization for data-

centric workﬂows may reduce effectiveness for purely

function-driven applications. Continuation mecha-

nisms are absent, forcing workﬂows to remain active

during idle periods.

Triggerﬂow (Garc

ıa-L

opez et al., 2020) presents

an extensible trigger-based orchestration architecture

for serverless workﬂows. It enables the construction

of reactive orchestrators like state machines and di-

rected acyclic graphs (DAGs). Triggerﬂow focuses on

event-driven mechanisms and enhances orchestration

efﬁciency by allowing reactive triggers to optimize la-

CLOSER 2025 - 15th International Conference on Cloud Computing and Services Science

240

Table 1: Feature comparison of serverless orchestration platforms.

Platform DAG Support Currying Continuation Language

Flexibility

Mitigates

Double

Spending

DataFlower Partial No No Medium Partial

Pheromone No No No Low (C++ only) No

Triggerﬂow Yes No No High Partial

DFlow Partial No No High Partial

DAGit Native No No Medium No

Wukong No No No High Partial

Proposed Solution Native Yes Yes High Yes

tency and resource utilization. Despite its ﬂexibility,

it does not support partial execution or incremental

data processing, leading to inefﬁciencies in workﬂows

with dynamic dependencies.

DFlow (Shi et al., 2023) introduces a dataﬂow-

based serverless workﬂow system aimed at reducing

end-to-end execution time by enabling partial execu-

tion of tasks based on data availability. DFlow em-

phasizes dynamic scheduling and parallel task invo-

cation, aligning with the goals of currying and con-

tinuation by allowing functions to execute incremen-

tally based on data readiness. However, DFlow fo-

cuses on dataﬂow orchestration rather than leveraging

functional programming constructs like currying and

continuation for modularizing and reusing workﬂow

components.

DAGit (Jana et al., 2023) is an open-source

platform designed to streamline serverless applica-

tion development through native support for Directed

Acyclic Graphs (DAGs). It provides a declarative

framework for deﬁning workﬂows as DAGs, enabling

developers to express complex dependencies, paral-

lel execution, and conditional logic. Unlike platforms

that rely on external orchestration layers, DAGit inte-

grates DAG execution directly into its runtime, opti-

mizing task scheduling and reducing overhead.

Wukong (Fouladi et al., 2019) addresses server-

less workﬂow inefﬁciencies by optimizing parallelism

and locality-aware scheduling. Its architecture maps

workﬂows to distributed systems, leveraging ﬁne-

grained task partitioning and data locality to minimize

latency. Wukong achieves signiﬁcant performance

improvements for parallel workloads, such as linear

algebra operations, by reducing cross-node commu-

nication and prioritizing colocated tasks.

A critical gap in existing platforms is their inefﬁ-

ciency in handling double spending, where workﬂows

incur costs from idle resources (e.g., waiting for de-

pendencies) or redundant invocations, as discussed in

(Kratzke, 2021; Baldini et al., 2017a). For instance,

DAGit’s inability to suspend workﬂows during delays

results in unnecessary billing, while Pheromone’s

lack of continuation forces full recomputation after

interruptions.

Our proposal mitigates this through:

• Currying: Enables incremental execution, reduc-

ing redundant calls by processing available data

immediately.

• Continuation: Suspends workﬂows during idle

periods, freeing resources and avoiding costs for

inactive states.

• DAG Execution: Optimizes parallelism and re-

source reuse, minimizing idle time.

By addressing these gaps, our enhancements po-

sition Apache OpenWhisk as a versatile platform ca-

pable of supporting modern, cost-efﬁcient workﬂows

while advancing the state of the art in serverless com-

puting.

2.3 Motivation for Enhancements in

Apache OpenWhisk

Apache OpenWhisk was chosen as it is an open-

source platform, which allows for modifying the

source code to implement these enhancements. The

insights from platforms like DataFlower, Pheromone,

and other research efforts underscore the need for

foundational improvements in serverless platforms.

The integration of currying would enable developers

to modularize workﬂows, reducing redundancy and

promoting reuse. Additionally, currying would help

reduce latency by allowing partial execution of avail-

able data, improving efﬁciency and responsiveness

in complex workﬂows. Incorporating continuation

mechanisms would allow workﬂows to pause and re-

sume as needed, minimizing latency caused by depen-

dencies or delays. Finally, the addition of DAG-based

execution would provide a powerful framework for

representing and managing complex workﬂows, al-

lowing parallel execution, partial recomputation, and

optimized resource utilization.

By addressing these gaps, Apache OpenWhisk

has the potential to evolve into a more expressive,

Advancing Serverless Workﬂow Efﬁciency: Integrating Functional Programming Constructs and DAG-Based Execution

241

efﬁcient, and ﬂexible serverless platform, bridging

the limitations of current approaches and position-

ing itself as a leading platform for complex serverless

workﬂows with higher performance and modularity.

3 PROPOSED SOLUTION

Serverless workﬂows often face inefﬁciencies due to

rigid execution models that require complete readi-

ness of inputs before invoking functions. To ad-

dress these challenges, we propose three interrelated

enhancements that leverage partial execution princi-

ples to improve performance, resource utilization, and

adaptability. Each enhancement targets a speciﬁc lim-

itation in current serverless systems, collectively pro-

viding a robust solution for dynamic and efﬁcient

workﬂow orchestration.

3.1 Support Native Directed Acyclic

Graphs (DAGs) Execution

Introducing native support for Directed Acyclic

Graph (DAG) execution transforms the capabilities of

serverless computing platforms by enabling direct or-

chestration of serverless functions within the core ex-

ecution framework. This approach enhances the abil-

ity to express and manage complex workﬂows, where

tasks have intricate data dependencies and can be exe-

cuted in parallel without external orchestration layers.

The architecture for supporting native DAG ex-

ecution involves modifying the Apache OpenWhisk

controller to interpret a domain-speciﬁc language

(DSL) designed for DAG orchestration. The con-

troller processes the DSL input, constructing a DAG

where nodes represent serverless functions and edges

represent data dependencies. These DAG deﬁnitions

and function states are stored in a CouchDB database,

ensuring persistence and traceability throughout the

execution process. The controller dynamically sched-

ules functions based on data availability, minimizing

latency and optimizing parallelism.

The design emphasizes a functional approach to

specifying complex workﬂows, enabling developers

to describe computations as dataﬂow graphs. This de-

sign choice supports parallelism and efﬁcient schedul-

ing without requiring developers to manage explicit

synchronization. The DSL provides intuitive con-

structs for deﬁning parallel maps and sequential re-

ductions, allowing the system to infer dependencies

and schedule functions accordingly. Each function

invocation is treated as an independent action, pre-

serving serverless principles such as statelessness and

event-driven execution.

The implementation extends OpenWhisk’s core

by introducing a parser and executor for the DAG

DSL. The parser translates the DSL into a JSON rep-

resentation suitable for storage and processing within

the OpenWhisk controller. During execution, the

interpreter asynchronously triggers serverless func-

tions as their input data becomes available, ensur-

ing efﬁcient parallel execution and reducing idle time.

The minimal code footprint for this extension en-

sures compatibility with existing OpenWhisk features

while introducing powerful orchestration capabilities.

The primary beneﬁts of this solution include dy-

namic parallelism, efﬁcient resource utilization, and

simpliﬁed developer experience. By natively support-

ing DAG execution, OpenWhisk enables workloads

that require complex data dependencies, such as ma-

chine learning pipelines and large-scale matrix opera-

tions. Developers can focus on the computation logic,

while the platform manages concurrency and schedul-

ing.

A practical example of the Cholesky decomposi-

tion using the DAG DSL is shown in Listing 1. This

Python-based DAG representation demonstrates how

complex matrix operations can be parallelized effec-

tively using the native DAG execution model. Each

function call and dependency is captured as a node in

the DAG, and computations run as soon as inputs are

ready.

Listing 1: DAG DSL program for Cholesky Decomposition.

def cholesky(A, B, N):

nblocks = ceil(N/B)

def for_j(j):

L[j][j] = chol(A[j][j])

par_for(i in range(j, j + nblocks)):

L[i][j] = mul(inv(L[j][j]),

A[i][j])

def for_k(k, j):

par_for(l in range(k, nblocks)):

A[k][l] = sub(A[k][l],

mul(T(L[k][j]), L[l][j]))

par_for(k in range(j, j + nblocks)):

for_k(k, j)

seq_fold(L = A, j in range(0,

nblocks))(for_j(j))

return L

This enhancement represents a step forward in

serverless architecture design by integrating complex

orchestration capabilities directly into the execution

engine. Developers gain a powerful tool for par-

allel computing, while the underlying platform en-

sures efﬁcient, cost-effective, and scalable execution

of serverless functions. The convergence of server-

less computing with native DAG execution opens new

horizons for scientiﬁc computing, data engineering,

and real-time analytics, providing a powerful mech-

CLOSER 2025 - 15th International Conference on Cloud Computing and Services Science

242

anism for modern cloud-native application develop-

ment.

3.2 Support Native Currying

Currying, a functional programming technique, trans-

forms a function with multiple arguments into a se-

ries of functions, each consuming one argument at

a time (Hutton, 2016). By adapting this concept,

serverless workﬂows can beneﬁt from incremental ex-

ecution. By allowing functions to be broken into

a sequence of partial applications, currying enables

serverless workﬂows to handle partially available data

more efﬁciently. This ﬂexibility is especially valu-

able in dynamic workﬂows where data dependencies

might be resolved incrementally or asynchronously.

Instead of waiting for all inputs to become available, a

curried function can process available inputs immedi-

ately and defer the computation of the remaining logic

until the required data arrives. This approach mini-

mizes idle time and enhances responsiveness, partic-

ularly in workﬂows with interdependent tasks that do

not all resolve simultaneously.

To illustrate the beneﬁts of currying in a serverless

context, consider a real-time video analysis pipeline

involving multiple stages: frame extraction, object

detection, and metadata tagging. In a traditional

workﬂow, each stage must wait for the previous one to

fully complete before initiating its processing. For ex-

ample, object detection cannot begin until all frames

have been extracted, and metadata tagging must wait

for all object detection results. This sequential depen-

dency unnecessarily increases latency and underuti-

lizes the dynamic invocation capabilities of serverless

platforms. Listing 2 highlights this limitation.

Listing 2: Traditional serverless workﬂow of video analysis.

def process_video(video_url):

frames = extract_frames(video_url)

objects = detect_objects(frames)

metadata = tag_metadata(objects)

return metadata

In this approach, each function, such as

detect objects and tag metadata, waits for

the complete output of the preceding function,

extract frames, before starting execution. This cre-

ates a bottleneck, particularly in workﬂows process-

ing large volumes of data, where intermediate results

could be used immediately.

With currying, the workﬂow can be restructured

to process data incrementally and trigger subsequent

stages dynamically. As shown in Listing 3, partial ap-

plications allow each function to operate on the avail-

able data as soon as it is produced.

Listing 3: Curried serverless workﬂow of video analysis.

def extract_frames_partial(video_url,

callback):

for frame in

extract_frames_generator(video_url):

callback(frame)

def detect_objects_partial(frame, callback):

objects = detect_objects(frame)

callback(objects)

def tag_metadata_partial(objects, callback):

metadata = tag_metadata(objects)

callback(metadata)

def process_video_with_currying(video_url):

extract_frames_partial(video_url, lambda

frame:

detect_objects_partial(frame, lambda

objects:

tag_metadata_partial(objects,

lambda metadata:

store_metadata(metadata))))

In this curried workﬂow, each frame extracted

from the video triggers object detection immediately,

and metadata tagging begins as soon as object detec-

tion results are available. This eliminates the need

for later stages to wait for the entire dataset to be pro-

cessed in earlier stages, reducing latency. By enabling

partial execution, currying enhances the responsive-

ness of the pipeline and optimizes resource utiliza-

tion, as downstream stages are invoked only when

their input data is ready.

Furthermore, currying enriches the expressive-

ness of serverless workﬂows by making them more

composable. For instance, the object detection and

metadata tagging functions in this example can be

reused in other workﬂows with minimal modiﬁcation,

as their partial application makes them ﬂexible and

adaptable. Developers can construct modular work-

ﬂows that are easier to extend, reuse, and maintain,

reducing overall development effort.

This adoption of currying in serverless comput-

ing aligns with the goal of enabling expressive, ef-

ﬁcient, and latency-optimized workﬂows. By pro-

cessing available data incrementally and construct-

ing workﬂows as a series of lightweight, composable

steps, currying addresses the inherent limitations of

traditional serverless orchestration while leveraging

functional programming principles to enhance cloud

computing platforms.

3.3 Support Native Continuation

Continuation, rooted in functional programming (Ap-

pel, 1992), enables workﬂows to suspend and re-

Advancing Serverless Workﬂow Efﬁciency: Integrating Functional Programming Constructs and DAG-Based Execution

243

sume dynamically, addressing inefﬁciencies in long-

running serverless tasks. By pausing execution during

delays (e.g., waiting for external inputs) and resuming

only when dependencies resolve, it eliminates idle re-

source consumption — critical for cost-sensitive and

scalable workﬂows.

For instance, in a document processing pipeline

(text extraction → sentiment analysis → manual an-

notation), traditional workﬂows idle between stages,

billing continuously. Continuation suspends execu-

tion after sentiment analysis, freeing resources until

annotations arrive. This avoids wasteful billing and

preserves scalability without altering workﬂow logic.

Listing 4 demonstrates the limitations of a tradi-

tional serverless workﬂow.

Listing 4: Traditional serverless workﬂow of document pro-

cessing.

def process_document(doc_url):

text = extract_text(doc_url)

sentiment = analyze_sentiment(text)

annotations =

get_user_annotations(sentiment)

return apply_annotations(annotations,

sentiment)

In this approach, the function

get user annotations requires external input

from the user, causing the workﬂow to remain

idle while waiting. The entire workﬂow remains

active, leading to inefﬁcient resource utilization and

potential timeouts for long-running tasks.

With native continuation, the workﬂow can sus-

pend itself after completing sentiment analysis and

wait for the user’s annotations to resume. This en-

sures that resources are only allocated during active

computation phases. Listing 5 illustrates how contin-

uation can be applied.

Listing 5: Continuation-enabled serverless workﬂow of

document processing.

def process_document_continuation(doc_url):

text = extract_text(doc_url)

sentiment = analyze_sentiment(text)

suspend_workflow(lambda:

get_user_annotations_async(sentiment,

lambda annotations:

resume_workflow(lambda:

apply_annotations(annotations,

sentiment))))

In this continuation-enabled workﬂow, the

suspend workflow function pauses execution after

sentiment analysis. Once user annotations are

provided asynchronously, the workﬂow resumes

execution at the resume

workflow point, completing

the remaining tasks. This ensures that resources

are used only when needed and avoids unnecessary

idling or resource contention.

The beneﬁts of adopting continuation in server-

less workﬂows extend beyond resource optimization.

By enabling dynamic pausing and resumption, con-

tinuation allows workﬂows to handle unpredictable

or asynchronous dependencies more gracefully. De-

velopers can design workﬂows that adapt to real-time

conditions, making them more robust and responsive

to external inputs. Additionally, continuation reduces

the likelihood of workﬂow timeouts, which is partic-

ularly valuable for long-running tasks that rely on hu-

man input or external data sources.

By integrating native continuation into serverless

platforms, workﬂows become more efﬁcient and scal-

able, addressing the limitations of traditional execu-

tion models. Continuation aligns with the princi-

ples of event-driven architecture and asynchronous

programming, enhancing the capability of serverless

computing to support complex, real-world workﬂows.

4 EVALUATION

4.1 Serverless Trilemma Fulﬁllment

Baldini et al. (Baldini et al., 2017c) deﬁne the server-

less trilemma, which outlines three core constraints

for effective function composition: (1) no double-

billing, (2) black-box usage, and (3) substitution

principle. Our enhancements—native DAG execu-

tion, currying, and continuation—collectively resolve

these constraints:

• Native DAG Execution: By decoupling func-

tion calls and treating DAGs as atomic actions,

it eliminates double-billing (no waiting charges),

enforces black-box usage (no source code expo-

sure), and ensures substitutability (DAGs behave

as single functions).

• Currying: Partial function application processes

incremental data without redundant billing. Cur-

ried functions retain black-box integrity (no in-

ternal code access) and act as substitutable units

(same input/output behavior as non-curried func-

tions).

• Continuation: Suspends workﬂows during idle

periods to prevent billing, preserves black-box

constraints (execution resumption requires no

code modiﬁcation), and maintains substitutability

(paused workﬂows behave as single logical units).

Thus, native DAG execution, currying, and con-

tinuation collectively provide a strong foundation for

serverless function composition while fully satisfying

the serverless trilemma.

CLOSER 2025 - 15th International Conference on Cloud Computing and Services Science

244

4.2 Preliminary Evaluation

A preliminary prototype has been developed and re-

mains under active development. This prototype in-

cludes a patch of 800 lines of code integrated into the

Apache OpenWhisk core. The codebase modiﬁcation

focuses on extending the reactive core to support na-

tive DAG execution and functional programming con-

structs directly within the controller.

This preliminary version has successfully demon-

strated the fundamental principles of DAG execu-

tion. The integration enables dynamic orchestration

of serverless workﬂows, reducing latency and enhanc-

ing modularity, aligning with the theoretical goals

outlined in the design phase.

A preliminary evaluation of our prototype has

been conducted, demonstrating improvements over

traditional serverless execution models. Our proto-

type successfully completed identical Cholesky de-

compositions of various sizes and block numbers with

an average reduction in completion time of 28% com-

pared to numpywren (Shankar et al., 2018). The eval-

uation also showed superior parallelization and re-

source utilization, particularly for workloads involv-

ing matrix decompositions where our prototype pro-

cessed blocks in parallel, reducing idle time by 32%.

The results indicated higher worker utilization

and better parallelization with our prototype, lead-

ing to improved efﬁciency. CPU utilization levels on

the virtual machines were measured, with our proto-

type achieving a 27% higher saturation compared to

numpywren. Network overhead was reduced when

passing data between functions due to the optimized

execution model, showing a 30% reduction in data

transfer time.

The support for currying and continuation in our

prototype is expected to provide key beneﬁts. How-

ever, these features are not currently supported in the

current implementation. Once integrated, they are an-

ticipated to offer improvements such as enabling par-

tial function execution for modular workﬂows and fa-

cilitating long-running computations through pausing

and resumption.

As the implementation matures, further testing

and optimization are required. The current focus is on

ensuring compatibility with the existing OpenWhisk

components and validating the performance beneﬁts

in real-world scenarios. Early tests indicated promis-

ing results, with improved parallelization and reduced

cold start impact compared with traditional function

chaining models.

5 FUTURE WORK

Future work on the current prototype holds signiﬁ-

cant potential. Evaluation across diverse real-world

use cases is essential to validate our prototype scala-

bility and efﬁciency. Future work could focus on the

following directions:

First, DAG compilation currently occurs within

the OpenWhisk controller. A key improvement would

be shifting this compilation process to the CLI, en-

abling proactive type-checking and immediate error

detection during DAG creation. By preemptively

compiling a structured representation of function de-

pendencies, the system could facilitate advanced an-

alytics, including graph and edge analyses for work-

ﬂow optimization.

Second, extending the scope of these features to

support more complex scenarios, such as workﬂows

with dynamic or conditional dependencies, would sig-

niﬁcantly enhance their usability. For instance, en-

abling conditional branching within DAGs or natively

supporting higher-order functions would make the

platform more versatile.

Third, the integration of intelligent scheduling al-

gorithms for DAG execution could further optimize

resource utilization and reduce latency. By leveraging

reinforcement learning or heuristic-based approaches,

the system could dynamically predict resource re-

quirements, adaptively schedule tasks, and minimize

execution latency. Such improvements could lead to

more efﬁcient resource utilization, reducing opera-

tional costs while improving performance.

Fourth, one avenue for improvement is the de-

velopment of a graphical domain-speciﬁc language

(DSL) editor, allowing users to visually design and

manage DAG workﬂows. This enhancement would

improve usability, reduce complexity, and provide

better observability into function execution, depen-

dencies, and performance metrics.

Finally, comprehensive evaluation of the proto-

type in real-time scenarios is critical. This includes

benchmarking execution time, worker utilization, and

resource efﬁciency for workﬂows like Cholesky de-

composition across varying matrix sizes and block

conﬁgurations. Metrics such as the number of work-

ers executing concurrently, CPU utilization levels,

network overhead between function invocations, and

database access latency must be measured to as-

sess scalability and identify bottlenecks. Addition-

ally, comparative benchmarking against state-of-the-

art orchestrations (e.g., AWS Step Functions, Google

Cloud Workﬂows) under diverse workloads — in-

cluding machine learning pipelines, IoT data process-

ing, and large-scale computational tasks — will help

Advancing Serverless Workﬂow Efﬁciency: Integrating Functional Programming Constructs and DAG-Based Execution

245

assess performance advantages and guide further re-

ﬁnements.

By addressing these gaps, the prototype can

evolve into a robust, production-ready solution, bridg-

ing the divide between theoretical enhancements and

practical applicability in modern serverless ecosys-

tems.

6 CONCLUSION

This paper has proposed enhancements to Apache

OpenWhisk to address the limitations of existing

serverless platforms in workﬂow orchestration and

execution. The platform can handle dynamic, asyn-

chronous, and interdependent tasks more efﬁciently

by introducing native support for currying, continua-

tion, and DAG execution.

Currying allows workﬂows to process partially

available data incrementally, reducing latency and

enhancing modularity. Continuation enables work-

ﬂows to suspend and resume dynamically, optimize

resource utilization, and improve scalability for long-

running tasks. DAG execution transforms workﬂow

orchestration by enabling parallel execution, dynamic

scheduling, and efﬁcient handling of complex depen-

dencies. Together, these features align with the prin-

ciples of serverless computing, which offers greater

expressiveness, efﬁciency, and scalability.

These enhancements position Apache OpenWhisk

as a more powerful serverless platform capable of

supporting modern, complex workﬂows. By reduc-

ing operational overhead and improving resource uti-

lization, they bring serverless computing closer to its

promise of seamless scalability and efﬁciency, em-

powering developers to focus on innovation while the

platform handles the complexities of execution.

REFERENCES

Appel, A. W. (1992). Compiling with Continuations. Cam-

bridge University Press.

Baldini, I., Castro, P., Chang, K., Cheng, P., Fink, S.,

Ishakian, V., Mitchell, N., Muthusamy, V., Rabbah,

R., Slominski, A., and Suter, P. (2017a). Serverless

computing: Current trends and open problems.

Baldini, I., Castro, P., Chang, K., Cheng, P., Fink, S. J.,

Ishakian, V., Muthusamy, V., Rabbah, R. M., Suter, P.,

and Tardieu, O. (2017b). Serverless computing: Cur-

rent trends and open problems. Research Advances in

Cloud Computing, pages 1–20.

Baldini, I., Cheng, P., Fink, S. J., Mitchell, N., Muthusamy,

V., Rabbah, R., Suter, P., and Tardieu, O. (2017c). The

serverless trilemma: function composition for server-

less computing. In Proceedings of the 2017 ACM

SIGPLAN International Symposium on New Ideas,

New Paradigms, and Reﬂections on Programming and

Software - Onward! 2017, pages 89–103. ACM Press.

Fouladi, S., Mitchell, E. J., Wei, H., Devanbu, P., and Zhao,

J. (2019). Wukong: A scalable and locality-enhanced

framework for serverless parallel computing. In Pro-

ceedings of the ACM Symposium on Cloud Computing

(SoCC ’19), pages 1–12, Santa Cruz, California, USA.

ACM.

Garc

ıa-L

opez, P., Arjona, A., Samp

e, J., Slominski, A.,

and Villard, L. (2020). Triggerﬂow: Trigger-based

orchestration of serverless workﬂows. arXiv preprint

arXiv:2006.08654.

Hutton, G. (2016). Programming in Haskell, chapter 5,

pages 73–77. Cambridge University Press. Discusses

the concept of currying and its applications in func-

tional programming.

Jana, A., Kulkarni, P., and Bellur, U. (2023). DAGit: A Plat-

form For Enabling Serverless Applications. In Pro-

ceedings of the 2023 IEEE 30th International Con-

ference on High Performance Computing, Data, and

Analytics (HiPC), pages 367–376.

Jonas, E., Schleier-Smith, J., Sreekanti, V., Tsai, C.-C.,

Yadwadkar, N., Gonzalez, J. E., Popa, R. A., Stoica,

I., and Patterson, D. A. (2019). Cloud programming

simpliﬁed: A berkeley view on serverless computing.

arXiv preprint arXiv:1902.03383.

Kratzke, N. (2021). Cloud Computing. Hanser Verlag, 2nd

edition. Section 12.6.1.

Li, Z., Xu, C., Chen, Q., Zhao, J., Chen, C., and Guo,

M. (2024). Dataﬂower: Exploiting the data-ﬂow

paradigm for serverless workﬂow orchestration. In

Proceedings of the 28th ACM International Confer-

ence on Architectural Support for Programming Lan-

guages and Operating Systems, Volume 4, ASPLOS

’23, page 57–72, New York, NY, USA. Association

for Computing Machinery.

Lin, P.-M. and Glikson, A. (2019). Mitigating cold starts in

serverless platforms: A pool-based approach.

Shahrad, M., Fonseca, R.,

nigo Goiri, Chaudhry, G., Ba-

tum, P., Cooke, J., Laureano, E., Tresness, C., Russi-

novich, M., and Bianchini, R. (2020). Serverless in

the wild: Characterizing and optimizing the serverless

workload at a large cloud provider.

Shankar, V., Krauth, K., Pu, Q., Jonas, E., Venkataraman,

S., Stoica, I., Recht, B., and Ragan-Kelley, J. (2018).

numpywren: serverless linear algebra. arXiv preprint

arXiv:1810.09679.

Shi, X., Li, C., Li, Z., Liu, Z., Sheng, D., Chen, Q., Leng,

J., and Guo, M. (2023). Dﬂow: Efﬁcient dataﬂow-

based invocation workﬂow execution for function-as-

a-service. arXiv preprint arXiv:2306.11043.

Yu, M., Cao, T., Wang, W., and Chen, R. (2022). Following

the data, not the function: Rethinking function orches-

tration in serverless computing.

CLOSER 2025 - 15th International Conference on Cloud Computing and Services Science

246