Serverless computing simplifies application deployment by removing the need for infrastructure management, with REST APIs being the common interface. Data persistence is essential for serverless applications because serverless functions are stateless and short-lived. To retain information across function executions, relational databases are commonly used to persist data, to ensure continuity, scalability, and reliable management. However, REST can lead to inefficiencies such as data over-fetching and under-fetching, which impact performance. GraphQL is a data query and manipulation language that supports client queries that specify what data is to be retrieved or modified. GraphQL resolvers fetch and transform data as specified by client queries.This paper compares the performance and scalability of GraphQL APIs as a database interface middleware in contrast to REST APIs implemented using serverless functions. We compare a GraphQL API implemented using the managed GraphQL AWS AppSync service, an unmanaged GraphQL API hosted using Apollo Server, and a traditional REST API implemented via the Amazon API Gateway and AWS Lambda. We compare these alternatives using clients implemented with serverless AWS Lambda functions, and also a local machine, an Amazon virtual machine (VM), and a Google VM. Our data APIs accessed a managed Amazon Aurora PostgreSQL cluster populated with the U.S. Centers for Medicare & Medicaid Services (CMS) Open Payments dataset. Our GraphQL implementations show content-dependent performance compared to REST, with Apollo Server demonstrating 25-67% faster average round-trip times vs. REST for most operations, but worse scalability than REST with very high concurrent workloads. Our findings provide practical guidance for developers selecting serverless architectures for GraphQL and REST APIs based on specific application requirements, network conditions, and expected request volumes.

Today’s cloud native applications are often built using a service-oriented architecture supported by many microservices hosted using serverless Function-as-a-Service (FaaS) platforms. The vast majority of serverless function benchmarks and tests are performed using a single-client machine to generate workloads against highly scalable serverless backends. However, single-client test engines can lack sufficient computational resources and network bandwidth to adequately stress serverless backends. Testing tools such as Apache JMeter support orchestrating tests using multiple client nodes, but lack the ability to orchestrate sophisticated tests with distributed workload patterns common with real-world serverless workloads. In this paper, we introduce Distributed FaaSRunner, a distributed test tool which supports the ability to reproduce multi-node serverless workloads using traces derived by ingesting serverless function log files and randomly generated workload traces. We test Distributed FaaSRunner’s ability to precisely reproduce serverless function request dispatch and arrival time using various test cluster configurations. Using globally distributed clients, we predict latency to adjust workload trace event dispatch times to reproduce original request arrival latency. We demonstrate that Distributed FaaSRunner can reproduce both temporal and spatial characteristics of serverless workloads, enabling new capabilities to assess performance of FaaS platforms beyond traditional load testing.

Serverless Function-as-a-Service (FaaS) platforms enable easy deployment and hosting of microservices and have gained great traction among software developers. FaaS platforms, however, only host compute-based functionality of applications resulting in vendor lock-in as applications rely on supporting services known as Backend-as-a-Service (BaaS) offered by the cloud provider for key features such as data persistence. Migrating FaaS code to different cloud providers is made more challenging as a result of these dependencies on vendor-specific services. Cloud service abstraction libraries have been developed to alleviate vendor lock-in, but these libraries were largely developed prior to the advent of serverless computing and have not been evaluated in this context. This paper investigates the use of cloud service abstraction libraries to interface with object storage, a key BaaS used in FaaS code. We investigate the utility of these libraries to improve the portability of code to enable easier migration between cloud providers. We investigate performance of seven FaaS functions on AWS and Google Cloud that use object storage using the Apache jclouds abstraction library vs. platform-specific APIs and assess code quality metrics. We then conduct an empirical study leveraging computer science students enrolled in cloud computing courses to assess the impact of cloud abstraction libraries on FaaS function code portability.

