Interim Report on Adaptive Event Dispatching in Serverless Computing Infrastructures

TL;DR

This paper explores how adaptive event dispatching considering locality and dependencies can enhance resource efficiency in serverless computing platforms, addressing current limitations in data locality optimization.

Contribution

It proposes the importance of adaptive event dispatching in serverless platforms and highlights the gap in existing systems' data locality optimization.

Findings

Existing serverless platforms lack data locality optimization.

Distributed computing scheduling methods can improve resource efficiency.

Adaptive dispatching can reduce latency and resource usage.

Abstract

Serverless computing is an emerging service model in distributed computing systems. The term captures cloud-based event-driven distributed application design and stems from its completely resource-transparent deployment model, i.e. serverless. This work thesisizes that adaptive event dispatching can improve current serverless platform resource efficiency by considering locality and dependencies. These design contemplations have also been formulated by Hendrickson et al., which identifies the requirement that "Serverless load balancers must make low-latency decisions while considering session, code and data locality". This interim report investigates the economical importance of the emerging trend and asserts that existing serverless platforms still do not optimize for data locality, whereas a variety of scheduling methods are available from distributed computing research which have proven to increase resource efficiency.

Figures

Full text

1. 1 Introduction

2. 2 Project Background

3. 2.1 Serverless Computing

4. 2.2 Decomposition Performance Challenges

5. 2.3 Adaptive Event Dispatching

6. 3 Initial Survey

7. 3.1 Economical aspects

8. 3.1.1 Cloud service model

9. 3.1.2 Cloud economy

10. 3.1.3 Data center utilization

11. 3.2 Review of Serverless Architectures

12. 3.2.1 OpenLambda

13. 3.2.2 IBM OpenWhisk

14. 3.2.3 OpenFaaS

15. 3.2.4 Serverless Prototype

16. 4 Objectives

17. 5 Methods

18. 5.1 Data-awareness

19. 5.2 Distributed scheduling

20. 5.3 Event clustering

21. 6 Project timeline

22. 7 Deliverables

1 Introduction

Serverless computing is an emerging service model in distributed computing systems. The term captures cloud-based event-driven distributed application design and stems from its completely resource-transparent deployment model, i.e. serverless. This work thesisizes that adaptive event dispatching can improve current serverless platform resource efficiency by considering locality and dependencies. These design contemplations have also been formulated by Hendrickson et al in [27], which identifies the requirement that “Serverless load balancers must make low-latency decisions while considering session, code and data locality”. This interim report investigates the economical importance of the emerging trend and asserts that existing serverless platforms still do not optimize for data locality, whereas a variety of scheduling methods are available from distributed computing research which have proven to increase resource efficiency.

This report is structured as follows. Section 2 gives a thorough background of the topic. The initial survey provided in section 3 assesses the economical aspects (3.1) of improving serverless event dispatching and asserts the requirement for adaptive event dispatching in existing serverless platforms (3.2). Objectives for the project are provided in section 4. Section 5 discusses methods used in other areas that can be applied in the design of a novel adaptive event dispatching. The remainder provides a project task plan in section 6 and concludes with the expected deliverables of the project in section 7.

2 Project Background

Serverless has recently emerged as a trend in Cloud computing. Its Function-as-a-Service model envisions applications to be partitioned (over-decomposed) and designed as event-driven applications. The event-driven design paradigm[42][34] has already been adopted to develop highly elastic components for self-managing applications[16]. Serverless may give way to reactive programming for software[15] that would automatically scale on Cloud platforms. A background on the serverless trend is given below (2.1).

But the trending decomposition of application components into smaller functions bears the risk of significant overhead because in its plain form, every invocation is encapsulated with request authorization, event dispatching, code loading and heavy remote data access which raises performance challenges discussed in section 2.2. Section 2.3 explains the pending change from allocation placement to event (task) scheduling on shared Cloud infrastructures.

2.1 Serverless Computing

Serverless computing has only recently appeared. Within a short series of announcements, Cloud providers alike have released offerings that facilitate event-driven programming. Amazon Lambda[2] first became generally available (9/4/15), Google released Cloud Functions[8] (11/02/16), IBM had announced OpenWhisk[10] (22/02/16), and Microsoft announced Azure Functions[2] (31/03/16). At the same time, research papers emerged at prominent venues, such as the OpenLambda[27] implementation at HotCloud’16 and a review of Cloud event programming[34] at CLOUD’16. The topic has recently drawn attention of computer science research worldwide. By 2017, the First International Workshop on Serverless Computing (WoSC) has been launched, several national developer conferences are themed around serverless computing (e.g. Serverless London, O’Reilly Software Architecture Conference), and others have adopted the topic to their calls for paper (e.g. WS-REST). Apart from the acclaimed praise, serverless can be considered a serious trend in Cloud computing.

