# Multi-formalism Models for Performance Engineering
## 1 Introduction
If cloud computing relies on a centralized architecture (usually, a data center), in edge computing, processing occurs at the edge of the network. This choice has proved to be a viable solution to overcome the data latency typical of cloud computing, at the cost of limited processing power. The two proposed architectures are not mutually exclusive: instead, they complement each other. In this sense, _fog computing_ extends the concept of centralized network by taking into account localized data centers or _fog nodes_, deployed to store and elaborate data at a shorter distance from the source. A fog node can filter which data need to be referred to the central server of the cloud structure from those which can be processed locally. As the success of a cloud network architecture depends on its performance, it is crucial to identify those factors influencing its implementation in order to build a valid model, which can be either simulated or studied analytically. The scientific literature provides numerous approaches to this task, ranging from stochastic models to machine learning-inspired methods. The contribution of this work consists of a survey of specific extensions of queuing networks formalism and solving methods to efficiently analyze the aforementioned scenarios. To be more specific, we start from the observation that queuing networks are particularly suited to model cloud and edge computing architectures, as this formalism denotes some limitations when taking in account different scenarios. For instance, one can imagine a simple auto-scaling scenario, where virtual machines are shut down and restated only when needed (see, for example, _Overview of autoscale in Microsoft Azure Virtual Machines, Cloud Services, and Web Apps_ at [[https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-overview](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-overview)]([https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-overview](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-overview))). Restart requires a non-negligible amount of time, and, when the system is fed with a very low workload, this becomes the main component of the average response time. As the workload increases, the chance of finding the system already in _on-state_ increases too, resulting in a reduced response time. However, when requests increase, resources start to saturate, extending again the average response time.This behavior cannot be modeled easily with queuing modeling primitives even if some specific computing techniques (such as _fork/join_, _finite capacity regions_, and _class switch_) and approaches (such as _multi-formalism_) allow the modeler to take in account more complex architectures. Table 1 briefly recaps the main characteristics of the case studies presented here, including specific characteristics for which special techniques are required and describes the minimal extension that can capture such behavior. All the models presented in this work were solved using JMT ([[http://jmt.sourceforge.net/Download.html](http://jmt.sourceforge.net/Download.html)]([http://jmt.sourceforge.net/Download.html](http://jmt.sourceforge.net/Download.html))) [5]. All results were computed with 99% confidence intervals that, for simplicity of presentation, are not graphically represented. This work is organized as follows. Section 2 reviews the related work in the scientific literature and Section 3 focuses on computing problems that can be addressed with extensions to classical queuing networks modeling features. Section 4 describes cases where this formalism alone cannot be applied, but where multi-formalism modeling techniques that combine Petri nets with queuing networks, can provide meaningful and clear solutions. Both sections include a description of some of the known results, explaining how this study could provide better insights into the considered scenarios. Finally, Section 5 draws the conclusions and explains the roadmap for future work.