The high demand for energy consumption and the resulting carbon footprint of the cloud pose significant sustainability challenges, as cloud data centers consume vast amounts of energy. The emergence of serverless cloud computing platforms has opened up new avenues for more sustainable cloud computing. Serverless Function-as-a-Service (FaaS) cloud computing platforms facilitate deploying applications as decoupled microservices to leverage automatic rapid scaling, high availability, fault tolerance, and on-demand pricing. The absence of always-on hosting costs associated with virtual machines enables serverless functions to be deployed with many different function configurations and cloud regions to achieve high performance, low network latency, and reduced costs. In this paper, we investigate the utility of a global sky computing platform where serverless resources are aggregated between up to 19 distinct cloud regions. We prototype a serverless load distribution system to distribute client requests across serverless aggregations to minimize performance objectives, including network latency, runtime, hosting costs, and carbon footprint. To evaluate our serverless distribution system's ability to meet performance objectives, we continuously executed large experiments across 19 regions around the world from November 2022 through March 2023. Our serverless load distribution approach using aggregated resources reduced the carbon intensity of a globally distributed serverless application by up to 99.8%, network latency by 65%, or hosting costs by 58% by optimizing function routing to deployments with optimal hardware configurations.

The Sky Computing vision represents a unified multi-cloud environment where applications can be deployed to utilize resources from different cloud regions, resource configurations, and cloud providers. Serverless computing platforms have recently emerged, offering automatic elastic scaling, high performance, and reduced costs but often utilize proprietary deployment tools and services locking users into platform-specific services. This research aims to apply Sky Computing to serverless computing platforms offered by major cloud providers such as Amazon Web Services, Google Cloud, Azure, and more. This research will build a serverless sky architecture to enable the aggregation of serverless resources to achieve service-level objectives such as low hosting costs, high performance, fault tolerance, high throughput, and low carbon footprint. The research will focus on evaluating the performance implications of serverless aggregation (Thrust-1), design and evaluation of Sky Computing architectures and aggregation strategies (Thrust-2), and finally autonomous resource aggregation for intelligent self-management of applications deployed to the sky (Thrust-3).

Serverless Function-as-a-Service (FaaS) platforms often abstract the underlying infrastructure configuration into the single option of specifying a function's memory reservation size. This resource abstraction of coupling configurations options (e.g. vCPUs, memory, disk), combined with the lack of profiling, leaves developers to make ad hoc decisions on how to configure functions. Solutions are needed to mitigate exhaustive brute force searches of large parameter input spaces to find optimal configurations which can incur high costs. To address these challenges, we propose CPU Time Accounting Memory Selection (CPU-TAMS). CPU-TAMS is a workload agnostic memory selection method that utilizes CPU time accounting principles and regression modeling to recommend memory settings that reduce function runtime and subsequently, cost. Comparing CPU-TAMS to eight existing selection methods, we find that CPU-TAMS finds maximum value memory settings with only 8% runtime and 5% cost error compared to brute force testing while only requiring a single profiling run to evaluate function resource requirements. We adapt CPU-TAMS for use on four commercial FaaS platforms demonstrating efficacy to optimize function memory configurations where platforms feature heterogeneous infrastructure management policies.

Hypervisors used to implement virtual machines (VMs) for infrastructure-as-a-service (IaaS) cloud platforms have undergone continued improvements for the past decade. VM components including CPU, memory, network, and storage I/O have evolved from full software emulation, to paravirtualization, to hardware virtualization. While these innovations have helped reduce performance overhead when simulating a computer, considerable performance loss is still possible in the public cloud from resource contention of co-located VMs. In this paper, we investigate the extent of performance degradation from resource contention by leveraging well-known benchmarks run in parallel across three generations of virtualization hypervisors. Using a Python-based test harness we orchestrate execution of CPU, disk, and network I/O bound benchmarks across up to 48 VMs sharing the same Amazon Web Services dedicated host server. We found that executing benchmarks on hosts with many idle Linux VMs produced unexpected performance degradation. As public cloud users are interested in avoiding resource contention from co-located VMs, we next leveraged our dedicated host performance measurements as independent variables to train models to predict the number of co-resident VMs. We evaluated multiple linear regression and random forest models using test data from independent benchmark runs across 96 vCPU dedicated hosts running up to 48 x 2 vCPU VMs where we controlled VM placements. Multiple linear regression over normalized data achieved R2=.942, with mean absolute error of VM co-residency predictions of ±1.61 VMs. We then leveraged our models to infer VM co-residency among a set of 50 VMs on the public cloud, where co-location data is unavailable. Here models cannot be independently verified, but results suggest the relative occupancy level of public cloud hosts enabling users to infer when their VMs reside on busy hosts. Our results characterize how recent hypervisor and hardware advancements are addressing resource contention, while demonstrating the potential to leverage co-located benchmarks for VM co-residency prediction in a public cloud.

