# Placement of IoT Microservices in Fog Computing Systems: A Comparison of Heuristics
## 2 Background and Problem Definition
### Reference Scenario  
The fog computing paradigm typically involves the deployment of services close to the source of data that needs to be processed or to the application's end users. Unlike the cloud computing context, this scenario is characterized by high heterogeneity of resources such as computational capacity of nodes and network delays for inter nodes communications. We assume that fog nodes are computing nodes with a non-negligible computational capacity. Each node can provide several services concurrently, for example, by using containerized environments. To better explain our vision, consider fog nodes can be considered as similar to computing elements placed alongside mobile phone antennas, rather than battery-operated motes in a sensor network. In this context, we focus on the application _microservice placement_ issue, that is, the problem of how to best allocate microservices on the distributed fog nodes with the objective of minimizing the application response time and satisfying the SLAs. The inputs to the problem are:  
* A list of applications with related SLAs;* A set of fog nodes, along with their computational capacity;
* A demand for applications with short-to-mid term expected load that is known a priori. We assume that microservices can be stateful, meaning that migrating or re-deploying them in a short time span is not feasible. Even if requests from a single client, i.e., a sensor or a user, are difficult to predict, we assume that the overall incoming request rate either remains stable through time or changes slowly. This means that the time frame for a service deployment is on the order of tens of minutes up to one hour, and that the system load can be considered constant for that time. It is worth noting that this provides an order of magnitude for the time needed to solve the optimization problem, that is, it should reach a solution within a time frame of minutes. In this scenario, we assume that each IoT application is modeled as a _microservice chain_ that consists of multiple (at least two) independent and interconnected microservices. Without loss of generality, we model a service chain \(c\) as an ordered sequence of microservices \(m_{i},i\in 1,2,...n\). The microservice chain length is the number of microservices composing the chain. As examples of applications that can be supported by our solution, we propose two chains of microservices. First, monitoring and logging of sensor data in an industrial plant. In this application (1), the chain is composed of (1a) data collection, (1b) data validation, (1c) data smoothing to remove outliers, (1d) alert triggering, and (1e) data logging. Second, traffic surveillance application based on smart traffic lights. In this case (2), the microservices are (2a) image collection, (2b) car identification, (2c) plate number recognition and anonymization, and (2d) data logging to a database. The microservices in a service chain may be allocated over one or over multiple fog nodes, and a fog node may host microservices belonging to different service chains. Fog nodes may have different computational capabilities, and are interconnected with each other by means of heterogeneous high-speed network. The final objective is to define an optimal microservice placement that meets applications' SLAs. To this end, as a main performance metric we consider the application's _service response time_, that is, the time passing between the end user request and the receipt of the application's reply. This metric is influenced by different elements, with the following being the most important: (i) the application request load, (ii) the average service time of the microservices in the service chain, and (iii) the computing capability of the fog nodes. Furthermore, it is important to mention that the presence of chains of microservices may lead to higher levels of complexity in the concept of SLAs, for example, where issues about availability are concerned.