The serverless hype yields expectations for fully automated operations[19], better resource utilization, and is promoted a programming model for event-driven IoT applications [25][3][20]. Following the advancements of continuous integration/contiuous development, the event-based function programming paradigm fits the software engineering trend to continuously develop, test and release small software extensions, because it provides every function with its individual management lifecycle, thereby making the software development even more transparent to operations and may help to close remaining gaps in DevOps automation to achieve the controversial target of NoOps[26].

Serverless continues the microservices trend that segments traditional servers into scalable, distributed, fault-tolerant components. Serverless functions are considered even smaller than microservices. Their small size makes the boot time of individual functions very short because it allows for individual hosts to only load the required code and it allows for fast reconfigurations of the deployment.

Related trends exist in Big Data parallel and distributed computing systems that allow to deploy custom user-defined functions. Some distributed systems already leverage data locality to reduce both communication cost and delay. For example, Apache Hadoop schedules map tasks at data replica locations of its distributed file system. Spark schedules and distributes parallelizable stages of a task (directed acyclic graph) on servers that host the partitions of a resilient distributed dataset (RDD). In some cases the scheduler may even delay single tasks in hope for a CPU to free up rather than moving data across the network. More recently, a Big Data company has announced serverless computing based on Apache Spark[7].

2.2 Decomposition Performance Challenges

Serverless computing would decompose an application into event-triggered function code and externalize state, while abstracting completely from the machine configuration.

Decomposing the code of a program requires the computing infrastructure to dispatch events across servers. The executing node would then have to communicate to obtain related code and data, load code, contact other services during execution and store or return results. This is a severe overhead as compared to a local function call and puts serverless platforms to a performance challenge. Moreover, events may be part of distributed workflows. The application decomposition bears the risk of having any two related events run on different machines such that they need to synchronize remotely on the shared context data.

To optimize the performance of event-driven serverless function execution, code and data would ideally be readily cached at the executing host. In existing microservice frameworks, a messaging middleware dispatches named events to execution hosts while a data backend provides means to access shared data. Here, the application needs to correlate both the request stream and data accesses to optimize efficiency.

Because serverless functions are required to be stateless, the application state needs to be externalized. Current serverless frameworks use distributed key-value stores. These provide high availability and fault-tolerance by employing replication and key hashing for pseudo-random distribution. However, this practice counteracts data colocation and is difficult to circumvent without jeopardizing data load balancing. Also, distributed message queues are employed for scalable event dispatching. The most prominent is Kafka (for its reliability and scalability) which effectively has the message producer select a consumer partition, whereas in other systems, message brokers allow for message routing based on message contents. Ideally, events should be dispatched to hosts where required data context is already cached to speed-up function execution, but it seems that current platforms are not standing up to the performance challenge.

2.3 Adaptive Event Dispatching

In commercial serverless computing environments, various sorts of events can be used to trigger a function, e.g. the creation, update or deletion of a data element (data access), a system event, an application event or by explicit invocation (web requests, messages). The traditional on-demand model (VM and microservices alike) allocates isolated compute capacity for network-based services, i.e. service instances are stateful, stationary control flows that communicate with each other. This notion of long-running instances has had its implications on placement of allocation requests. For example, [21] approaches the Cloud service placement as a capacitated host and network allocation problem and formalizes it as a combination of the general assignment and the facility location problem. A different approach [17] assumes a hierarchically organized infrastructure and formalizes a minimum cost mixed-cast flow problem that can be solved using linear integer programming, because of the insights into the application’s data flow model. A huge body of research covers online and offline optimization of the VM/service placement ([32]).

Placement decisions are still a part of serverless platforms, only computing resources are not actively consumed until events are dispatched. Serverless functions are fully data and execution location-transparent, so the workload distribution is effectively determined by event dispatching. This makes event dispatching a key component in workload scheduling that needs to consider the cost in establishing an execution context when adapting the workload distribution.

3 Initial Survey