Modern day analyses of biomedical data typically involves a series of computational tasks called workflows. Each of these modules could be written by different laboratories and thus, potentially requires different computing environments. Reproducible analyses of biomedical data is a growing field of interest [1]. This makes it important to develop tools to facilitate analyses in a reproducible manner. Software containers have been used to increase reproducibility in bioinformatics analyses [2]. However, these software containers often use command line tools, requiring expertise that make them inaccessible to many biomedical scientists.

SUMMARY: For many next generation-sequencing pipelines, the most computationally intensive step is the alignment of reads to a reference sequence. As a result, alignment software such as the Burrows-Wheeler Aligner is optimized for speed and is often executed in parallel on the cloud. However, there are other less demanding steps that can also be optimized to significantly increase the speed especially when using many threads. We demonstrate this using a unique molecular identifier RNA-sequencing pipeline consisting of 3 steps: split, align, and merge. Optimization of all three steps yields a 40% increase in speed when executed using a single thread. However, when executed using 16 threads, we observe a 4-fold improvement over the original parallel implementation and more than an 8-fold improvement over the original single-threaded implementation. In contrast, optimizing only the alignment step results in just a 13% improvement over the original parallel workflow using 16 threads. AVAILABILITY AND IMPLEMENTATION: Code (M.I.T. license), supporting scripts and Dockerfiles are available at https://github.com/BioDepot/LINCS_RNAseq_cpp and Docker images at https://hub.docker.com/r/biodepot/rnaseq-umi-cpp/. SUPPLEMENTARY INFORMATION: Supplementary data are available at Bioinformatics online.

As cloud architectural platforms evolve, understanding how to maximize cost efficiency of application deployments is difficult without the ability to assess cost vs. performance tradeoffs of new technology platforms. With the advent of container-based computing, new opportunities for improving resource utilization efficiency have emerged. Compared to traditional cloud application deployments hosted on dedicated virtual machines (VMs), deployments to container clusters can save significant resources by aggregating application deployments to a shared pool of VMs. However, the degree of savings is often uncertain, and hobbled by excessive container resource allocation reflective of engineers' instincts to treat them as individual VMs. As practitioners are accustomed to performing application deployments to VMs, we are especially interested in understanding if VM resource allocations (e.g. CPU, RAM, disk) are appropriate for container deployments. In this research, we set out to analyze gaps between memory allocation and memory utilization for application deployments to container clusters.

Serverless computing platforms provide function(s)-as-a-Service (FaaS) to end users while promising reduced hosting costs, high availability, fault tolerance, and dynamic elasticity for hosting individual functions known as microservices. Serverless Computing environments, unlike Infrastructure-as-a-Service (IaaS) cloud platforms, abstract infrastructure management including creation of virtual machines (VMs), operating system containers, and request load balancing from users. To conserve cloud server capacity and energy, cloud providers allow hosting infrastructure to go COLD, deprovisioning containers when service demand is low freeing infrastructure to be harnessed by others. In this paper, we present results from our comprehensive investigation into the factors which influence microservice performance afforded by serverless computing. We examine hosting implications related to infrastructure elasticity, load balancing, provisioning variation, infrastructure retention, and memory reservation size. We identify four states of serverless infrastructure including: provider cold, VM cold, container cold, and warm and demonstrate how microservice performance varies up to 15x based on these states.

