Wednesday 26 April 2017


Customizable and Extensible Deployment for Mobile/Cloud Applications

Summary:

This paper focuses on the challenge faced by modern applications which work in a heterogeneous environment and in a distributed manner. Apart from providing application features the developer needs to worry about issues like fault tolerance, code-offloading and caching. This creates a dependency between application requirements and deployment decisions leading to complicated application logic in the code, consequently it inhibits the process of evolution of the application. Sapphire, a system presented in this paper is a distributed programming platform which removes the need of incorporating complex logic in the application code for managing multi-platform environment and provides a simpler way to handle this. This is achieved by segregating deployment logic from the application code.

Design:

There are two main components of Sapphire:

1. Deployment Kernel : It stitches together heterogeneous mobile devices and cloud servers using best effort RPC communication, failure detection, and location finding.
2. Deployment Manager : It provides the deployment kernel functionality to the application layer based on the deployment needs. For example: decision about how many, when to created, and when to delete a replica is taken by DM but the actual work of creating, and deleting is done by DK.

Sapphire's design of separating deployment logic from the application code gives programmers the choice to change deployment options easily as and when the requirement changes.

Steps for building a Sapphire based application:

1. Build the whole application logic as a single object.
2. Break down the application into few objects whose subset(distributed components) will be declared as sapphire objects.
3. Apply deployment managers to the sapphire objects as per the need.
The communication between the SOs(Sapphire objects) are location independent.

Strengths of the Paper:

1. Separating application logic from deployment logic greatly improves programmers ease as far as distributed management of resources is concerned.
2. Use of inheritance for creating a more complicated(required by few applications) DM is very useful and will make it easy to expand the DM library.
3. With the help of DMs we can solve different deployment issues like caching, code offloading, replication separately but combining all of them gives us a unified solution which is more extensive than systems like MAUI, COMET which are specific to code offloading or Bayou, Simba which focuses only on client-side caching.
4. Paper actually showcases how concise it is to implement a full-fledged application like shared text editor, twitter. Here object oriented way of handling DMs helps.

Weaknesses and Discussion Points:

1. The deployment policy for each SO now is static, but with current applications where requirements change almost in realtime, it would be better to have a dynamic assignment of deployment policy to each SO.
2. There is no comparison between systems with specific focus and Sapphire with only corresponding DM. Paper compares different applications for code-offloading but didn't compare it to other systems like MAUI and COMET.
3. Is it possible to manage multiple SOs from the same DM? This will help reduce the overhead of instantiating all the DMs each time a server hosting those fails.
4. It would have been interesting to see how an application can be broken down into sapphire objects. Is there a rule of thumb? How do a programmer determine the division?

2 comments:

  1. All excellent discussion points. For D#4, earlier OO systems like Mentat and Legion addressed this. They explicitly opted against D#3 -- can you think of examples where this would be great to have?

    ReplyDelete
  2. Any example would be good which has a basic requirement of lets say replication for all its SOs. If we just instantiate 1 DM for all the SOs then the overhead will be lot less.

    ReplyDelete

Note: only a member of this blog may post a comment.