Service placement and execution

According to what it has been discussed and presented in this thesis, it is clear that fog computing and cloud computing, when deployed in a collaborative fashion, shall bring up remarkable benefits. Aligned to this, the combined F2C computing has been recently proposed as a powerful framework to make the most out of both distributed and centralized resource allocation. It is worth mentioning that, distributed and centralized placement do not necessarily mean allocation in fog and cloud respectively. We consider that, a distributed allocation occurs when a service is placed in several resources, whilst the centralized allocation occurs when the service is placed in one unique resource, be it either in cloud or fog.

F2C aims at optimizing the execution of IoT services with high requirements in terms of both processing and network delay through a perfect matching between resources capacities and services demands. Therefore, we define service placement as the management decision regarding where a service (or atomic service—as described section 5.3) is to be allocated for execution. The strategy to be deployed for services placement must consider specific demands of a service, be it atomized or not, as well as the set of available resources at both fog and cloud premises. Notice that distinct atomic services may have distinct characteristics in terms of accepted delay, required network and IT resources, input and outputs, holding time, security, interdependence, failure tolerance, etc. The service placement in a real- scenario must consider all these aspects.

Albeit simple strategies, such as Random-Fit and First-Fit, presented in Section 5.4, have shown good results in comparison to the approach based exclusively on cloud placement, enhanced placement strategies considering decisions regarding atomization, distribution, and parallel execution should be further assessed. Indeed, while still in its infancy from the research perspective, the collaborative model envisioned by the F2C model for service placement and resource allocation is a salient feature. In line with this, we propose two distributed approaches to be considered for service execution and placement in combined F2C systems, in addition to a centralized approach, where a service would be completely placed and executed at either cloud, or one single fog edge-device.

proper service placement, let us assume a service that is complex enough to be atomized, that is, a service implementing the primitives and signaling mechanisms required for its atomization. The workflow shown in Figure 9.1 illustrates possible decisions to be taken for service atomization, placement and execution, which are described as follows.

The service request is initially sent to an F2C management system, which is in charge of placing the service. Thus, as a reaction to the received request, two decision-making processes may be sequentially issued, where the first one is triggered immediately after the service request is received and is responsible for deciding whether the service should be atomized or not. This analysis considers the information regarding both requested service – for instance, type and capacity of required resources for its execution– and available resources –for instance, type, processing capacity, network load and the fog/cloud they are currently contributing with. If the service atomization is chosen, the second decision is responsible for deciding if the service should be executed sequentially or in parallel. Since the service has been atomized after the first decision, the second one may be handled through the analysis of the atomic services execution graph created as the atomization process output.

Service

Should it be

atomized? No

Best-fit strategy: get the resource with lowest

delay and, at least, the total required

capacity

Yes

Execute in parallel?

Based on:

- service: type, minimum required IT power, maximum latency, estimated execution time... - resource: type, IT capacity, network load, located F2C layer, mobility profile...

Based on:

- atomization graph No

Minmax strategy: get the minimum amount of resources

able to satisfy the service requests

Yes

Distribute the service allocattion in distinct resources considering estimated service response time Atomize Parallelize Based on:

- service type: data processing, IoT data gathering, CDN - parallelism model: TLP or DLP?

Centralized

Distributed

Figure 9.1: Decisions for service placement.

fog. Taking as example a centralized Best-Fit strategy, the selection of one unique resource offering the lowest network delay, whilst complying with all service requirements , may provide acceptable QoS for a range of services. Indeed, such centralized strategy may reduce the signaling and atomization effort, as well as the network load. For instance, a service collecting all required data from one single data source may benefit from a centralized strategy, whilst, on the other hand, no single resource can meet multiple constraints regarding service quality for more complex service scenarios, where centralized placement would result in suboptimal service execution.

Regarding the employment of the distributed execution approach, let us assume the sequential service execution as the next choice, where multiple resources are sequentially involved on the service execution. For example, the resource allocation can make use of distinct data sources, such as sensors or datasets, where each source is selected according to the immediately preceding processing outcome. The employment of MINMAX heuristics (as shown in Figure 9.1) may be used in some cases, where the sequential allocation may be accomplished by the allocation of the minimum set of resources that may deliver an efficient service execution, diminishing network communication overhead. As an example of possible implementation requiring sequential service placement, let us assume the deployment of cameras in distributed areas of a smart city, where an object location service is implemented, while a specific car moving through an urban area needs to be traced in real-time. In such service, the employment of edge resources for image processing can avoid the need of uploading each picture to a dedicated server at cloud. Furthermore, the employment of resources at the edge of the network will also enable the low delay selection of the region where further data should be collected, for instance, according to the direction where the target car is moving. Therefore, the strategy employed for distributed sequential processing needs to consider an efficient allocation of processing resources able to process locally raw data close to each data source, reducing network load and delay. Since the minimization of network load can be further achieved by the reduction on the communication among processing resources, an important challenge of this strategy is to assess the tradeoff between proximity to data sources and amount of employed edge resources.

In addition, Figure 9.1 further depicts the distributed parallel service execution, which is executed according to the atomized service execution graph, aiming at improving the overall service performance. The rationale behind this approach is to benefit from both simultaneous obtaining of data from distinct sources, and simultaneous processing of large raw data that may be split into nondependent data slices. Notice that, both parallel and sequential approaches selection are highly dependent on the service to be executed. Indeed, services presenting data level parallelism (DLP), for instance, may rely on the processing capacity of upcoming edge devices; however, notice that, an important requirement for the efficient parallel execution of such atomic services is the minimum interdependence among them –i.e., no distributed shared memory (DSM) and minimum control messages among allocated resources– due to the unreliability and high latency offered by the transmission

It is worth noting that, the employment of distributed parallel placement and execution strategies opens up new issues and challenges. For instance, the processing latency for distinct atomic services may present a high difference from each other due to many factors, such as the heterogeneous type of tasks that may compose a service, amount of data processed by each atomic service, or allocated resources differences, among others. Therefore, let us consider a service whose completion depends on the outcome generated by a set of atomic services, possibly running in parallel, with distinct execution times. Assuming that the F2C control can estimate the execution latency for each atomic service, it might handle the allocation of two or more lower time consuming services at one single resource, enforcing their sequential execution in the same time interval of one time consuming service allocated to be executed in parallel in another resource. Moreover, strategies for message passing reduction employed in other distributed scenarios may further be evaluated and tailored to the F2C architecture, as well as the tradeoff between network load and QoS obtained from distributed parallel execution strategies.