Application Partitioning

The model of offloading to multiple devices is similar to the version of a Cloudlet given by Verbelen et al [141], and that of the local cloud by Nishio et al [92].

Alfredo by Giurgiu et al [45] is an application partitioner. The aim of the project is to move computation intensive components of an application onto cloud in-frastructure. They developed this component system on top of R-OSGI. By designing applications into movable (or possibly non-movable) components, they could be moved between the mobile device and the infrastructure with the aim of maximising or minimising an objective function, such as minimising interaction latency. Alfredo profiles an application into a consumption graph, where the vertices represent the application components known as bundles, and the edges between bundles represent a one-to-one dependency. Various annotations are used on the graph to describe attributes such as data size, en-ergy or time constraints. Various configurations of bundle deployments are calculated from this graph based on the objective function. They also demon-strate two novel algorithms used to decide the deployment configuration from the graph. They tested the implementation with a new application designed for the Alfredo architecture, and an existing application they modified for the architecture. The results showed the algorithms were optimal in deciding con-figurations for minimising latency. The results of application performance var-ied based on the configuration chosen. The authors concluded by suggesting a new approach to mobile applications; rather than a single application running on the mobile device or accessing software through a web browser, that a third approach could be to use the mobile device as an application controller. It will be responsible for providing the interface, and the other components are del-egated to the cloud. This is similar to the remote display/thin client solution work by Simoens et al [124], which is discussed in subsection 2.3.3.

The benefits of partitioning the applications in such a manner are clear; ul-timately it enabled the applications that were too resource intensive to run locally on the mobile device to be used. The example shown to minimise in-teraction latency again is desirable from the user experience point of view, as is it’s capability to calculate deployments to minimise energy costs. It may be worth highlighting that minimising latency and maximising energy savings may not result in the same deployment. Both are important for the user ex-perience. In this case, a deployment that saves energy, may increase latency,

Figure 2.2: Application Partitioning Model. Mobile applications are developed as separate components forming a graph. A cut is then made in the graph to form a distribution of components for execution on other devices located in the vicinity. The cut specifically is made to meet an objective function, such as minimise energy consumption.

and vice versa. No tests were carried out in the work on that note, nor would it be decisive as the results would vary for different applications. The experi-mentation used was between a tablet device and a laptop computer; no cloud infrastructure is utilised, which would be useful, as deployments could also take place between different cloud nodes. The approach as a whole is very similar to the dynamic Cloudlet solution by Verbelen et al, such as it requires applications to be built as distributable components, and existing applications would need to be modified for this.

One issue not taken into account by the original Alfredo partitioner is the fact that the network environment is consistently changing. Therefore, at one time, a partitioning may be the most optimal, but a later time, the partitioning may no longer be optimal. In this case, an element of "dynamic-ness" must be in-troduced to partitioning. An extension to the Alfredo framework in later work by Giurgiu et al [44] builds on the previous work by the authors to introduce dynamic partitioning. This kind of partitioning results in the deployment of application components to local nodes changing at run-time, based on online

calculations for optimal re-deployments, as network and device conditions change. The authors describe the first version of Alfredo, as a ’static parti-tioning" model, in that after the initial calculation of the application compo-nent graph and deployment cut, the deployment configuration never changes.

Once again the work is based on OSGI bundles, and so applications must be adapted to the OSGI framework. The results showed the value of dynamic partitioning over the original work, with performance increase up to 75%, and power consumption improved by up to 46% (on Wi-Fi), depending on the spe-cific application.

Similar to the second version of Alfredo, the MoSeC framework by Wu and Huang [146] considers the extension of the cloud to an ever-changing network edge consisting of many mobile devices and sensors; a dynamic configura-tion as Giurgiu et al would describe it. Instead of the tradiconfigura-tional mobile cloud offloading model of making one decision to offload to one server, this paper presents a model for the topology reconfiguration problem. In this problem, a mobile device, at different decision points, may offload several application components, to various different sites/nodes. This process repeats several times for the changing environment. The paper proposes a system for mon-itoring network state, and then applies one of three different algorithms to re-configure the offloaded application components, to match an updated network topology, using resources such as energy saving as a reward for reconfigura-tion. MapReduce algorithms are used to calculate the reconfiguration at these decision points. The work formulates the reconfiguration problem for use with the algorithms. No implementation or evaluation has taken place; the model is purely theoretical.

One example of work, which still takes an OSGI-based approach, yet tries to remove the burden of partitioning considerations from the mobile application developers, is the AIOLOS middleware by Bohez et al [13]. Specifically, based on OSGI, it takes mobile applications developed as a set of components, and sends these components to AIOLOS nodes, which consist of various mobile, cloud edge (Cloudlet) or cloud data centre VMs, for execution (where each runs AIOLOS). The focus of this work was the scalability of the AIOLOS nodes to support multi-user applications. AIOLOS can monitor the resource usage, and based on policies, re-configure the deployment of components to match a goal, such as minimise execution time or maximise energy savings, again, as seen with Alfredo. This reconfiguration of the deployments is similar to the second version of Alfredo, and the topology reconfiguration problem defined

with the MoSeC framework. The other aim of this work was to separate the developer burden of having to develop the application to handle execution of these different kinds of nodes, by making the aspects of remote or local execu-tion, transparent to the developer. This is important, as other code offload ap-proaches such as MAUI and CloneCloud, as discussed in the next subsection, suffer greatly from developers having to modify the applications for remote mobile cloud execution.

To summarise application partitioning, this technique has demonstrated the benefits of performance improvements, and the realisation of applications that are too resource intensive for mobile devices. The major difficulty here is the requirements shared by most of these frameworks, that the applications must be developed as components for the OSGI framework (or OSGI bundles to be precise). The argument of the authors of these works, is that it is good pro-gramming practice to develop applications in this way, coding to interfaces, and loosely coupled, which is an agreement shared by software developers in general. However, more often than not, this is unlikely to be the reality, requir-ing extensive application modification to support OSGI bundles. Aside, there is also the issue of devices being nearby and willing to participate, similar to the concerns with the Cloudlets in the previous subsection. Finally, the cost to the mobile device of profiling the network repeatedly, calculating graph cuts, and component deployment, is non-negligible. Adding this cost on is not ben-eficial to the user experience because of the resulting power cost. Arguably if this profiling was cheap, this would be an excellent approach from the user experience perspective, but troublesome for the developer experience.