The terminology of the emerging Serverless hype still lacks clear definition as assessed in [24] to whether it is a subset of event-driven computing or a location transparency paradigm. While many implementation efforts target the commercialization of Function-as-a-Service under the term serverless, few research literature is available on its platform designs. Amazon’s spearheading offer is called Lambda, which stems from the Lambda calculus and has led to the term Lambda architecture (used e.g. by [27]). The paradigm to design Cloud applications to run on serverless platforms has recently been coined Cloud event programming[34], while distributed applications that are designed to self-manage their resource allocation have been branded by the microservice (container-based) movement as cloud-native applications ([43],[1]) which has led to the attribution of cloud-native event-based application design[16]. Cloud-native is specifically connected to container-based architectures[1], and containers are in fact the most widely used isolation mechanism for FaaS, supposedly including all public serverless offers[2][8][10][5] who provide it as an extension to their infrastructure. Economical aspects for the adoption of event-driven computing as a Cloud service model are discussed in more detail below.

Some research argues for performance reasons that containers “cannot be the unit of deployment”[29] and that “container throughput […] would not be enough to be cost-effective”[44]. Given the diversity of emerging computing architectures that share common requirements, [44] argues that research for unified environments are required and recommends the cloud-native application design[43]. A unified platform would exceed the scope of this thesis. Instead, prominent serverless platform architectures are reviewed below to assert the opportunity to develop and integrate an improved event dispatching.

3.1 Economical aspects

Serverless computing is advertised an evolution of Cloud computing in the growing market of virtual infrastructure provisioning. The following describes how serverless fits with Cloud economy.

3.1.1 Cloud service model

Serverless computation stems from the Cloud business model to offer resources on demand. Infrastructure-as-a-Service offerings for time sharing of a physical server infrastructure has created a large market to rent resources. Serverless is about changing the business model from reserved capacity to actual utilization (cmp. [14]) and provides means to deploy consumer-created (or acquired) applications, so it categorizes as Platform-as-a-Service model by the NIST Cloud service model definition[35]. Meanwhile, distributed application architecture components have been commoditized for Cloud deployment, such as databases, messaging middleware, storage subsystems, networks, firewalls, and load balancers. Serverless aims to complement this ecosystem by providing lean deployment of highly customized application logic. But with serverless, dispatching events or routing service requests is an integral part of the platform and no longer part of the application, so this thesis categorizes as serverless platform research but not Cloud application design.

3.1.2 Cloud economy

In the Cloud service business, platform commodity components (DB, messaging, CDN) are available through self-service interfaces and billed in terms of hardware resource consumption rather than software metrics. Few services have appeared as exception that were billed by the number of API calls (e.g. former versions of the Google App Engine). Today, almost all pricing schemes have been simplified to billing by infrastructure metrics (resource amounts over time). Likewise, FaaS offerings charge by resource metrics, none of which allows sizing of the CPUs but pin execution to a single processor[37]. Only memory can be scaled, so compute time is charged by memory capacity over time, e.g. MB-sec or GB-h. Except with IBM[11], a charge is incurred for the number of invocations[4][6][9]. Additional costs are incurred by complementary use of persistent storage. Adam Eivy (Solution Architect at Walt Disney) has published a warning cry[22] that resource consumption can backfire for large demand baselines and create higher cost for the FaaS customer than traditional IaaS virtual resource rental. Remote data access during execution of a function can cause active waiting time for which the customer is billed. This work thesisizes that intelligent dispatching can improve cache hits on colocated data caches/stores to reduce function execution time and resource consumption. Improving resource efficiency would reduce resource usage for the customer and increase throughput of function invocations for the provider. Also, operational models where Cloud customers deploy self-managed FaaS platforms on public or private infrastructures would benefit from improved efficiency, reduced cost and ultimately lower energy consumption.

3.1.3 Data center utilization

Serverless is supposed to saturate resources better than allocation-based virtual server leases. The actual server utilization in data centers is low[28] despite IaaS provider claims that the introduction of Cloud infrastructures has reduced overall carbon emissions[18]. The reason is simple. The customer is required to allocate a resource capacity upfront. The provider has to provide the contracted amount of allocated resources and must not fall short of resources during execution (e.g. due to overbooking). This business aspect has ruined some of the benefits of resource sharing because (a) execution is limited to only utilize the allocated part of a machine even if it had residual capacity and (b) allocated but unused resources are not available to colocated workloads. IaaS providers have adapted virtual machine flavors in terms of CPU and memory capacity for harmonic bin packing [30] for less fragmentation or more optimal resource booking, but spurred research on demand prediction, online scaling and finding optimal QoS trade-offs, etc. Up to date, this problem drives enormous efforts to optimize Cloud resource allocation.

