BriskChain: Decentralized Function Composition for High-Performance Serverless Computing

IEEE Access, Volume 12, 2024 | DOI: 10.1109/ACCESS.2024.3439695

Presented by: Adithyan B Raj
Roll Number: 11
Department: Computer Science
Semester: S7
Institution: College of Engineering, Perumon
Guide: Anison Abraham

Original Authors: K. Wang, J. Ma, E. M.-K. Lai | Auckland University of Technology, New Zealand

1 / 18

Content Overview

1. Background

  1. Abstract
  2. Problem Statement
  3. Objectives

2. Foundation

  1. Introduction
  2. Literature Review

3. Proposed Work

  1. Methodology
  2. Architecture
  3. Experimental Setup

4. Findings

  1. Results & Discussion
  2. Conclusion
  3. References

Core Idea: BriskChain enables serverless functions to communicate directly with each other, bypassing the central controller, resulting in significantly reduced workflow overhead.

2 / 18

Abstract

Background Study

  • Serverless computing (FaaS) allows building applications using small, independent functions
  • Complex tasks require combining multiple functions into workflows
  • Workflow engines manage function scheduling and coordination

Specific Problem

  • Current engines use master-side pattern
  • No direct interaction between consecutive functions
  • High scheduling & communication overhead
  • Inefficient for fine-grained workflows

Performance Results

  • >70% lower overhead vs OpenWhisk
  • 50-75% less overhead vs Apache Composer
  • Locality strategy optimizes execution
  • Tested on synthetic & real applications

Future Opportunities

  • Decentralized auto-scaling mechanisms
  • Self-managing container lifecycles
  • Broader cloud computing applications
3 / 18

Problem Statement

The Master-Side Pattern Problem

Every function must communicate through the central controller:

F1 → Controller → F2 → Controller → F3 → Controller → F4

Key Issues:

  • High Scheduling Overhead — Central controller manages every function
  • Communication Bottleneck — Data routed through controller/database
  • Data Size Limits — Cloud vendors impose quotas on I/O data size; transfers >1MB cause bottlenecks
  • Complexity — O(N×K) for FaaS vs O(N) for VMs (N=hosts, K=functions/host)
Research Question: How can consecutive serverless functions communicate directly without routing through a centralized controller?
VM vs FaaS Communication

Figure 1: Communication complexity — VM-based vs FaaS-based systems

4 / 18

Objectives

Primary Objective

To design and implement a decentralized worker-side architecture that reduces communication and scheduling overhead in serverless workflows.

Design Objectives

  • Propose a worker-side pattern where functions manage workflow progression
  • Enable direct data transfer between consecutive functions
  • Implement locality strategy to place workflow functions on the same host

Implementation & Evaluation

  • Build BriskChain as an extension to OpenWhisk platform
  • Compare performance against OpenWhisk and Apache Composer
  • Validate using synthetic and real-world workflow benchmarks

Traditional Approach

F1 → Master → F2 → Master → F3
→

BriskChain Approach

F1 → F2 → F3 (Direct)
5 / 18

Introduction — Serverless Computing

What is Serverless Computing?

  • Cloud computing model where developers deploy functions without managing servers
  • Also known as Function as a Service (FaaS)
  • Cloud platform handles provisioning, scaling, and infrastructure

Function Characteristics

  • Stateless — No persistent state between invocations
  • Fine-grained — Small, focused units of computation
  • Self-contained — Includes all dependencies
  • Event-driven — Triggered by events or requests

Serverless Platforms

Commercial Open Source
AWS Lambda, Google Cloud Functions, Azure Functions, IBM Cloud Functions OpenWhisk, OpenFaaS, Knative
Sandbox Process

Figure 3: Sandbox lifecycle — Load, Inject, Ready

Sandbox: A containerized environment that isolates serverless function execution with required runtime and dependencies.

6 / 18

Literature Review

