Cloud and edge computing, along with solutions for scalable and secure systems, have an added layer of complexity in the process of selecting the most suitable hardware configuration to facilitate the needs of applications that are deployed in such systems. In order to navigate in this vast landscape of cloud service offerings [1], edge infrastructure solutions are of great importance for understanding the resource needs of the software (application or part of an application) deployed in these systems. Application profiling aims to describe, monitor, and evaluate the requirements for resources of any given application. This process aids the application owner to better manage the application in the following sectors [2]:

• managing the application;
• managing, selecting, and recommending the resources; and
• managing the cost of operation.

The optimal way to approach the profiling of an application is to deploy and monitor the resource usage of an application in all the available hardware configurations both in cloud and edge environments by using different workloads. Given the fact that this procedure is unreasonably time consuming and expensive, it makes it impossible to follow. In computer science, the de facto method for evaluating the performance of various computer systems is through benchmarking [3]. Benchmarks make the process of evaluating the performance of resources easy, given that they are easy to install and have well-defined workloads to simulate different resource needs for a given hardware set up. Due to this fact, there is significant industry and research adaptation of benchmarks as the means of hardware resource evaluation ^{[4][5][6][7][8]}[4,5,6,7,8]. Benchmarks by nature simulate different types of tasks and processes that an application can perform, so given the heterogeneity of application as well as the processes they perform existing in this day and age, there was a need for different benchmarks that simulate tasks of different nature and intensity. The variety of benchmark types and workloads stretch from simple operations, such as computing mathematical problems, to very specific operations, such as compression simulations. Although the number of benchmarks that exist and are available to the users is substantial and includes benchmarks that can cover almost any type of application, there is no formal way for an application owner to know which benchmark simulates best the hardware impact their application will produce, in order to use it in the hardware-selection process. Application owners can narrow down the useful benchmarks only by the information on the application nature (i.e., if an application is a database there are specific benchmarks to simulate databases such as YCSB, MongoDB, Cassandra, etc.).

2. Application Profiling System Architecture

The application profiling system is developed by using the Node RED flow-based programming framework (https://nodered.org/, accessed on 15 November 2022). This framework has a great variety of different nodes which help with the communication of different components in order to obtain the functionality needed. In addition, given the heterogeneity of hardware and APIs of the cloud-edge environments, it provides the necessary communication nodes for data exchange and manipulation of external resources. Application profiling system can function with different container environments (Docker, Kubernetes), but for research work conducted for thereis paper the container environment used is Docker. Containerised environments are proven to produce little to no overhead in the performance of the applications ^[9][21], thus minimising the interferences produced by the operating system used. Furthermore, the internal tools provided by the container environment engine are consistent and precise, reducing the usage of other external tools for metric collection. The application profiling system has two major components in order to work—the profiling component and the model trainer component. The profiling component is responsible for the creation of the multidimensional vector that represents the profile of the resource usage of a benchmark or application. As far as the profiling component is concerned, there are three main processes in the form of Node RED flows (as depicted in Figure 12) that are performed in order to create the profile, and these flows have the following functions.

• Metric endpoint configuration: In order to communicate with the appropriate Docker command line interface (CLI) and collect the Docker metrics for the container that runs a benchmark or an application, the appropriate configuration must be performed. The information needed for a new profile to start is the endpoint of the Docker machine and the container ID. In the case of benchmark profiling, the name of the benchmark as well as the workload are also needed in order to store the profile for training the model. In the case of application profiling, no extra information is needed.
• Raw data collection and storage: After the successful communication with the Docker CLI, the application profiler collects the metrics for the resource usage of the specific container (Docker produces these metrics and delivers them to the users using the Docker stats service). These metrics are stored temporarily in a collection in the database. Some of the temporarily stored metrics will be used without any other computation, directly for the profile creations; others are stored in order to produce metrics that require more computations, such as mean values and deviations of specific metrics.
• Profile creation and storage: When the metric extraction is finalised, then the temporarily stored metrics are retrieved in order to compute all the features of the profile (vector). In the case the profile created is from an execution of a benchmark; then it is stored in a specific collection in the database in order to be used for the model training and evaluation. If the profile is extracted from a running application, then it is sent to the classification model to be classified.

The model trainer component is responsible for creating the classification model for the applications. All the stored benchmark profiles are fed to the classifier trainer. A subset of these data will be used for training, and the other subset will be used for evaluating the accuracy of the produced model. This component also has three main processes that created the component’s functionality; these flows, as shown in Figure 23, perform the following functions.

• Data preparation: This process is in charge of all the first steps for data preparation and transformation. More specifically the appropriate folders are created to store the new model and the preparation of the new classes of benchmarks are initialised. After the data preparation, this process is able to produce the sparkML (https://spark.apache.org/docs/1.2.2/mllib-guide.html, accessed on 10 December 2021) dataset that will be fed to the model-creation process.
• Model creation: This part of the flow facilitates the process of creating the actual classification model. The sparkML dataset is loaded, and the vectors representing the benchmarks are assembled attaching to them also the label which represents the benchmark category and workload. After the creation of the model, the results of the testing data set are exported as CSV in order to assess the accuracy of the model.
• Model evaluation: This process is responsible for the accuracy evaluation of the produced model. It takes all the labels of the testing dataset produced by the model and checks them against the actual labels (benchmark and workload). If the model does not produce accuracy greater than a specified percentage, then the model is discarded.