Stateful Function-as-a-Service at the Edge

In FaaS, an application is decomposed into functions. When functions are stateful, they typically need to remotely access the state, via an external service. On the one hand, this approach makes function instances equivalent to one another, which provides great resource efficiency. On the other hand, accessing a remote state causes increased delays and network traffic, which makes FaaS less attractive to edge computing systems. We propose to generalize FaaS by allowing functions to alternate between remote-state and local-state phases, depending on internal and external conditions, and dedicating a container with persistent memory to functions when in a local-state phase. We present initial results showing that this simple yet powerful pattern allows to better utilize the available resources, which are scarce on edge nodes, while significantly reducing tail latencies, which is key to enable new applications based on real-time Machine Learning (ML), e.g., in smart vehicles and smart factory scenarios. MONOLITHIC application design has shown its downsides in terms of scalability, maintainability, and agility. The current trend is to decompose complex applications into small pieces of code called microservices, each focusing on a specific aspect of the overall application. Microservices are typically instantiated within lightweight environments, e.g., containers. Function as a Service (FaaS) leverages microservices (which in FaaS are called functions) as a starting point to build enhanced cloud computing systems [1]. FaaS indeed abstracts the operational logic away from function developers, such that they do not need to care about function deployment, scaling, and lifecycle management. Besides, functions run according to an event-based pattern, and users only pay for what they actually use, with fine granularity. In this context, consecutive invocations of a function from the same client can be independent from one another or, more often, can form a session with an associated state that must persist across multiple invocations until the session ends [2]. With traditional FaaS for cloud computing systems, functions typically need to remotely access this state at each invocation, via an external service such as a database: we refer to these functions as remote-state functions. This is depicted 2 © 2021 IEEE Computer in the top-left image of Figure 1, whose notation will be explained in the next section. Following this approach, different instances of the same remote-state function are equivalent to one another, as they do not retain any state locally (state is download at each invocation, updated, and uploaded again to the external service). Therefore, FaaS providers can optimize their infrastructure, transparently to the users, as (i) different users can share the same function instance, (ii) consecutive invocations from the same user can be forwarded to different function instances, and (iii) resources allocated to inactive instances can be freed after a short period of idle time. The first company to propose a FaaS platform was Amazon with AWS Lambda. Since then, all the top cloud vendors announced their FaaS solutions, e.g., Microsoft Azure Functions, Google Cloud Run, IBM Cloud Functions, and Cloudflare Workers. Open-source platforms, to be executed on private compute infrastructures, are also available, such as Apache OpenWhisk, OpenFaaS, Kubeless, and Knative. Further information on the most prominent FaaS platforms can be found in [3]. Although it was initially designed for cloud environments, FaaS is gradually drawing interest as a viable option for edge computing, as well [4]. Edge computing extends the cloud toward the edge of the network, hosting cloud-like services in close proximity to the end users, e.g., on cellular base stations [5]. This proximity leads to many advantages, the most important of which is the reduced latency, which is essential to a vast number of emerging applications, such as real-time Internet of Things (IoT), mobile Virtual Reality (VR)/Augmented Reality (AR), and connected vehicle applications [6], [7]. Big IT companies have started investing in FaaS for edge computing, extending their FaaS platforms toward the edge of the network, for example Amazon IoT Greengrass, Microsoft Azure IoT Edge, and IBM Edge Functions. Notwithstanding these recent efforts toward FaaS for edge computing, there is still hesitation to widely adopt this novel paradigm. This is due to the cloud-oriented design of FaaS, which does not always suit the distinguishing characteristics of edge applications. The most important design assumption of FaaS that is violated by its expansion toward the edge is that functions access a remote state. In cloud-only environments, this approach affects performance only slightly because both function instances and session state are hosted by servers that are physically located in the same data center. However, when function instances run at the edge (as shown in the centerleft image of Figure 1), accessing a remote state may cause significant service latency and network traffic, at risk of nullifying edge computing advantages. To overcome the above limitation, local-state functions are coming into the picture [8]. As depicted in the bottom-left image of Figure 1, these functions keep the state locally. On the one hand, local-state functions avoid the delays and traffic caused by accessing state from an external storage service. However, on the other hand, they do not experience the same cost-efficiency and flexibility of remote-state functions. Localstate instances are indeed not equivalent to one another, as each is dedicated to a specific user or application session, for which it provides data access in a private and persistent manner. Besides, local-state function instances are not triggered on demand; instead, they are long-running to retain state across invocations. The following are examples of local-state functions in commercial FaaS platforms: (i) Microsoft entity functions [9]; (ii) Cloudflare durable objects [10]; and (iii) Amazon long-lived functions [11]. Today, the choice on whether a given function should follow a remote-state vs. local-state pattern is made at design time, and migrating from one pattern to another in production can be very expensive, since it involves changing the set of employed services (adapting to new Application Programming Interfaces (APIs), switching contracts, using a different Software Development Kit (SDK)). What is worse, during development the programmer may not even know whether the logic of the code they are implementing will be executed at the edge or in the cloud, so making an informed choice could be just impossible. In this work, we advocate that such a dichotomy between remote-state and local-state should not exist, but rather a function in a FaaS environment should be able to adapt dynamically, i.e., changing its behavior from remotestate to local-state and vice versa, depending on both internal and external factors. This approach