Work Year Main Contribution Limitation
StepConf [5,6] 2022 Dynamic workflow configuration to meet SLOs; function prewarming Still relies on master-side architecture
O-RDC [7] 2022 Retention-aware container caching across edge nodes Focuses only on cold-start latency reduction
HarmonyBatch [8] 2024 Heterogeneous batching for DNN inference tasks Limited to deep learning workloads
Nightcore [17] 2021 Orchestrates chained functions on same host via gateway Gateway still acts as a local master
FaaSFlow [2] 2022 Worker-side workflow execution with decentralized gateways Still uses gateway proxies for coordination
BriskChain 2024 Fully decentralized function composition with embedded runtime No intermediate masters or gateways required
FaaSFlow

Figure 2: FaaSFlow architecture — still relies on gateway proxies

7 / 18

Methodology — BriskChain Overview

Core Innovation: Worker-Side Pattern

Functions can directly pass control and data to the next function without routing through the central controller.

Master-Side (Traditional)

Controller schedules each function and mediates all communication

↓ BriskChain ↓

Worker-Side (Proposed)

Functions autonomously forward results to subsequent functions

Two Key Components

  • BriskChain Runtime — Embedded in each sandbox; handles workflow execution logic
  • Embedded Controller — Manages workflow scheduling and locality optimization
Substitution Principle: Workflows are treated as single units — no distinction between invoking a workflow vs a single function from user's perspective.
BriskChain Infrastructure

Figure 4: BriskChain Infrastructure

8 / 18

Methodology — System Architecture

OpenWhisk with BriskChain

Figure 5: OpenWhisk extended with BriskChain (shaded components)

Architecture Components

  • OpenWhisk Controller — Core FaaS management
  • BriskChain Embedded Controller — Workflow-specific scheduling
  • BriskChain Runtime — Inside each sandbox
  • Kafka — Message queue
  • CouchDB — Persistent storage

Locality Strategy

All sandboxes of the same workflow are placed on the same host, enabling local communication and eliminating network overhead.

Key Benefit: Database access only needed on errors — normal workflow proceeds entirely through direct sandbox communication.

Fan-In Handling: For scenarios where multiple nodes output to a single next node, BriskChain uses Redis to temporarily store data before transmission.
9 / 18

Methodology — Workflow Processing

Sequence Diagram

Figure 6: BriskChain sequence diagram

Processing Steps

  1. Request — User invokes workflow via NGINX gateway
  2. Fetch — Controller retrieves workflow schema from CouchDB
  3. Token — User receives activation ID
  4. Locality — Controller places sandboxes on same host
  5. Queue — Task dispatched via Kafka
  6. Execute — Functions invoke each other directly (steps 7-9)
  7. Return — Final result stored; user retrieves via token

Critical Insight: Steps 7, 8, 9 occur without any controller involvement — the BriskChain Runtime handles all transitions.

Algorithm Complexity: O(n+m) where n = sequential nodes, m = parallel nodes
10 / 18

Experimental Setup

Setup

Table 1: Hardware and software configuration

Comparison Systems

  • OpenWhisk — Sequential workflows only
  • Apache Composer — All workflow types
  • BriskChain — Proposed system

Benchmark Types

Benchmarks

Figure 7: Synthetic workflow types

Evaluation Metrics

  • Runtime Overhead — Scheduling time + state transition + delays between functions
  • 95th Percentile (P95) — 95% of executions complete faster than this value (measures tail latency)
Note: Results exclude cold start delays. Sequential tests: 100 runs each. Parallel tests: 1000 runs.
11 / 18

Experimental Setup — Real Applications

Travis2slack — CI/CD Notification

Pipeline
Travis2slack

Figure 9: Travis2slack workflow (12 nodes)

Video Transcoding — Parallel Processing

Video Transcoding

Figure 10: Video transcoding workflow (Fan-out/Fan-in)

Process: Split → Parallel transcode → Merge

Test: 100-second MOV → MP4. Video split required due to OpenWhisk's 1-minute function time limit.

12 / 18