FaaS offers much smaller memory flavors in terms of MB not GB (e.g. 64MB, 128MB, 256MB). The accounted time granularity is also much finer (100ms) with allowed execution times up to 5 minutes rather than hours of allocation, which alleviates the problem of blocking unused resources. As such, Serverless computing may finally increase the utilization of servers in Cloud data centers.

On the other hand, the current way of isolating serverless function execution may yield much, much higher overhead. The memory flavors become easily utilized by even a tiny function, because the execution requires JIT compilation (cmp. [27]), core libraries and may use additional packages. When executions need to load code and data from storage back-ends to a fresh (cold) container instance before actually starting computation, the bootstrap overhead may become significant. The current operation model is to isolate every function execution in its own container regardless of sequential actions on the same execution context. Event dispatching to servers based on where code and context has already been cached may increase resource efficiency but risks a lower overall resource utilization. An adaptive solution is required to optimize for efficiency within cost-effective boundaries of resource utilization.

3.2 Review of Serverless Architectures

Serverless platforms, in essence, need to dispatch the event, execute the function and store related data (event data, code, policies, state). Most serverless platform designs so far follow the Cloud application model and are compartmentalized architectures similar to the 3-tier web architecture that separates the web front-end, an application server and a data back-end. Merely, the novel Cloud application designs extend this concept with resilience and elasticity of services [43] and use resource pooling and caching. Besides the public offers (AWS Lambda, Google Cloud Function, Microsoft Azure Functions and IBM Bluemix OpenWhisk), over 20 Function-as-a-Service platforms have emerged, mostly based on Docker container isolation. Hendrickson et al.[27] have identified the need for research on load balancing that considers code and data colocation. The following reviews prominent existing system designs to assert that adaptive event dispatching is still missing from todays platforms.

3.2.1 OpenLambda

Hendrickson et al. have published the OpenLambda platform [27] to “facilitate research on Lambda architectures”. The group has identified colocation awareness as a requirement for load balancing. The project initially used the front-end proxy to load balance events across worker instances[13] which keeps forwarding latency short. The group published ideas early but had only round robin load balancing and worked on a balancer using gRPC [12]. Unfortunately, the group has ceased development.

3.2.2 IBM OpenWhisk

IBM has open-sourced its serverless compute service to the Apache Software Foundation and is among the first to publicly conjoin the serverless paradigm with a cloud-native infrastructure for distributed mobile application architectures in [16]. Figure 1 outlines the components of the platform:

• •

Nginx as a web request front-end reverse proxy that terminates user connections and translates RESTful requests into API calls of the controller

• •

Controller written in Scala that asserts entitlement and orchestrates function executions by sorting events into invoker’s message queues

• •

Kafka to buffer and persist the events and ensure delivery

• •

Invokers that process events by loading function code from CouchDB, executing it in a Docker container and storing the result back to CouchDB

• •

Consul to manage the platform’s container infrastructure (inventory management) of proxy, controller, database and worker containers

• •

CouchDB that maintains security policies, authentication data, function code, execution quotas, execution results, a.o.

The OpenWhisk architecture design uses reverse proxy load balancing (Nginx), master-worker job scheduling (controller-invoker) with persistent, distributed queuing (Kafka). These are typical best practices for scalable web application architectures. Notably, the application state and platform state are held separately in Consul and CouchDB, a key-value store and a document-based store, both distributed in nature but with different replication protocols. Event dispatching is performed in two stages by the reverse proxy and the controller that selects a worker’s queue. The default controller implementation only uses round-robin but the architecture is suitable to implement more sophisticated event scheduling algorithms. Kafka uses distributed and replicated event message queues for reliability. Its coordination framework employs consensus protocols to determine ownership (responsibility) and replication (reliability) of queue partitions, which allows the controller to be implemented as a stateless component. However, there is currently no mechanism to consider data locality or context caching when dispatching an event.

3.2.3 OpenFaaS

More recently, Alex Ellis came out a winner of a Docker contest (Moby’s cool hacks) with a serverless architecture that reuses the Cloud Native Computing Foundation’s components Kubernetes (container orchestration), Prometheus (monitoring database) and Docker (container runtime) - usually known for microservice architectures - in a Function as a Service platform architecture[23]:

• •

Gateway written in Go to dispatch events to running containers

• •

Worker containers that can run a certain function type

• •

