Embed Size (px)
Citation preview
Triggerflow: Trigger-based Orchestration of ServerlessWorkflows
Pedro García LópezIBM Watson Research
New York, [email protected]
Aitor ArjonaUniversitat Rovira i Virgili
Tarragona, [email protected]
Josep SampéUniversitat Rovira i Virgili
Tarragona, [email protected]
Aleksander SlominskiIBM Watson Research
New York, [email protected]
Lionel VillardIBM Watson Research
New York, [email protected]
ABSTRACTAsmore applications are being moved to the Cloud thanks to server-less computing, it is increasingly necessary to support native lifecycle execution of those applications in the data center.
But existing systems either focus on short-running workflows(like IBM Composer or Amazon Express Workflows) or imposeconsiderable overheads for synchronizing massively parallel jobs(Azure Durable Functions, Amazon Step Functions, Google CloudComposer). None of them are open systems enabling extensibleinterception and optimization of custom workflows.
We present Triggerflow: an extensible Trigger-based Orchestra-tion architecture for serverless workflows built on top of KnativeEventing and Kubernetes technologies. We demonstrate that Trig-gerflow is a novel serverless building block capable of construct-ing different reactive schedulers (State Machines, Directed AcyclicGraphs, Workflow as code). We also validate that it can supporthigh-volume event processing workloads, auto-scale on demandand transparently optimize scientific workflows.
CCS CONCEPTS• Computer systems organization→ Cloud computing.
KEYWORDSevent-based, orchestration, serverless
ACM Reference Format:Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski,and Lionel Villard. 2020. Triggerflow: Trigger-based Orchestration of Server-less Workflows. In The 14th ACM International Conference on Distributed andEvent-based Systems (DEBS ’20), July 13–17, 2020, Virtual Event, QC, Canada.ACM,NewYork, NY, USA, 12 pages. https://doi.org/10.1145/3401025.3401731
Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior specific permission and/or afee. Request permissions from [email protected] ’20, July 13–17, 2020, Virtual Event, QC, Canada© 2020 Association for Computing Machinery.ACM ISBN 978-1-4503-8028-7/20/07. . . $15.00https://doi.org/10.1145/3401025.3401731
1 INTRODUCTIONServerless Function as a Service (FaaS) is becoming a very popularprogramming model in the cloud thanks to its simplicity, billingmodel and inherent elasticity. The FaaS programming model isconsidered event-based, since functions are activated (triggered) inresponse to specific Cloud Events (like a state change in a disaggre-gated object store like Amazon S3).
The FaaS model has also proven ideally suited (PyWren [14],ExCamera [9]) for executing embarrassingly parallel computingtasks. But both PyWren and ExCamera required their own ad-hocexternal orchestration services to synchronize the parallel execu-tions of functions. For example, when the PyWren client launches amap job with N functions, it waits and polls Amazon S3 until all theresults are received in the S3 bucket. ExCamera also relied on anexternal Rendezvous server to synchronize the parallel executions.
Lambda creator Tim Wagner recently outlined [24] that Cloudproviders must offer new serverless building blocks to applications.In particular, he foresees new services like fine-grained, low-latencyorchestration, execution data flows, and the ability to customizecode and data at scale to support the emerging data-intensive ap-plications over Serverless Functions.
The reality is that existing serverless orchestration systems arenot designed for long-running data analytics tasks [3, 18]. Eitherthey are focused on short-running highly interactive workflows(Amazon Express Workflows, IBM Composer) or impose consider-able overheads for synchronizing massively parallel jobs (AzureDurable Functions, Amazon Step Functions, Google Cloud Com-poser).
We present Triggerflow, a novel building block for composingevent-based services. As more applications are moved to the Cloud,this service will enable to control the life-cycle of those applicationsin a reactive and extensible way. The flexibility of the system canalso be used to transparently optimize the execution of tasks inreaction to events.
The major contributions of this paper are the following:
(1) We present a Rich Trigger framework following an Event-Condition-Action (ECA) architecture that is extensible at alllevels (Event Sources and Programmable Conditions and Ac-tions). Our architecture ensures that composite event detec-tion and event routing mechanisms are mediated by reactiveevent-based middleware.
3
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
(2) We demonstrate Triggerflow’s extensibility and universal-ity creating atop it a state machine workflow scheduler, aDAG engine, an imperative Workflow as Code (using eventsourcing) scheduler, and integration with an external sched-uler like PyWren. We also validate performance and over-head of our scheduling solutions compared to existing CloudServerless Orchestration systems like Amazon Step Func-tions, Amazon Express Workflows, Azure Durable Functionsand IBM Composer.
(3) We finally propose a generic implementation of our modelover standard CNCF Cloud technologies like Kubernetes,Knative Eventing and CloudEvents. We validate that our sys-tem can support high-volume event processing workloads,auto-scale on demand and transparently optimize scientificworkflows. The project is available as open-source in [1].
2 RELATEDWORKFaaS is based on the event-driven programmingmodel. In fact, manyevent-driven abstractions like triggers, Event Condition Action(ECA) and even composite event detection were already inspiredby the veteran Active Database Systems [21].
Event-based triggering has also been extensively employed in thepast to provide reactive coordination of distributed systems [11, 20].Event-based mechanisms and triggers have also been extensivelyused [4, 6, 10, 17] in the past to build workflows and orchestrationsystems. The ECA model including trigger and rules fits nicely todefine the transitions of finite state machines representing work-flows. In [7], they propose to use synchronous aggregation triggersto coordinate massively parallel data processing jobs.
An interesting related work is [17]. They leverage composite sub-scriptions in content-based publish/subscribe systems to providedecentralized Event-based Workflow Management. Their PADRESsystem supports parallelization, alternation, sequence, and rep-etition compositions thanks to content-based subscriptions in aComposite Subscription Language.
More recently, a relevant article [22] has surveyed the intersec-tions of the Complex Event Processing (CEP) and Business ProcessManagement (BPM) communities. They clearly present the existingchallenges to combine both models and describe recent efforts inthis area. We outline that our paper is in line with their challenge“Executing business processes via CEP rules", and our novelty hereis our serverless reactive and extensible architecture.
In serverless settings, the more relevant related work aiming toprovide reactive orchestration of serverless functions is the Server-less trilemma [2] from IBM. In their paper, the authors advocate forreactive run-time support for function orchestration, and present asolution for sequential compositions on top of Apache OpenWhisk.
A plethora of academic works are proposing different so-calledserverless orchestration systems like [5, 8, 13, 15, 19, 23]. However,most of them rely on non-serverless services like VMs or dedicatedresources, or they use functions calling functions patterns whichcomplicate their architectures and fault tolerance. None of themoffer extensible trigger abstractions to build different schedulers.
All Cloud providers are now offering cloud orchestration andfunction composition services like IBM Composer, Amazon StepFunctions, Azure Durable Functions, or Google Cloud Composer.
IBM Composer service is in principle designed for short-runningsynchronous composition of serverless functions. IBM Composergenerates a state machine representation of the workflow to beexecuted with IBM Cloud Functions. It can represent sequences,conditional branching, loops, parallel, and map tasks. However,fork/join synchronization (map, parallel) blocks on an externaluser-provided Redis service, limiting their applicabillity to shortrunning tasks.
Amazon offers two main services: Amazon Step Functions (ASF)and Amazon Step Functions Express Workflows (ASFE). The Ama-zon States Language (based on JSON) permits to model task transi-tions, choices, waits, parallel, and maps in a standard way. ASF is afault-tolerant managed service designed to support long-runningworkflows and ASFE is designed for short-running (less than fiveminutes) highly intensive workloads with relaxed fault-tolerance.
Microsoft’s Azure Durable Functions (ADF) represents work-flows as code using C# or Javascript, leveraging async/await con-structs and using event sourcing to replay workflows that have beensuspended. ADF does not support map jobs explicitly, and only in-cludes a Task.whenAll abstraction enabling fork/join patterns for agroup of asynchronous tasks.
Google offers Google Cloud Composer service leveraging a man-aged Apache Airflow cluster. Airflow represents workflows in aDAG (Directed Acyclic Graph) coded in Python, so that it cannotsupport cycles. It is not ideally suited for parallel jobs or high-volume workflows, and it is not designed for orchestrating server-less functions.
Two previous papers [3, 18] have compared public FaaS orches-tration services for coordinating massively parallel workloads. Inthose studies, IBM Composer offered the fastest performance andreduced overheads to execute map jobs whereas ASF or ADF im-posed considerable overheads. We will also show in this paper howASFE obtains good performance for parallel workloads.
None of the existing cloud orchestration services is offeringan open and extensible trigger-based API enabling the creationof custom workflow engines. We demonstrate in this paper thatwe can use Triggerflow to implement existing models like ASFor Airflow DAGs. Triggerflow is not just another scheduler, but areactive meta-tool to build reactive schedulers leveraging Knativestandard technologies.
2.1 Cloud Event Routing and Knative EventingEvent-based architectures are gaining relevance in Cloud providersas a unifying infrastructure for heterogeneous cloud services andapplications. Event services participate in the entire cloud controlloop from event production in event sources, to event detectionusing monitoring services, to event logging and data analytics ofexisting event workflows, and finally to service orchestration andevent reaction thanks to appropriate filtering mechanisms.
The trend is to create cloud event routers, specialized rule-basedmulti-tenant services, capable of filtering and triggering selectedtargets in the Cloud in response to events. Amazon is offering Event-Bridge, Azure offers EventGrid, and Google and IBM are investingin the open Knative Eventing project and CNCF CloudEvents stan-dard.
4
Triggerflow: Trigger-based Orchestration of Serverless Workflows DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada
TheKnative project was created to provide streamlined serverless-like experience for developers using Kubernetes. It contains a setof high-level abstractions related to scalable functions (KnativeServing) and event processing (Knative Eventing) that allows thedescription of asynchronous, decoupled, event-driven applicationsbuilt out of event sources, sinks, channels, brokers, triggers, filters,sequences, etc.
The goal of Knative is to allow developers to build cloud na-tive event-driven serverless applications on those abstractions. Thevalue of Knative is to encapsulate well tested best practices in high-level abstractions that are native to Kubernetes: custom resourcedefinitions (CRDs) for new custom resources (CRs) such as eventsources. Abstractions allow developers to describe event-drivenapplication components and have late-binding to underlying (pos-sibly multiple) messaging and eventing systems like Apache Kafkaand NATS among others.
Triggerflow aims to leverage existing event routing technology(Knative Eventing) to enable extensible trigger-based orchestrationof serverless workflows. Triggerflow includes advanced abstrac-tions not present in Knative Eventing like dynamic triggers, triggerinterception, custom filters, termination events, and a shared con-text among others. Some of these novel services may be adopted inthe future by event routing services to make it easier to compose,stream, and orchestrate tasks.
3 TRIGGERFLOW ARCHITECTURE
We can see in Figure 1 an overall diagram of the Triggerflow Archi-tecture. The Trigger service follows an extensible Event-Condition-Action architecture. The service can receive events from differ-ent Event Sources in the Cloud (Kafka, RabbitMQ, Object Storage,timers). It can execute different types of Actions (containers, Func-tions, VMs). And it can also enable the creation of custom filters orConditions from third-parties. The Trigger service also provides ashared persistent context repository providing durability and faulttolerance.
Figure 1 also shows the basic API exposed by TriggerFlow: cre-ateWorkflow initializes the context for a given workflow, addTriggeradds a new trigger (including event, conditions, actions, and con-text), addEventSource permits the creation of new event sources,and getState obtains the current state associated to a given triggeror workflow.
Different applications and schedulers can benefit from serverlessawakening and rich triggering by using this API to build differentorchestration services like Airflow-like DAGs, ASF state machinesor Workflow as Code clients like PyWren.
3.1 Design goalsLet’s establish a number of design goals that must be supported inthe proposed architecture:
(1) Support for Heterogeneous Workflows: The main idea is tobuild a generic building block for different types of sched-ulers. The system should support enterprise workflows basedon Finite StateMachines, Directed Acyclic Graphs, andWork-flow as Code systems.
(2) Extensibility andComputational Reflection: The systemmustbe extensible enough to support the creation of novel work-flow systems with special requirements like specialized sci-entific workflows. The system must support introspectionand interception mechanisms enabling the monitoring andoptimization of existing workflows.
(3) Serverless design: The system must be reactive, and onlyexecute logic in response to events, like state transitions.Serverless design also entails pay per use, flexible scaling,and dependability.
(4) Performance: The system should support high-volume work-loads like data analytics pipelines with numerous paralleltasks. The system should exhibit low overheads for bothshort-running and long-running workflows.
3.2 Trigger serviceOur proposal is to design a purely event-driven and reactive archi-tecture for workflow orchestration. Like previous works [4, 6, 10],we also propose to handle state transitions using event-based trig-gering mechanisms. The novelty of our approach precisely relieson the aforementioned design goals: support for heterogeneousworkflows, extensibility, serverless design, and performance forhigh volume workloads.
We follow an Event Condition Action architecture in whichtriggers (active rules) define which action must be launched inresponse to Events or to Conditions evaluated over one or moreEvents. The system must be extensible at all levels: Events, Condi-tions, and Actions. Let us introduce some definitions:
Definition 1. Workflow: We can represent a workflow as aFinite State Machine (FSM) being a 6-tuple withM = (
∑in,Ctx, S, s, F , δ ), in this 6-tuple:
(1)∑in : the set of input events
(2) Ctx: the set of context variables(3) S: the set of states which map to Actions in the ECA model(4) s: initial state, linked to an initial event(5) F: end state, linked to a final Termination event(6) δ : state-transition function: δ : S ×
∑→ S , based on the
ECA triggersDefinition 2. Trigger (δ ): can be defined as the state transition
function. The trigger is a 4-tuple with (Event, Context, Condition,Action) that moves one state to the following when the condition oninput events holds. In this case, the trigger launches the appropriateaction which corresponds to the next state. Each action will in turnfire events that may be captured by another trigger. Triggers can betransient and dynamic (activated on demand) or persistent if theyremain always active.
Its components are:• Event: Events are the atomic piece of information that driveflows in Cloud applications. We rely on the standard CNCFCloudEvents version 1.0 specification to represent events.To match an event to its trigger, the subject and type fieldsof a CloudEvent are used. We use the subject field to matchthe event to its corresponding trigger, and the type field todescribe the type of the event. Termination and failure eventsuse this type field to notify success (and result) or failure(and code or error information).
5
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
Trigger service worker
RESTfulAPI
createWorkflow
addEventSource
addTrigger
getContext
PersistentStorage
EventSourceSubscribers KafkaSource RedisStreamsSource SQSSource
Worker Event Sink
Global Context
Triggers
Match activation event with trigger
Event-Trigger Processing
Condition
TriggerContext
Action
UpdateState /
checkpoint
CommitEvent
[true]
Google Composer-likeDAGs Interface
Amazon StepFunctions Interface
PyWren imperativeInterface
User defined container or default Python functions
Events
Figure 1: Triggerflow Architecture
• Context: The context is a fault-tolerant key-value data struc-ture that contains the state of the trigger during its lifetime.It is also used to introspect the current trigger deployment,to modify the state of other triggers or to dynamically acti-vate/deactivate triggers.
• Condition: Conditions are active rules (user-defined code)that filter events to decide if they match in order to launchthe corresponding action. Conditions evaluate rules overprimitive events (single) or over composite (group) events.Composite event information like counters may be storedin the Context. Conditions produce a boolean result thatrepresents whether the trigger has to be fired or not.
• Action: Actions are the computations (user-defined code)launched in response to matching Conditions in a trigger.An Action can be a serverless function or some code in aVM or container in the Cloud. When the action is executed,we consider that the trigger has been fired.
Definition 3. Mapping workflow to triggers: A workflowcan be mapped to a set of Triggers (∆) which contains all statetransitions (δ triggers) in the State Machine.
We will show in next sections how different workflows (AmazonStep Functions) and Directed Acyclic Graphs (Apache Airflow) canbe transformed to a set of triggers (∆), which is the informationneeded by the Trigger service to orchestrate them. For example, totransform a DAG into triggers, a trigger is added for every edge(workflow transition) of the graph. In a DAG, every node has itsown unique ID, so the termination event from a task will containas subject its ID to fire the trigger that handles its termination andinvokes the next step in the workflow.
Definition 4. Substitution principle: A Workflow must com-ply with an Action according to triggering (initialization) and final-ization (Termination Event). A homogeneous treatment of Work-flows and Actions permits nested workflow composition and itera-tions.
Definition 5. Dynamic Trigger interception: Any triggercan be intercepted dynamically and transparently to execute adesired action. Interception code is also performed with triggers.It must be possible to intercept triggers by condition identifier orby trigger identifier. The condition identifier represents each ex-isting condition in Triggerflow, for example a map condition thataggregates all events in a parallel invocation. The trigger identifierrepresents the unique ID that each trigger receives on creation.
We can introspect workflows, triggers, conditions, and actionsusing the Context. And we can intercept any trigger in the systemin a transparent way using the Rich Trigger API. This opens thesystem to customize code and data in a very granular way.
4 PROTOTYPE IMPLEMENTATIONWe have developed two different implementations of Triggerflow:one over Knative, which follows a push-based mechanism to passthe events from the event source to the appropriate worker, andanother one using Kubernetes Event-driven Autoscaling (KEDA),where the worker follows a pull-based mechanism to retrieve theevents directly from the event source. We created the prototypeson top of the IBM Cloud infrastructure, leveraging the services inits catalog to deploy the different components of our architecture.These components are the following:
• A Front-end RESTful API, where a user connects to interactwith Triggerflow.
• A Database, responsible for storing workflow information,such as triggers, context, etc.
• A Controller, responsible for creating the workflow workersin Kubernetes.
• The workflow workers (TF-Worker hereafter), responsiblefor processing the events by checking the triggers’ condi-tions, and applying the actions.
6
Triggerflow: Trigger-based Orchestration of Serverless Workflows DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada
In our implementation, each workflow has its own TF-Worker. Inother words, the scalability of the system is provided at workflow-level and not at TF-Worker level. In the validation (Sec. 6), wedemonstrate how each TF-Worker provides enough event ingestionrate to process large amounts of events per second.
In our system, the events are logically grouped in what we callworkflows. The workflow abstraction is useful, for example, to dif-ferentiate and isolate the events from multiple workflows, allowingto share a common context among the (related) events.
4.1 Deployment on KnativeWe mainly benefit from the Knative auto scaler component in Kna-tive Serving and the routing/filtering service in Knative Eventing.
Any serverless reactive architecture requires a managed multi-tenant component that is constantly running, monitoring eventsources, and only launching actions in response to specific events.In this way, the tenant only pays for the execution of actions inresponse to events, and not for the constant monitoring of eventservices. For example, in OpenWhisk, when we create a trigger fora Function (like an Object Storage trigger), the system is in chargeof monitoring the event source and only launching the function inresponse to events.
In Knative Eventing, each tenant will have an Event Sourcethat receives all events they are interested in (and have accessto). We register a Knative Eventing trigger for each workflow inthe system. The filtering capabilities of Knative Eventing’s triggerpermit to route events of this workflow to the appropriate TF-Worker (Condition).
Each workflow event is tagged with a unique workflow identifier.We have created a customized functions runtime, which generatesfunction termination events to the desired message broker thatinclude the selected workflow identifier. If Triggerflowmust receiveevents from services which do not include this workflow ID, ageneric filtering service will match conditions to the incomingevent (like “all events of this object storage bucket belong to thisworkflow"), tag the event, and route it to the tenant’s Event Source.
As each event contains a unique identifier per workflow, it is easyfor Knative eventing to route this event to the selected TF-Worker.The TF-Worker is then launched by Knative Serving to process theevent, but it will also scale to zero if no more events are producedin a period. This ensures the serverless scale to zero and pay as yougo qualities for our Triggerflow service. The TF-Worker accessesworkflow state in the Context persistent store, which is also usedfor checkpointing and fault tolerance.
Regarding fault tolerance, Knative Eventing guarantees "atleast once" message delivery, and automatic detection and restartof failed workers. If a TF-Worker fails, the persistent Context willrestore the state in a consistent manner after the failure. The persis-tent Context is also used for stateful Conditions, like aggregationfork-join triggers that perform composite event detection and eventcounting.
4.2 Deployment on KEDAOne of the hardest problems in event-driven applications is to dealwith reliability and scalability. Event systems may be receivingevents as soon as they are created ("pushed") or they may process
KEDAController
RESTfulAPI
TriggerflowWorker
(TF-Worker)
TriggerflowWorker
(TF-Worker)
TriggerflowWorker
(TF-Worker)Database
Actor
AWS SQS GCP Pub/Sub Apache Kafka
1
2
3
4
7
6workflow
-1w
orkflow-2
workflow
-3
TriggerflowController
5
Redis Streams
Figure 2: Prototype deployment on KEDA
them when they are ready ("pull" or "poll") and for both cases theyneed to deal with capacity limits and error handling. Knative isvery well suited for push-based scaling as it can auto-scale basedon incoming HTTP requests containing events. Kubernetes Event-driven Autoscaling (KEDA) is the best option now for event-basedconfigurable pull-based scaling.
We have also implemented Triggerflow entirely on top of Ku-bernetes using the KEDA project [16]. KEDA offers pull-basedconfigurable event queue monitoring and reactive scalable instan-tiation of Kubernetes containers. KEDA also offers configurableauto-scaling mechanisms to scale up or down to zero.
In this case, the Triggerflow Controller integrates KEDA for themonitoring of Event Sources and for launching the appropriate TF-Workers, and scaling them to zero when necessary. It is also possibleto configure different parameters in KEDA like the queue pullinginterval, passivation interval, and number of events scaling interval.Different types of workflows may require different configurationparameters.
The advantage here is that, unlike in Knative Eventing, ourTF-Workers connect directly to the Message Broker (Kafka, RedisStreams) using the native protocol of the broker. This permits tohandle more events per second in a single pod. As we demonstratein the validation, this allows us to handle intensive workloads fromscientific workflows coordinating parallel jobs over thousands ofserverless functions.
Figure 2 shows a high-level perspective of our implementationusing KEDA. In this deployment, Triggerflow works as follows:Through the client, a user must firstly create an empty workflowto the Triggerflow registry, and reference an event source that thisworkflow will use. Then, the user can start adding triggers to it (1).All the information is persisted in the database (for example, Redis)(2). Then, immediately after creating the workflow, the front-endAPI communicates with the Triggerflow controller (3), deployed as asingle stateless pod container (service) in Kubernetes, to create theauto-scalable TF-Worker in KEDA (4). From this moment, KEDAis responsible to scale up and down the TF-Workers (5). In KEDA,as stated above, the TF-Worker is responsible for communicatingdirectly to the event source (6) to pull the incoming events. Finally,TF-Workers periodically interact with the database (7) to keep thelocal cache of available triggers updated, and to store the context(checkpointing) for fault-tolerance purposes.
7
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
Regarding fault tolerance, we also guarantee "at least once"message delivery and restarting of failed workers. In this case, theTF-Worker uses batching to commit groups of events in the KafkaEvent Source once they have been correctly processed. If the TF-Worker fails, Kafka will just resend the non-committed events tothe TF-Worker and thus ensuring message delivery.
In our Redis implementation, we use Redis both as event broker(Redis Streams), and as persistent store (for the Context and events).Again, if the TF-Worker fails, all events are in the event store, so itwill continue with the non-processed events.
If Knative Eventing and KEDA communities converge in thenext months, we will be able to deploy Triggerflow directly ontop of one unified event router technology. It is also possible thatsome building blocks of Triggerflow could be moved to the KnativeEventing kernel. For example, the Knative Eventing community isnow considering more advanced filtering mechanisms (complexevent processing). In that case, our TF-Worker could delegate manytasks to the underlying event router.
5 USE CASESTo demonstrate the flexibility that can be achieved using triggerswith programmable conditions and actions, we have implementedthree different workflow models that use Triggerflow as the under-lying serverless and scalable workflow orchestrator.
5.1 Directed Acyclic GraphsWhen a workflow is described as a Directed Acyclic Graph (DAG),the vertices of the graph represent the tasks of the workflow andthe edges represent the dependencies between the tasks. The factthat a DAG does not have cycles implies that there are no cyclicdependencies, which would be impossible to fulfill.
The orchestration platforms that rely on DAGs for their work-flow description, such as Apache Airflow, handle the dependenciesbetween tasks with their downstream relatives attribute, i.e. upon acompletion of a task execution, these orchestrators look for whattasks have to be executed after the completed task.
However, from a trigger-based orchestration perspective, it ismore compelling to know what tasks have to be executed beforea certain one, i.e. what are the dependencies of every task, theirupstream relatives. With this information, we can register a triggerto activate a task’s execution when all termination events from itsupstream relatives are present.
To orchestrate a workflow defined as a DAG with triggers, wewill define a trigger for every edge of the DAG:
• As activation events of the trigger, we register the task IDsthat have to be completed before the tasks that the edgepoints to (their upstream relatives).
• As condition, we count the number of events the triggerhas to aggregate before executing the next task (i.e. a join ofa map execution).
• As action, we register the actual task to be executed, ideallyan asynchronous task such as an invocation of a serverlessfunction.
To orchestrate a workflow in this way, it is assumed that afteran asynchronous task is completed, it will produce a termination
Task3Task3Task3
Task1
Task2
Activation event: { T1 }Action: Map
Activation event: { $init }Action: Call Async
Activation events: { T2, T3 }Condition: Receiveone term. event fromT2 and N term.events from T3
<<init event>>
<<end>>
Trigger 1
Trigger 2 Trigger 3
<<invoke async>>
Trigger 4
<<Task 1 term. event>>
<<map>>
<<fan-in>>
Figure 3: Triggers that connect the tasks of an example DAG
event containing its ID to activate the trigger that manages the taskexecution that follows it.
To handle a map-join trigger condition, before actually makingthe invocation requests, we use the introspect context feature fromthe activated trigger action to dynamically modify the condition ofthe trigger that will aggregate the events, to set the specific numberof expected functions to be joined. This is used in the case that theiterator which we map onto has a variable length depending on theworkflow execution.
Furthermore, this approach gives us the opportunity to handleerrors during a workflow runtime. Special triggers can be added thatactivate when a task fails, so that the trigger action can handle thetask’s error and halt the workflow execution until the error is solved.After error resolution (retry, skip or try-catch logic), the workflow’sexecution can be resumed by activating the corresponding triggerthat would have been executed in the first place, as if there had notbeen an error.
The DAGs interface implementation is inspired by Airflow’sextensible DAG definition based on the Operator abstraction. Ac-cording to Airflow’s core ideas, an Operator describes what is theactual work logic that is carried out by a task. Airflow offers awide variety of operators to work with out of the box, but it canbe extended through the implementation of plugins. This approachis well suited to Triggerflow’s architecture, thanks to its flexibleprogrammatic trigger actions and conditions.
To illustrate this approach, Figure 3 depicts how a simple DAGwith call async, maps, and branches is orchestrated using triggers.
5.2 State Machines and Nested WorkflowsAmazon Step Functions bases its workflow description on a statemachine defined by a declarative JSON object using the AmazonStates Language DSL.
Similarly to Airflow’s DAGs, a state machine definition in Ama-zon States Language (ASL) only takes into consideration what isthe next state to execute for each of them. However, from a trig-ger perspective, it is needed to figure out what states need to beexecuted before a given one, so that we can add a trigger that firesupon a state completion and executes the next one. Therefore, therewill be a trigger for every state transition that handles the statemachine flow logic.
8
Triggerflow: Trigger-based Orchestration of Serverless Workflows DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada
Nevertheless, a distinctive feature that ASL provides is that astate can be a sub-state machine. For instance, the primitives mapand parallel, map and branch to an entire state machine, ratherthan a single task like in the DAG interface. To manage this feature,we need a special event that is produced when a state machineends. For map and branch joins, we will then join those sub-statemachines instead of single tasks. To do so, we identify each sub-state machine with a unique tag in the scope of the execution. Bydoing so, we also comply with the substitution principle of theserverless trilemma.
To produce state machine termination events, we need to activatetriggers from within a trigger action/condition function, as statemachine joining is detected in there. To do so, the worker’s eventsink internal buffer was made accessible through the context objectso that a trigger action/condition function can produce the eventsthat activate the necessary subsequent triggers.
In an Amazon Step Functions execution, the states can transfertheir output to the input of the following state. To reproduce thisfunctionality, we use the Context of theWorkflow, so that the outputof a state can be saved in the trigger’s context and accessed by othertriggers.
If we consider a state machine to be itself a state, we can seam-lessly compose ASL definitions in other state machines with itstriggers and connections. Amazon Step Functions, however, is morelimited in terms of task extensibility since we are given a closed setof state types. We will explain here how these are processed withtriggers:
• Task and Pass states: These state types carry out the actualworkflow computational logic, the rest of the state typesonly manage the state machine flux. The Task state relies onthe asynchronous Lambda invoked to signal the next triggerupon its termination, whereas the Pass state signals itself itstermination event.
• Choice state: The choice state type defines a set of possibleoutcomes that execute depending on some basic booleanlogic that can compare numbers, timestamps, and strings.The trigger approach for this state is simple: for all possibleoutcomes apply the condition defined in the Choice stateto the condition field of the trigger that handles its stateexecution.
• Parallel state: This state type defines a set of sub-state ma-chines that run in parallel. In this case, we will iterate eachsub-state machine and collect their IDs. Finally, we add atrigger that is activated whenever any of those sub-state ma-chines ends, but it is only executed when it has been signaledby every sub-state machine.
• Map state: Similarly to the Parallel state type, this statedefines a single sub-state machine that executes for everyelement in an iterable data structure input in parallel. Beforeexecuting the sub-state machines, we first add a trigger that,during its action execution, checks the length of the iterableobject (which is the number of parallel state machines, un-known until execution), and registers it to the trigger contextthat handles the sub-state machines termination stating howmany of them it should wait for.
• Wait state: The Wait state type waits for a certain amount ofseconds, or until a timestamp is reached before continuing.It can be implemented by registering the activation eventproduction that activates the trigger to an external time-based scheduler.
• Fail and Succeed states: The Fail and Succeed states stopthe execution of the state machine and determine if it exe-cuted successfully or failed. It can be implemented assigningspecial actions to their triggers that end the execution of theworkflow.
Figure 4 depicts how an ASF state machine is orchestrated bytriggers.
RunFirst
$init
RunFirst
Map
Map
Outcome1
Outcome1
Outcome2
Outcome2
MapTask
MapTask
StateMachine2
StateMachine2
StateMachine1
StateMachine1
StateMachine3
StateMachine3
Fork
StateMachine0
StateMachine0
$end
<<branch>>
<<choice>>
<<fan-out>>
<<fan-in>>
<<branch join>>
Figure 4: Triggers representation of an ASF state machine
5.3 Workflow as Code and Event SourcingThe trigger service is also useful to reactively invoke an externalscheduler because of state changes caused by some condition. Forexample, Workflow as Code systems like PyWren or Azure DurableFunctions represent state transitions as asynchronous functioncalls (async/await) inside code written in Python or C#. Asynchro-nous invocations and futures in PyWren or async/await calls inAzure Durable Functions simplify code so developers can writesynchronous-like code that suspends and continues when eventsarrive.
The model supported by Azure Durable Functions is reactive andevent-based, and it relies on event sourcing to restart the function toits current state. We can use dynamic triggers to support externalschedulers like Durable Functions that suspend their executionuntil the next event arrives. For example, let’s look at this PyWrencode:
9
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
import pywren_ibm_cloud as pywren
def my_function(x):
return x + 7
pw = pywren.ibm_cf_executor()
future = pw.call_async(my_function , 3)
res = future.result()
futures = pw.map(my_function , range(res))
print(pywren.get_result(futures))
In this code, the functions call_async andmap are used to invokeone or many functions. PyWren code like this is executed normallyin the client in a notebook, which is usually adequate for shortrunning workflows. But what if we want to execute a long-runningworkflow with PyWren in a reactive way? The solution is to runthis PyWren code in Triggerflow reacting to events. Here, priorto perform any invocation, PyWren can register the appropriatetriggers, for example:
call_async(my_function, 3): Inside this code we will dynami-cally register a function termination trigger.
map(my_function, range(res)): Inside this code we will dy-namically register an aggregate trigger for all functions in the map.
After trigger registration for each function, the function canbe invoked and the orchestrator function could decide to suspenditself. It will be later activated when the trigger fires.
To ensure that this PyWren code can be restarted and continuefrom the last point, we use event sourcing. When the orchestratorcode is launched, an event sourcing action will re-run the codeacquiring the results of functions from termination events. It willthen be able to continue from the last point.
In our system prototype, the event sourcing is implemented intwo different ways: native and external scheduler.
In the native scheduler, the orchestration code is executed inside aTriggerflow Action. Our Triggerflow system enables then to uploadthe entire orchestration code as an action that interacts with triggersin the system.When Triggerflow detects events that match a trigger,it awakens the native action. This code then relies on event sourcingto catch up with the correct state before continuing the execution.In the native scheduler, the events can be retrieved efficiently fromthe context and thus accelerate the replay process. If no eventsare received in a period, the action will be scaled to zero. Thisguarantees reactive execution of event sourced code.
In the external scheduler, we use IBM PyWren [12], where the or-chestration code is run in an external system, like a Cloud Function.Then, thanks to our Triggerflow service, the function can stop itsexecution each time it invokes for example amap(), recovering theirstate (event sourcing) when it is awaken by our TF-Worker onceall map() function activations finished their execution. Moreover,to use our event sourcing version of PyWren, it is not required anychange in the user’s code. This means that the code is completelyportable between the local-machine and the Cloud, so users candecide where to run their PyWren workflows without requiringany modification. The life cycle of a workflow using an externalscheduler can be seen in Figure 5.
TriggerCondition:
Join
PyWren code
TerminationEvents
map( )
call_async( ) EventsAlready
invoked?
Asynchronous invoke
Continueexecution
Add dynamictrigger
[Yes]
[No]
Stopexecution
Trigger Action: Replay event sourcing code Serverless
Function
Start execution
Figure 5: Life cycle of an event sourcing-enabled workflowas code with IBM-PyWren as external scheduler.
6 VALIDATIONOur experimental testbed consists of 5 client machines with 4 CPUsand 16 GB RAM. On the server side, we deploy Triggeflow on aKubernetes installation (v1.17.3) in a rack of 5 Dell PowerEdgeR430 (2 CPUs Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz - 8Cores/CPU - 32 Logical processors) machines with 16GB RAM. Allof these machines, including the clients, are connected via 10GbEnetwork, and run Ubuntu Server 19.04. For the experiments we useKafka 2.4.0 (Scala 2.13), Redis 5.0.7, KEDA 1.3.0 and Knative 0.12.0.
6.1 Load testThe load test objective is to demonstrate that our system can supporthigh-volume event processing workloads in an efficient way. This ismandatory if we want to support the execution of high performancescientific workflows.
For the first experiment, we want to measure how many eventsper second can be processed by a worker that filters events from amessage broker like Kafka or Redis Streams. Tables 1 and 2 showthe time to process 200K events in a container using different CPUresources (0.25, 0.5, 1 and 2). Noop means that the worker is notdoing any operation on the event. Join refers to aggregated filtersthat process joining for different map jobs with 2000 functions each.As we can see, the performance numbers tell that the system canprocess thousands of events per second.
The second experiment consists of measuring the actual resourceusage (CPU and mem) of 1 Core worker using Redis by injectingdifferent numbers of events per second (form 1K e/s to 12K e/s).Figure 6 shows that, with a constant memory footprint, the CPUresource can cope with increasing number of events per second.
Table 1: Maximum number of processed events/second us-ing Redis Streams
Cores Ev. Noop (s) Noop (e/s) Join (s) Join (e/s)
0.25 200K 56.09 3565 59.83 3342
0.5 200K 28.03 7135 30.25 6611
1 200K 14.17 14114 14.56 13736
2 200K 11.48 17421 12.02 16638
10
Triggerflow: Trigger-based Orchestration of Serverless Workflows DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada
Table 2: Maximum number of processed events/second us-ing Kafka
Cores Ev. Noop (s) Noop (e/s) Join (s) Join (e/s)
0.25 200K 43.89 4556 49.30 4056
0.5 200K 18.01 11104 23.99 8336
1 200K 9.34 21413 11.31 17683
2 200K 5.68 35211 7.56 26450
0 20 40 60 80 100 120 140 160 180Time (s)
0
2000
4000
6000
8000
10000
12000
Even
ts/s
Events/sCPUMemory
0
20
40
60
80
100
CPU
(%)
0
20
40
60
80
100
120
Mem
ory
(MB)
Figure 6: Resource utilization depending on incoming num-ber of events/second (1 Core w/ Redis)
6.2 Auto-scalingIn this case, the objective is to demonstrate that TF-Workers canscale up and down based on the current active workflows. Wedemonstrate here that our Triggerflow implementation on top ofKubernetes and KEDA can auto-scale on demand based on thenumber of events received in different workflows.
For this experiment, we use the entire testbed described above,and set the TF-Worker to use 0.5CPUs and 256MB of RAM. The testconsists of 100 synthetic workflows that send events during somearbitrary seconds, pause the workflow for a while (simulating along-running action), then resume sending events, and finally stopthe workflow. The test works as follows: It first starts 50 workflowsat a constant rate of 2 workflows per second), after 100 seconds itstarts another 50 workflows at a rate of 3 workflows per second,and finally, after 70 seconds, it starts 15 more workflows at a rateof also 3 workflows per second.
The results are depicted in Figure 7. It shows how the TF-Workersscale up when the workflows start to send events, and scale down,even to zero (second 210 and 250), when the active workflows donot produce any event due to a long-running action. We can seehow Triggerflow leverages the KEDA auto-scaler to activate orpassivate workflows. Triggerflow is automatically providing faulttolerance, event persistence, and context and state recovery eachtime a workflow is resumed.
6.3 Completion time and overheadThe validation in this section demonstrates that Triggerflow showscomparable overhead to public Cloud orchestration systems. Wemust be fair here: we are comparing an implementation of Trigger-flow over dedicated and idle resources in our rack against public
multi-tenant cloud services that may be used by thousands of users.The objective is not to claim that our system is better than them,but only to demonstrate that we can reach comparable overheadand performance. Furthermore, most cloud orchestration systemsare not designed for highly concurrent and parallel jobs, which canlimit their performance in those scenarios.
We evaluate the run-time overhead of Amazon’s, IBM’s, andMicrosoft’s orchestration services. We consider as overhead all thetime spent outside the functions being composed, which is easyto measure in all platforms. For a sequential composition д of nfunctions д = f1 ◦ f2 ◦ · · · ◦ fn , it is just:
overhead (д) = exec_time(д) −n∑i=1
exec_time(fi ).
It is important to note that our overhead definition includesthe delays between function invocations, and the execution timeof the orchestration function (for IBM Composer and ADF) or thedelays between state transitions (for ASF). In the case of Triggerflow,the overhead depends on all the services in the architecture—i.e.,latency to access Kafka or Redis, latency to invoke functions in IBMCF, etc.
For all the tests, we use a single TF-Worker with 0.5 CPU Coresand 64MB of RAM, and we list only the results when functionsare in warm state. This implies that we do not consider the coldstart of spawning the function containers and VMs. Our focusis on measuring the overhead of running function compositions.All the tests are repeated 10 times. The results displayed are themedian of those 10 samples and the standard deviation for theerror intervals. Measurements are done during March of 2020. ForIBM Cloud Functions (IBM CF) and AWS Lambda executions, weuse the Python 3.8 runtime. The exception is Azure, which doesnot currently support Python for ADF, but C#. The orchestrationfunctions are implemented in the default language available ineach platform: Node.js for IBM Composer, and C# for ADF. ASForchestration is specified in Amazon States Language (JSON-basedformat) using the console editor.
For the sequential workflows, we quantify the overhead for se-quential compositions of length n in {5, 10, 20, 40, 80}. For simplicity,all the functions in the sequence are the same: a function that sleepsfor 3s, and then returns. For the parallel workflows, we define a work-flow with a single parallel stage composed of n parallel instances ofthe same task, with n ranging from 5 to 320, and doubling each time.This task has a fixed duration of 20 seconds. Consequently, anyexecution of the experiment should ideally last 20 seconds, irrespec-tive of n or the environment. To put it in another way, in an idealsystem with no overhead, the execution time of the n concurrenttasks should match that of a single task. Therefore, we compute theoverhead of the orchestration system by subtracting the fixed timeof a single task, namely 20 seconds, from the total execution time.
6.3.1 DAGs and State Machines. For the DAG and State Machineuse cases, we evaluated our DAG engine interface against IBMComposer, AWS Step Functions, AWS Step Functions Express, andAzure Durable Functions. It is important to state that these resultsare exactly the same we would get for the State Machine imple-mentation over Triggerflow. Sequences and parallel jobs in statemachines and DAGs use the same triggers.
11
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
0
20
40
60
80
Wor
kers
Active workers (pods)
0 100 200 300 400 500Time (seconds)
0
20
40
60
80
Wor
kflo
ws
Active workflows
Figure 7: TF-Worker auto-scaling test using KEDA
5 10 20 40 80
Number of sequential functions
101
102
103
104
105
Ove
rhea
d (m
s)
Triggerflow (IBM CF + Redis)AWS Step Functions ExpressAWS Step Functions
IBM ComposerAzure Durable Functions
Figure 8: DAG overhead comparison for sequences
Sequential workflows. The resultant overhead is represented inFigure 8. In general, Triggerflow’s overhead is higher than in otherorchestration systems. In this case, almost all overhead comes fromthe IBM Cloud Functions invocation latency using its public API,which is about 0.13s. When multiplied by 80 functions, it adds upto approximately 10 seconds of overhead. Amazon Step Functions,however, can use internal trigger protocols rather than the publicAPI, which explains the lower invocation latency. In addition, itseems that using Express Workflows does not provide a consid-erable speed improvement compared to regular ASF when usingsequential workloads, so they are probably not worth the extra costfor this kind of job. IBM Composer is the fastest in sequences, butwith the drawback of its limitation of only 50 transitions per com-position. Finally, Azure Durable Functions present competent over-heads, although being quite unstable for short sequences. This isprobably because ADF is designed and optimized for long-runningsequential workloads.
Parallel workflows. For small-sized compositions (5 to 10), wecan see in Figure 9 that Triggerflow and AWS Step Functions yieldsimilar overhead, both being outperformed by Express Workflowsnonetheless. Express Workflows has a wider range of error though,while regular Step Functions, Triggerflow and IBM Composer aremore stable. Express Workflows perform similarly regardless ofthe number of parallel functions until it reaches about 80, whenits performance drops drastically and the overhead skyrockets forno apparent reason. From 80 functions and up, Express Workflowsand IBM Composer have similar overheads.
5 10 20 40 80 160 320
Number of parallel functions
101
102
103
104
105
Ove
rhea
d (m
s)
Triggerflow (IBM CF + Redis)AWS Step Functions ExpressAWS Step Functions
IBM ComposerAzure Durable Functions
Figure 9: DAG overhead comparison for parallel workflows
From 80 parallel functions and up, we also see that Triggerflowhas the lowest overhead, proving that event-driven function com-position is indeed well suited for parallel function joining.
Azure Durable Functions yield the worst results when used forsmall-sized function joining and is considerably unstable. However,it turns to be equivalent to the other orchestration systems whenjoining a higher number of concurrent functions.
6.3.2 Workflow as Code and Event Sourcing. The objective hereis to evaluate Workflow as Code and event sourcing overheads inTriggerflow compared to Azure Durable Functions. We compareboth sequential and parallel constructs.
For the event sourcing use case, we evaluate both the externalscheduler (IBM-PyWren) and the native scheduler (Triggerflow ac-tion). One the one hand, we measure and compare the performanceof our modified version of IBM-PyWren for Triggerflow with theoriginal version of IBM-PyWren (external scheduler). In this case weevaluate 4 different scenarios: 1) The original IBM-PyWren, whichmakes use of IBM Cloud Object Storage (COS) to store the eventsand results. 2) The modified version of IBM-PyWren for Trigger-flow that stores the results in COS (original IBM-PyWren behavior),but sends the termination events trough a Redis Stream. 3) TheTriggerflow IBM-PyWren that sends the events and results trougha Kafka Topic. And 4) the Triggerflow IBM-PyWren that sends theevents and results trough a Redis Stream.
On the other hand, we evaluate the native Triggerflow eventsourcing scheduler, where the orchestration code is executed aspart of the trigger action. In this case we compare the results againstthe Azure Durable Functions (ADF) service, which is the only FaaSworkflow orchestration service that employs an event sourcingtechnique to execute the workflows.
Sequential workflows. Figure 10 shows the overhead evolutionwhen increasing the length of the sequence. The overhead addedby both the native and external schedulers grows up linearly basedon the number of functions in the sequence. As we can see, theresults are very stable, meaning that the behavior is implementation-related, and not a problem with resources.
For the external scheduler, we can see comparable performancebetween the original IBM-PyWren and our modified version forTriggerflow. Overhead evolves similarly in all scenarios. PyWrenhas to serialize and upload the function and the data to COS before
12
Triggerflow: Trigger-based Orchestration of Serverless Workflows DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada
5 10 20 40 80
104
105 IBM-PyWren COS
TF + IBM-PyWren COS + RedisTF + IBM-PyWren + KafkaTF + IBM-PyWren + Redis
5 10 20 40 80
103
104
TF + IBM CF + RedisAzure DF
Number of sequential functions
Ove
rhea
d (m
s)
Figure 10: Event sourcing overhead comparison for se-quences. PyWren vs TF-PyWren on the left side. Triggerflowvs Azure Durable Functions on the right side.
executing it, creating overhead common for all scenarios. The re-maining overhead comes from the place and the way these eventsare retrieved to recover the state of the execution (event sourcing).This means that the event source service—either COS, Kafka, orRedis—, has direct impact on these results. For example, the maindrawback of using COS in both the original (1) and Triggerflow (2)versions of IBM-PyWren is that they have to individually downloadthe results from COS. This fact substantially increases the totaltime needed to execute a workflow, since for each step it has toretrieve all the previous events. In this case, for a workflow with nsteps, IBM-PyWren has to perform a total of n(n + 1)/2 requests. Incontrast, in the scenarios where IBM-PyWren does not use COS,and stores the events in a Kafka Topic (3) or a Redis Stream (4), itonly needs one request to retrieve all the events in each step. Then,it only needs n requests to these services to complete the executionof a workflow. If we compare scenarios 2 and 3, we see better per-formance if we use a Redis Stream instead of a Kafka Topic. This ismainly caused by the Kafka library, which adds a fixed overhead of0.25s each time the orchestration function is awaken and creates aconsumer. This means that using a Kafka Topic as event store hasa fixed overhead of n ∗ 0.25 seconds.
For the Triggerflow native scheduler, it is important to note thatthe functions are already deployed in the cloud (in contrast withPyWren that has to serialize and upload them each time). More-over, the orchestration code is execute within the TF-Worker thatcontains all the events loaded in memory, so it does not need toretrieve them from the event source (Kafka, Redis) in each step.Compared to ADF, we obtain similar overhead. As stated in theprevious section, the overhead comes mainly from the fact that in-voking an action in IBM CF service takes around 0.13s. This meansthat, for a workflow of n steps, Triggerflow has a fixed overhead ofn ∗ 0.13 when using IBM CF.
Parallel workflows. For this experiment, we evaluate the samescenarios described above. The results are depicted in Figure 11.In this case, for the external scheduler, the original IBM-PyWrenand the Triggerflow IBM-PyWren version have also similar over-head, being scenario 4—which uses Redis as event store—the bestapproach. In the Kafka scenario (3), the overhead of 0.25s described
5 10 20 40 80 160 320102
103
104
IBM-PyWren COSTF + IBM-PyWren COS + RedisTF + IBM-PyWren + KafkaTF + IBM-PyWren + Redis
5 10 20 40 80 160 320101
102
103
104
105
TF + IBM CF + Redis Azure DF
Number of parallel functions
Ove
rhea
d (m
s)
Figure 11: Event sourcing overhead comparison for parallelworkflows. PyWren vs TF-PyWren on the left side. Trigger-flow vs Azure Durable Functions on the right side.
above is negligible, since in this experiment the orchestration func-tion is awaken only once. The main difference in the performancebetween scenarios 1 and 2 is that the original IBM-PyWren is run-ning all the time and polling the results as they are produced. Incontrast, in the Triggerflow version of IBM-PyWren that uses COS(2), the TF-Worker first waits for all activations to finish to awakethe orchestration function, that then has to retrieve all the eventsand results from COS. Finally, with the native scheduler, Triggerflowis faster for parallel workflows compared to ADF.
6.4 Scientific WorkflowsWe adapted a geospatial scientific workflow, that was originally im-plementedwith IBM-PyWren, to workwith our DAGs interface. Theobjective of the workflow is to compute the evapotranspiration andthus the water consumption of the crops from a set of a partitionedgeographical region using the Penman-Monteith equation. Due tothe nature of the workflow, and despite the optimizations applied,the workflow’s execution time is similar to that provided by IBM-PyWren. The main difference lies in the workflow programmingmodel: DAGs are more geared towards dissecting the workflow intoindependent tasks and their dependencies, while PyWren opts fora map-reduce model. An important point in favor of Triggerflow isits automatic and transparent fault tolerance provided by the eventsource and trigger persistent storage. Figure 12 depicts the progres-sion of a workflow run of the scientific workflow, using Kafka asthe event source and Redis for the trigger storage. To check thesystem’s fault tolerance, we intentionally stopped the execution ofthe Triggerflow worker and the IBM-PyWren execution in the 20thsecond of the workflow execution. Triggerflow rapidly recovers thetrigger context from the database and the uncommitted events fromthe event source, and finishes its execution correctly. In contrast,IBM-PyWren stops and loses the state of the workflow, having tore-execute the entire workflow wasting time and resources.
To demonstrate Triggerflow’s ability to introspect triggers withits Rich Trigger API, we have also implemented a service over theDAGs interface that automatically and transparently prewarmsfunction containers on IBM Functions to increase the efficiency andoverall parallelism, reduce total execution time and mitigate strag-gler functions effects in workflows that require high performance
13
DEBS ’20, July 13–17, 2020, Virtual Event, QC, Canada Pedro García López, Aitor Arjona, Josep Sampé, Aleksander Slominski, and Lionel Villard
0 10 20 30 40 50 60
Time (s)
0
100
200
300
400
500
Eve
nts
proc
esse
d
Triggerflow DAG workerSystem failureTriggerflow DAG respawned workerIBM PyWren
Figure 12: Scientific workflow execution progression overtime, with an intended system failure at the 20th second.
0 20 40 60Time (s)
0
50
100
150
200
250
300
Num
ber
of c
oncu
rren
t fun
ctio
ns WarmCold
0 10 20 30 40Time (s)
0
100
200
300
400
500
600
Num
ber
of c
oncu
rren
t fun
ctio
ns WarmCold
Figure 13: (a) Parallelism and total execution time in a se-quential workflow that increases its map size and executiontime every step. (b) Parallelism and total execution time ofa single map task with high concurrency.
and throughput. Figure 13 shows its effects. Thanks to Triggerflow’sinterception mechanisms we can also transparently apply otherdata pre-fetching optimizations in scientific workflows.
7 CONCLUSIONSWe have presented in this paper Triggerflow: a novel building blockfor controlling the life cycle of Cloud applications. As more applica-tions are compiled to the Cloud, our system permits to encode theirexecution flow as reactive triggers in an extensible way. The noveltyof our approach relies on four key aspects: serverless design, ex-tensibility, support for heterogeneous workflows, and performancefor high-volume workloads.
TriggerFlow can become an extensible control plane for deploy-ing reactive applications in the Cloud. We implemented and val-idated different orchestration systems based on State Machines(ASF), Directed Acyclic Graphs (Airflow), and Workflow as Code(PyWren).
Finally, the major limitations about TriggerFlow as an event-based orchestration system are debuggability and developer experi-ence. As an open source project, TriggerFlow would clearly benefitfrom tools and user interfaces to simplify the overall observabilityand life-cycle support of the system.
ACKNOWLEDGMENTSThis work has been partially supported by the EU Horizon 2020programme under grant agreement No 825184.
REFERENCES[1] [n.d.]. Triggerflow. https://github.com/triggerflow/triggerflow.
[2] Ioana Baldini, Perry Cheng, Stephen J. Fink, Nick Mitchell, VinodMuthusamy, Ro-dric Rabbah, Philippe Suter, and Olivier Tardieu. 2017. The Serverless Trilemma:Function Composition for Serverless Computing. In Proceedings of the 2017 ACMSIGPLAN International Symposium on New Ideas, New Paradigms, and Reflectionson Programming and Software (Onward! 2017). 89–103.
[3] Daniel Barcelona-Pons, PedroGarcía-López, Álvaro Ruiz, AmandaGómez-Gómez,Gerard París, and Marc Sánchez-Artigas. 2019. FaaS Orchestration of ParallelWorkloads. In Proceedings of the 5th International Workshop on Serverless Com-puting (WOSC ’19). Association for Computing Machinery, New York, NY, USA,25–30. https://doi.org/10.1145/3366623.3368137
[4] Walter Binder, Ion Constantinescu, and Boi Faltings. 2006. Decentralized orches-tration of composite web services. In 2006 IEEE International Conference on WebServices (ICWS’06). IEEE, 869–876.
[5] Benjamin Carver, Jingyuan Zhang, Ao Wang, and Yue Cheng. 2019. In Searchof a Fast and Efficient Serverless DAG Engine. arXiv preprint arXiv:1910.05896(2019).
[6] Wei Chen, Jun Wei, Guoquan Wu, and Xiaoqiang Qiao. 2008. Developing aconcurrent service orchestration engine based on event-driven architecture. InOTM Confederated International Conferences" On the Move to Meaningful InternetSystems". Springer, 675–690.
[7] Dong Dai, Yong Chen, Dries Kimpe, and Rob Ross. 2018. Trigger-based Incre-mental Data Processing with Unified Sync and Async Model. IEEE Transactionson Cloud Computing (2018).
[8] Sadjad Fouladi, Francisco Romero, Dan Iter, Qian Li, Shuvo Chatterjee, ChristosKozyrakis, Matei Zaharia, and Keith Winstein. 2019. From Laptop to Lambda:Outsourcing Everyday Jobs to Thousands of Transient Functional Containers. In2019 USENIX Annual Technical Conference (USENIX ATC 19). USENIX Association,Renton, WA, 475–488. https://www.usenix.org/conference/atc19/presentation/fouladi
[9] Sadjad Fouladi, Riad S Wahby, Brennan Shacklett, Karthikeyan Vasuki Balasubra-maniam, William Zeng, Rahul Bhalerao, Anirudh Sivaraman, George Porter, andKeith Winstein. 2017. Encoding, fast and slow: Low-latency video processing us-ing thousands of tiny threads. In 14th USENIX Symposium on Networked SystemsDesign and Implementation (NSDI 17). 363–376.
[10] Andreas Geppert and Dimitrios Tombros. 1998. Event-based distributed workflowexecution with EVE. In Middleware’98. Springer, 427–442.
[11] Sangjin Han and Sylvia Ratnasamy. 2013. Large-scale computation not at thecost of expressiveness. In Presented as part of the 14th Workshop on Hot Topics inOperating Systems.
[12] IBM. [n.d.]. IBM PyWren. https://github.com/pywren/pywren-ibm-cloud.[13] Abhinav Jangda, Donald Pinckney, Yuriy Brun, and Arjun Guha. 2019. Formal
foundations of serverless computing. Proceedings of the ACM on ProgrammingLanguages 3, OOPSLA (2019), 1–26.
[14] Eric Jonas, Qifan Pu, Shivaram Venkataraman, Ion Stoica, and Benjamin Recht.2017. Occupy the cloud: Distributed computing for the 99%. In Proceedings of the2017 Symposium on Cloud Computing. ACM, 445–451.
[15] Shannon Joyner, Michael MacCoss, Christina Delimitrou, and Hakim Weath-erspoon. 2020. Ripple: A Practical Declarative Programming Framework forServerless Compute. arXiv preprint arXiv:2001.00222 (2020).
[16] KEDA. [n.d.]. Kubernetes-based event-driven autoscaling. https://keda.sh/.[17] Guoli Li and Hans-Arno Jacobsen. 2005. Composite subscriptions in content-
based publish/subscribe systems. InACM/IFIP/USENIX International Conference onDistributed Systems Platforms and Open Distributed Processing. Springer, 249–269.
[18] Pedro García López, Marc Sánchez-Artigas, Gerard París, Daniel Barcelona Pons,Álvaro Ruiz Ollobarren, and David Arroyo Pinto. 2018. Comparison of faasorchestration systems. In 2018 IEEE/ACM International Conference on Utility andCloud Computing Companion (UCC Companion). IEEE, 148–153.
[19] Maciej Malawski, Adam Gajek, Adam Zima, Bartosz Balis, and Kamil Figiela. inpress. Serverless execution of scientific workflows: Experiments with HyperFlow,AWS Lambda and Google Cloud Functions. Future Generation Computer Systems(in press).
[20] Christopher Mitchell, Russell Power, and Jinyang Li. 2012. Oolong: asynchronousdistributed applications made easy. In Proceedings of the Asia-Pacific Workshopon Systems. ACM, 11.
[21] NormanWPaton and Oscar Díaz. 1999. Active database systems. ACMComputingSurveys (CSUR) 31, 1 (1999), 63–103.
[22] Pnina Soffer, Annika Hinze, Agnes Koschmider, Holger Ziekow, Claudio Di Ciccio,Boris Koldehofe, Oliver Kopp, Arno Jacobsen, Jan Sürmeli, and Wei Song. 2019.From event streams to process models and back: Challenges and opportunities.Information Systems 81 (2019), 181–200.
[23] Erwin Van Eyk, Johannes Grohmann, Simon Eismann, André Bauer, LaurensVersluis, Lucian Toader, Norbert Schmitt, Nikolas Herbst, Cristina Abad, andAlexandru Iosup. 2019. The SPEC-RG Reference Architecture for FaaS: FromMicroservices and Containers to Serverless Platforms. IEEE Internet Computing(2019).
[24] Tim Wagner. [n.d.]. The Serverless Supercomputer. https://read.acloud.guru/https-medium-com-timawagner-the-serverless-supercomputer-555e93bbfa08.
14
