Function-as-a-service (FaaS) is a popular serverless computing paradigm for event-driven functions that elastically scale on public clouds. FaaS workflows (e.g.,AWS Step FunctionsandAzure Durable Functions), are composed from FaaS functions (e.g., AWS Lambda and Azure Functions) to build practical applications. But, the complex interactions between functions in the workflow and limited visibility into the internals of proprietary FaaS platforms are major impediments to analyzing a FaaS workflow's performance. While several works characterize FaaS platforms to derive such insights, or offer FaaS Workflow benchmarks, there is a lack of a principled of FaaS workflow platforms, which have unique scaling, performance and costing behavior influenced by the platform design, dataflow and workloads. In this article, we perform extensive evaluations of three popular FaaS workflow platforms from AWS and Azure, running 25 micro-benchmark and application workflows over$139k$invocations. Our detailed analysis confirms some conventional wisdom but also uncovers unique insights on the function execution, workflow orchestration, inter-function interactions, cold-start scaling and monetary costs. Our observations help developers better configure and program these platforms, set performance and scalability expectations, and identify research gaps on enhancing the platforms.

Quantum computing is entering the mainstream as part of cloud offerings, where it serves as a special-purpose accelerator in larger applications. However, it is still challenging for developers and researchers to design, build and manage the resources for Hybrid Quantum-Classical (HQC) applications that include both classical logic (x86, ARM) and quantum circuit blocks, and run across both traditional and quantum processors. Further, quantum hardware is available on public cloud and even on-premise as private clouds, with varying capabilities, costs and queue times. Further, such quantum circuits also expose optimization methods that offer cost, time, accuracy and parallelism trade-offs. So, there is a compelling for easy composition of HQC applications that can be effortlessly and efficiently deployed on hybrid clouds. In this paper, we propose a framework to intuitively compose and deploy “zero-touch” quantum-classical Function-as-a-Service (FaaS) workflows through various workflow patterns that leverage diverse cloud system (workflow partitioning, adaptive polling) and quantum (circuit cutting, qubit reuse) optimizations. These utilize our XFaaS FaaS workflow framework for hybrid cloud deployments on AWS and Azure, and IBM Qiskit SDK for the quantum circuit toolchain. We also offer detailed experimental profiling of these optimizations for realistic and synthetic HQC applications on real clouds, and on real and simulated quantum hardware, and analyze the benefits of cloud system and quantum circuit optimizations. Our results demonstrate up to 53 % improvement in time and 80 % in cost when quantum circuit optimization on hardware is used in conjunction with dynamic fan-out.

Functions-as-a-Service (FaaS) is a widely used serverless computing abstraction that helps developers build applications using event-driven, stateless functions that execute on the cloud. Commercial FaaS platforms such as AWS Lambda and Azure Functions offer elastic auto-scaling and invocation-level billing to ease operations. Applications are often composed as a dataflow of FaaS functions that are orchestrated by FaaS workflow platforms such as AWS Step Functions or Azure Durable Functions. However, the proprietary nature of FaaS platforms on public clouds means that their internals are less understood. While benchmarks to characterize FaaS platforms exist, none are available for a principled evaluation of FaaS workflow platforms. Further, they are less configurable and often limited to simple workloads and a single cloud provider. We address this limitation by proposing XFBench, an end-to-end automated benchmarking framework for FaaS workflows that works across clouds, and an accompanying function, workflow, and workload suite. The user provides a generic definition of the workflow and workload for benchmarking, and XFBench automatically deploys the workflows across multiple cloud platforms, generates client requests, and profiles the execution. We validate XFBench with realistic workflows and workloads on AWS and Azure platforms in different global regions to offer early insights into understanding the inter-function communication, function execution time, and cold start scaling.

Functions as a Service (FaaS) have gained popularity for programming public clouds due to their simple abstraction, ease of deployment, effortless scaling and granular billing. Cloud providers also offer basic capabilities to compose these functions into workflows. FaaS and FaaS workflow models, however, are proprietary to each cloud provider. This prevents their portability across cloud providers, and requires effort to design workflows that run on different cloud providers or data centers. Such requirements are increasingly important to meet regulatory requirements, leverage cost arbitrage and avoid vendor lock-in. Further, the FaaS execution models are also different, and the overheads of FaaS workflows due to message indirection and cold-starts need custom optimizations for different platforms. In this paper, we propose XFaaS, a cross-platform deployment and orchestration engine for FaaS workflows to operate on multiple clouds. XFaaS allows “zero touch” deployment of functions and workflows across AWS and Azure clouds by automatically generating the necessary code wrappers, cloud queues, and coordinating with the native FaaS engine of the cloud providers. It also uses intelligent function fusion and placement logic to reduce the workflow execution latency in a hybrid cloud while mitigating costs, using performance and billing models specific to the providers based in detailed benchmarks. Our empirical results indicate that fusion offers up to ≈75 % benefits in latency and ≈57% reduction in cost, while placement strategies reduce the latency by ≈ 24%, compared to baselines in the best cases.