## 2 Background on Serverless Computing  
The model for using cloud resources commonly referred to as _serverless_ requires the cloud provider to take care of all the management activities of the physical servers and dynamically allocate the resources necessary for the operation of the costumer software. This frees up application developers to focus only on developing the code and deploying it directly into the production environment. To take advantage of the potential of serverless computing, applications must be organized into elementary functions that can be invoked in stateless mode. For this reason, serverless services are offered according to the _function as a service_ (FaaS) model. Ideally, each function should implement a single task, such that each function is short-lived and recyclable. This particular access to cloud services, if well executed, tends to minimize the use of resources by the customer and to maximize the number of applications deployed by the provider. Therefore, the use of the serverless model determines mutual benefit, which has led to its considerable success in recent years [2; 6; 7; 8; 9; 11; 12]. For this paper, we considered an edge computing system accessed using serverless technologies. Using this system, we analyzed and compared the ability of some machine learning algorithms to control the horizontal autoscaling events of functions. To understand some architectural choices and the expected performance, it is necessary to focus on the technical characteristics of the system and the technologies used in it. The schematic model of the serverless computing system used for our experimantal campaign is depicted in Figure 1. Before focusing on the individual elements, we point out the key element of the model, namely, the parameter \(n_{c}\). This parameter ideally represents the minimum number of instances of a single function generated by the platform autoscaling algorithm to satisfy the required performance, in terms of latency and losses, referred to, in short, as the service level agreement (SLA). The system is composed of the following functional elements, which the expert reader will be able to map onto the functional elements of the most popular commercial and open serverless platforms, such as OpenFaas ([[https://www.openfaas.com/](https://www.openfaas.com/)]([https://www.openfaas.com/](https://www.openfaas.com/)), accessed on 1 July 2024) and OpenWhisk ([[https://openwhisk.apache.org/](https://openwhisk.apache.org/)]([https://openwhisk.apache.org/](https://openwhisk.apache.org/)), accessed on 1 July 2024):  
* Scheduler: This component receives at time \(t\) incoming requests to access a function with an arrival rate equal to \(f_{\zeta}(t)\). * Computing cluster: This cluster can be composed of a generic number of physical servers. In this case, we use a single server, which represents the edge system. Since the functions must be instantiated, ensuring an adequate degree of isolation, they are implemented in containers. Furthermore, in line with a very popular practice today, the containers are orchestrated using Kubernetes. For this reason, in the computing cluster shown Figure 1 there are _pods_, which include the containerized code of functions. We assume that \(n_{c}\) function instances are currently deployed in the computing cluster. For this reason, we can reasonably assume that each pod receives requests for execution of the considered function by the scheduler at an average frequency of \(\frac{f_{\zeta}(t)}{n_{c}}\). * Metric server: This component collects resource metrics, such as CPU load, and makes them available to the scaling control mechanism by storing them in a log repository. Clearly, the collection of metrics cannot be a continuously running process; rather, it is carried out periodically, with a period that in Figure 1 is indicated by \(\Delta T_{1}\). * Horizontal pod autoscaler (HPA): This component automatically updates the number of active pods associated with the workload resource that implements the function.