Location, Proximity, Affinity – The key factors in FaaS

Abstract

The Function-as-a-Service paradigm emerged not only as a pricing technique, but also as a programming model promising to simplify developing to the cloud. Interestingly, while placing functions across hosts under the service platform is believed to be flexible, currently the available platforms pay little attention to co-locate connected functions, or data with the respective processing function in order to improve performance. Even though the local function invocation and data access might be an order of magnitude faster than their remote intra-cloud counterparts. In this paper, we therefore propose a Function-asa- Service platform design that reaps the performance benefits of co-location. We build the platform on WebAssembly, a secure and flexible tool for efficient local function invocations, and on a distributed in-memory database, which allows arbitrary data placement. On top we advocate smart placement strategies for function executions and data, decoupled from the functions. Hence we envision good horizontal scaling of functions while keeping the experienced processing latency to that of a single machine case.

The Shape of Your Cloud: How to Design and Run Polylithic Cloud Applications

“…Besides the pricing aspects, resource footprint and latency overhead have also been in the focus of the research community; particularly the cold-start latency FaaS platforms suffer from when a new VM or container has to be launched to run the invoked task [12]. The size of the image to mount, the number of libraries and dependencies all have an impact on this latency [4]. Even though communication is significantly faster the closer the parties are (e.g., same data center, same rack, same server machine, same process), currently available platforms miss out on co-locating entities that often communicate with each other [4].…”

“…The size of the image to mount, the number of libraries and dependencies all have an impact on this latency [4]. Even though communication is significantly faster the closer the parties are (e.g., same data center, same rack, same server machine, same process), currently available platforms miss out on co-locating entities that often communicate with each other [4].…”

“…Second, distributed applications, often used in a cloud environment, have to count with an inter-component invocation delay. Third, the latter are exacerbated by the inter-node network latency of the data center, if application components are orchestrated to run on different compute nodes [4].…”

Survey on Placement Methods in the Edge and Beyond

“…Function requests arrive frequently, demand various resource amounts and a great level of elasticity. Therefore, by its nature the FaaS service platform must apply an online placement method, probably with affinity constraints to consider in order to collocate functions that may invoke each other [190]. Inherent to the FaaS concept, input data or internal function state are often externalized, hence the stateless operation.…”

“…Inherent to the FaaS concept, input data or internal function state are often externalized, hence the stateless operation. As network delay might cause serious QoS degradation when remote data must be accessed by the functions invoked in the FaaS platform, the placement of those is of paramount importance too [190]- [192]. We advocate the emergence of joint placement policies of functions and their respective states in edge systems in the near future.…”