Registry of container images

The gateway monitors the container cluster resource metrics (through Prometheus) to scale the number of worker containers. Functions are provided as container images and at least one instance is required each to run for event dispatching. OpenFaaS maps the serverless model (functions) one-to-one onto containers and uses the container platform to track state of resources and services. Multiple invocations of a function run concurrently in a container and are isolated by different processes only.

3.2.4 Serverless Prototype

Garrett McGrath from University of Notre Dame, Indiana [33] designed a prototype based on Microsoft Azure services. It uses load-balanced RESTful WebServices to accept and classify a function request to create a task called ”execution request object” that contains the function meta-data (context) and inputs (event). Instead of submitting the job through the messaging layer, workers promote their availability through the message layer. A worker may either have a container running that has the function code loaded (warm) or unallocated memory to launch a new container (cold). Idle function containers promote their availability in per-function queues (warm queues), workers promote their capacity separately (cold queue). As explained in [33], an event is dispatched to the first in a queue of available containers per function regardless the available context data.

4 Objectives

Serverless allows to dispatch the invocation of individual functions to any resource node. This provides a new degree of flexibility alongside data replication and placement which allows the platform to scale the execution of an application comprised of functions across resources that also hold the related data but every invocation may come with some overhead.

The main objective of this thesis is to design and evaluate an adaptive event dispatching to increase serverless function execution resource efficiency.

To assess the potential for improvement, the design of event dispatching in existing open source serverless frameworks has to be reviewed. Initial survey of the matter has asserted that open serverless system designs do not optimize for function execution time and it has revealed that public serverless providers might be primarily concerned with resource utilization rather than computing efficiency.

Under the hypothesis that execution overhead is dominated by both dispatching latency and fetching execution context, a plan shall be designed to generate application knowledge on event-, function- and data dependecies and to use this knowledge to optimize platform resource efficiency. The target is to adaptively improve event dispatching for resource efficiency at runtime.

The objectives comprise the analysis of (at least) one serverless framework, a thorough evaluation of design options for serverless event dispatching, the implementation of an adaptive event dispatcher and its evaluation in a serverless testbed.

5 Methods

In the following, methods for the design of adaptive event dispatching are presented that may be applied to serverless. Advancements in other fields such as Big Data analytics and many-task computing (MTC) and the general area of distributed computing (Grid computing) have been considered.

5.1 Data-awareness

In the context of Grid computing, Ranganathan and Foster[39] have shown for synthetic, data-intensive workloads that “scheduling jobs to idle processors, and then moving data if required, performs significantly less well than algorithms that also consider data location when scheduling” and they “achieve particularly good performance with an approach in which jobs are always scheduled where data is located, and a separate replication process at each site periodically generates new replicas of popular datasets”. Their scheduling architecture is a two-stage hierarchical system (according to the Grid infrastructure) that (1) forwards jobs to sites that contain the data and (2) replicate popular data to meet computing demand with local data access. These two aspects of data-awareness are also popular with data-intensive computing (Big Data), which partitions, randomly distributes, and replicates ingested data in order to maximize resource utilization during parallel processing. However, disconnected strategies may unfortunately break this overall system property. As discussed in CoLoc[40], decoupling the Hadoop data store (HDFS) and container-based worker pools (YARN) requires a data-aware container placement to keep data accesses local, and can reduce execution time up to 35% as compared to default container scheduling and HDFS block placement. Serverless application design faces the same issue when decoupling the program state from the execution. The necessary design of a data-aware serverless event dispatching can either reactively or proactively localize data:

• •

reactive localization: event dispatching looks up data locations and schedules processing on optimal locations

• •

proactive localization: event dispatching clusters events and proactively choses locations considering that changes may cause replication or migration of data

Serverless computing however would be different from data-intensive computing in that it also comprises tasks with fewer data access and more complex data dependencies that vary with every event. Many-task computing as presented in [46] addresses a broader range of applications with execution time granularities of 64ms to 8 seconds and both communication-intensive as well as data-intensive tasks, which fits with serverless granularity. It needs to be assessed whether these MTC advancements on data-awareness[45] can be applied to serverless adaptive event dispatching.

5.2 Distributed scheduling

Recent work in many-task computing, like MATRIX [46][45] or Sparrow [38] suggests that the trend for over-decomposition of Big Data applications requires a decentralized or fully-distributed task scheduling to achieve the required scheduling throughput. The serverless trend towards functions faces a similar over-decomposition and latency has already been identified an issue[29][44]. Any centralized approach can be clearly dismissed for scalability issues, so scheduling requires some coordination over shared (externalized) system state.