Abstraction of physical hardware using infrastructure-as-a-service (IaaS) clouds leads to the simplistic view that resources are homogeneous and that infinite scaling is possible with linear increases in performance. Hosting scientific modeling services using IaaS clouds requires awareness of application resource requirements and careful management of cloud-based infrastructure. In this paper, we present multiple methods to improve public cloud infrastructure management to support hosting scientific model services. We investigate public cloud VM-host heterogeneity and noisy neighbor detection to inform VM trial-and-better selection to favor worker VMs with better placements in public clouds. We present a cpuSteal noisy neighbor detection method (NN-Detect) which harnesses the cpuSteal CPU metric to identify worker VMs with resource contention from noisy neighbors. We evaluate potential performance improvements provided from leveraging these techniques in support of providing modeling-as-a-service for two environmental science models.

Deployment of service oriented applications (SOAs) to public infrastructure-as-a-service (IaaS) clouds presents challenges to system analysts. Public clouds offer an increasing array of virtual machine types with qualitatively defined CPU, disk, and network I/O capabilities. Determining cost effective application deployments requires selecting both the quantity and type of virtual machine (VM) resources for hosting SOA workloads of interest. Hosting decisions must utilize sufficient infrastructure to meet service level objectives and cope with service demand. To support these decisions, analysts must: (1) understand how their SOA behaves in the cloud; (2) quantify representative workload(s) for execution; and (3) support service level objectives regardless of the performance limits of the hosting infrastructure. In this paper we introduce a workload cost prediction methodology which harnesses operating system time accounting principles to support equivalent SOA workload performance using alternate virtual machine types. We demonstrate how the use of resource utilization checkpointing supports capturing the total resource utilization profile for SOA workloads executed across a pool of VMs. Given these workload profiles, we develop and evaluate our cost prediction methodology using six SOAs. We demonstrate how our methodology can support finding alternate infrastructures that afford lower hosting costs while offering equal or better performance using any VM type on Amazon's public elastic compute cloud.

Abstraction of physical hardware using infrastructure-as-a-service (IaaS) clouds leads to the simplistic view that resources are homogeneous and that infinite scaling is possible with linear increases in performance. Support for autonomic scaling of multi-tier service oriented applications requires determination of when, what, and where to scale. "When" is addressed by hotspot detection schemes using techniques including performance modeling and time series analysis. "What" relates to determining the quantity and size of new resources to provision. "Where" involves identification of the best location(s) to provision new resources. In this paper we investigate primarily "where" new infrastructure should be provisioned, and secondly "what" the infrastructure should be. Dynamic scaling of infrastructure for service oriented applications requires rapid response to changes in demand to meet application quality-of-service requirements. We investigate the performance and resource cost implications of VM placement when dynamically scaling server infrastructure of service oriented applications. We evaluate dynamic scaling in the context of providing modeling-as-a-service for two environmental science models.

Service isolation, achieved by deploying components of multi-tier applications using separate virtual machines (VMs), is a common "best" practice. Various advantages cited include simpler deployment architectures, easier resource scalability for supporting dynamic application throughput requirements, and support for component-level fault tolerance. This paper presents results from an empirical study which investigates the performance implications of component placement for deployments of multi-tier applications to Infrastructure-as-a-Service (IaaS) clouds. Relationships between performance and resource utilization (CPU, disk, network) are investigated to better understand the implications which result from how applications are deployed. All possible deployments for two variants of a multi-tier application were tested, one computationally bound by the model, the other bound by a geospatial database. The best performing deployments required as few as 2 VMs, half the number required for service isolation, demonstrating potential cost savings with service consolidation. Resource use (CPU time, disk I/O, and network I/O) varied based on component placement and VM memory allocation. Using separate VMs to host each application component resulted in performance overhead of ~1-2%. Relationships between resource utilization and performance were harnessed to build a multiple linear regression model to predict performance of component deployments. CPU time, disk sector reads, and disk sector writes are identified as the most powerful performance predictors for component deployments.