Richard Patsch

Functions as a Service (FaaS) represents a recent advancement in the cloud computing paradigm, offering a fine-grained deployment model that enables the execution of individual functions on cloud infrastructure. This paradigm shift promises enhanced scalability and potential cost efficiencies by leveraging the sophisticated, geographically distributed infrastructure of cloud service providers, thereby optimizing performance through minimized latency. This paper systematically explores the critical considerations for adopting FaaS, focusing on challenges such as provider selection, performance optimization, inter-function communication, and dependency management. Through a qualitative research methodology, including a comprehensive literature review and experiential insights from serverless computing, this study provides both theoretical insights and practical guidelines. The findings aim to contextualize current academic discussions and niche approaches within the broader scope of FaaS, contributing to a deeper understanding of its implications. Specific recommendations include refactoring existing applications to resolve performance bottlenecks, strategies to avoid vendor lock-in, and minimizing latency in FaaS architectures.

Function as a Service is an established option to deploy event-driven code fragments. Its scalability and cost efficiency through pay-per-use pricing models make it particularly interesting for many use cases. Its isolated nature and statelessness demand rethinking regular software engineering patterns. Communication between several functions is different than it would be in a monolith application. Most functions do not require inter-function exchanges; yet when necessary, options are limited. Leveraging additional services of a cloud service provider increases vendor lock-in. This paper contributes with an approach to enable direct communication between serverless functions, utilizing TCP hole punching. The three largest cloud service providers were tested on applicability and optimal settings. It turned out that TCP hole punching only works with Amazon Web Services, but not in FaaS offerings on Microsoft Azure or Google Cloud. When comparing TCP hole punching with AWS storage service S3, TCP hole punching was significantly faster for data transfers larger than 50 MB. Using the rendezvous server as a relay showed similar performance but is problematic scaling-wise.