Current serverless follows the cloud-native design[43] to use decentralized pools of service instances dedicated to load balancing (cmp. controller [10], gateway [23]) to scale the front tier. OpenWhisk[10] uses Kafka as reliable distributed message queuing service to persist tasks on message queueing servers. Opposingly, the fully-distributed approach developed by Wang et al [46][45] spreads queued tasks across all system nodes which has the benefit to be able to dequeue and process tasks locally. It uses a distributed hash table (ZHT[31]) to store tasks, data dependency and data locality but employs randomized neighbor selection for work stealing, that has been questioned in [41] to potentially cause poor utilization and scalability in some scenarios. Instead, it suggests distributed message queuing over its distributed hash table, i.e. across all nodes. It is sensible to adopt the fully-distributed approach as locally spawned events could be quickly processed if the node also hosts the required data or if the data access to computation ratio is low.

5.3 Event clustering

Serverless event executions can be data-independent or data-coupled, sequential (flow chain) or parallel, recurrent or unique, small or large (w.r.t. memory), single- or multithreaded, short or long. Furthermore, serverless event dispatching needs to consider the system configuration, the data locality and resource availability to achieve the highest resource efficiency. The problem is how to use these parameters to infer the optimal location for an arriving event and, in case of proactive localization, how to cluster similar events.

OpenWhisk[36] and OpenFaaS[23] use by default round-robin and scale simply by machine load. Data-aware MATRIX[45] uses task graph dependencies and data dependencies to schedule on optimal locations and employs work-stealing to balance load. Considering the directed acyclic graph of a job’s workflow is also common for modern distributed computing platforms (cmp. Apache Spark). An event typically carries the name of the function to be invoked, so it can be used to cluster events by the code they trigger. An event may also carry function arguments. The values might give hints to which data sets might be required to execute the event. Eventually, metadata about an event can be used, e.g. the event source that initiated the request. Depending on the code (function name), the referred data (arguments) and the metadata (origin, endpoints, proxies) it might be possible to cluster events and direct groups to an optimal worker that has most of the required execution context in memory. For serverless, a common metric is required to describe optimality of a location which exceeds the current data-aware approaches[45][40].

6 Project timeline

The project timeline is set from October 2017 until the submission of the dissertation in March 2018 and is diplayed in figure 2. The task plan is result-oriented, i.e. tasks are structured to deliver intermediate results. All results feed into the thesis reporting which spans the entire project time and produces the final dissertation.

The project uses the waterfall model to engineer a solution. It starts with the choice and description of the serverless platform (or simulator) to integrate with. Architectures have been investigated during the initial survey, so it is expected to be finished within the first three weeks. The design of adaptive event dispatching follows, which provides a specification of the envisioned adaptive event dispatching subsystem. In parallel, the setup of a testbed should be promoted to assure that hardware is available and the chosen serverless platform software can be setup before the end of year. Beginning next year, the implementation and benchmarking efforts kick off to evaluate the platform’s default event dispatching and to implement the designed mechanism until final evaluation of the improvements. A separate task end of January 2018 is preserved to prepare a poster demonstration. The final three weeks of the project are left for dissertation writing and to mitigate the risk of accumulating delays.

7 Deliverables

This project is laid out to design and implement an adaptive event dispatching for serverless platforms. Hence, the system design, the implementation and an evaluation should be deliverables of this project. For documentation of the project’s progress, a poster is to be presented beginning of February. The final dissertation should be issued end of March.

The design comprises the choice of a serverless platform architecture as well as the design of the adaptive event dispatching subsystem. The resulting specification describes the components and mechanisms of adaptive event dispatching and interworking with the platform.

The implementation is a proof-of-concept realization of the designed specification and may use discrete event simulation in case that hardware resources are not available at the time to integrate the developed mechanism with a serverless platform.

This work thesisizes that intelligent dispatching can improve cache hits on colocated data caches/stores to reduce function execution time and resource consumption. The evaluation should assess the quality and efficiency of the designed system. If possible, the evaluation should also compare against one existing serverless plaform. The quality of event dispatching can be assessed comparing the actual execution time of a task and its ideal execution time. The efficiency of the system is the proportion of time that a system spends actually executing tasks, while the remaining time is used to move data, wait for communication, etc. System utilization may complement the evaluation to show system state. (cmp. [45])