Results — Synthetic Workflows

Sequential

Figure 11: Sequential workflow overhead

>70%
Lower overhead than OpenWhisk

Overhead grows linearly with function count

Branch

Figure 12: Branch workflow overhead

0.023s
Average overhead (~1/3 of Composer)

P95 latency: 70% lower than Composer

13 / 18

Results — Parallel Workflows & Payload Scaling

Parallel

Figure 13: Parallel workflow execution time

30 parallel functions: BriskChain overhead is only 1/5 of Composer

Payload

Figure 14: Overhead vs payload size

Scaling: OpenWhisk grows exponentially; BriskChain grows polynomially

50-75%
Less parallel overhead
3x
Better at 1KB payload
Linear
Overhead growth
Local
Communication only
14 / 18

Results — Real Application Performance

Video Results

Figure 15: Video transcoding — performance vs segment duration

Travis Results

Figure 16: Travis2slack — performance vs payload increase

Overhead

Figure 17: Overhead comparison — BriskChain vs Composer

~35%
Better video transcoding
60%
Less video overhead
3.5s
Travis2slack (vs 11.3s)
2x
Payload resilience
15 / 18

Conclusion

Key Contributions

  • Proposed decentralized worker-side pattern for serverless workflows
  • Functions directly transfer state and results to subsequent functions
  • Locality strategy places all workflow sandboxes on same host
  • Implemented as BriskChain — extension to OpenWhisk

Why It Works

  • No repeated controller communication
  • No unnecessary database access
  • Local communication via locality strategy
  • Linear (not exponential) overhead scaling

Performance Summary

Workflow TypeImprovement
Sequential>70% vs OpenWhisk
Branch~67% vs Composer
Parallel (30 fn)80% vs Composer
Video Transcoding35-60% better
Travis2slack70% less overhead

Future Opportunities

  • Decentralized auto-scaling — Containers manage own lifecycle
  • Extension to broader cloud computing scenarios
  • Further efficiency optimizations
16 / 18

References

  1. K. Wang, J. Ma, and E. M.-K. Lai, "BriskChain: Decentralized Function Composition for High-Performance Serverless Computing," IEEE Access, vol. 12, pp. 131313-131322, 2024.
  2. Z. Li, Y. Liu, et al., "FaaSFlow: Enable efficient workflow execution for function-as-a-service," Proc. 27th ACM Int. Conf. ASPLOS, pp. 782-796, 2022.
  3. Z. Li, L. Guo, et al., "The serverless computing survey: A technical primer for design architecture," ACM Computing Surveys, vol. 54, no. 10s, pp. 1-34, 2022.
  4. I. Baldini, P. Cheng, et al., "The serverless trilemma: Function composition for serverless computing," Proc. ACM SIGPLAN Int. Symp., pp. 89-103, 2017.
  5. Z. Wen, Y. Wang, and F. Liu, "StepConf: SLO-aware dynamic resource configuration for serverless function workflows," IEEE INFOCOM, pp. 1868-1877, 2022.
  6. L. Pan, L. Wang, et al., "Retention-aware container caching for serverless edge computing," IEEE INFOCOM, pp. 1069-1078, 2022.
  7. Z. Jia and E. Witchel, "Nightcore: Efficient and scalable serverless computing for latency-sensitive, interactive microservices," ACM ASPLOS, pp. 152-166, 2021.
  8. J. Schleier-Smith, V. Sreekanti, et al., "What serverless computing is and should become: The next phase of cloud computing," Commun. ACM, vol. 64, no. 5, pp. 76-84, 2021.
  9. E. Jonas, J. Schleier-Smith, et al., "Cloud programming simplified: A Berkeley view on serverless computing," arXiv:1902.03383, 2019.
17 / 18

Thank You!

Questions & Discussion

BriskChain: Decentralized Function Composition for High-Performance Serverless Computing

K. Wang, J. Ma, E. M.-K. Lai | IEEE Access, 2024

18 / 18