[oe-sync] apps development for edge cloud

Padmanabhan Pillai padmanabhan.s.pillai at intel.com
Mon Aug 10 14:10:22 EDT 2015


Hi Guenter,

This is an excellent point.  I think in general, to get the most out of 
cloudlets, one would need to design the system with the cloudlet tier in 
mind.  For existing apps that are partitioned between client and cloud, 
this may require refactoring of the cloud part into cloudlet and cloud 
components.  The difficulty of doing this will vary significantly by 
application.

For a small set of applications, moving to cloudlets will be trivial.  
For these, the cloud backend is primarily computational, without a large 
amount of data.  Here, the cloud component can just be run on the 
cloudlet instead of the remote cloud.  Applications of this sort are the 
low-hanging fruit that can make use of cloudlets with no additional 
effort.  Some of the new applications we have been exploring at CMU, 
such as the cognitive assistance apps, also fit in this category -- the 
backends are largely self-contained computation engines that don't rely 
on external data (other than sensor streams from the client).

Some applications that have large cloud-based data sets can work well on 
cloudlets with relatively little modification.  Although the whole data 
set may be very large, there may be significant locality to the data 
access from a particular cloudlet (and the clients it serves), so 
standard caching approaches may be sufficient to let these applications 
work well.  I can imagine this can work well for map data (due to 
geographic locality) and any data that is tied to particular users (web 
file store, pictures, etc.).  Perhaps a common "cloudlet recipe" for 
such applications is to leave the data store in the cloud, but put all 
of the application logic and a caching tier in the cloudlet component.  
I would imagine that for existing, large, high performance cloud 
applications, the storage is already a separate component, and the 
individual compute nodes in the datacenter likely use caching already 
anyway, so the cloudlet recipe would probably not entail significant 
modifications.  For new applications, the structure prescribed is a good 
one, even if cloudlets were not the target platform.

I like the idea of creating a reference that prescribes different 
"recipes" for designing / retrofitting various types of applications for 
cloudlet deployment.  This will require some work -- I personally don't 
have a good feel for how to divide up the application space or on 
concrete recommendations.  I think we will need a lot more experience 
with real applications to get a better sense of this.

- Babu


On 08/09/2015 06:49 AM, Klas, Guenter, Vodafone Group wrote:
>
> Hi Kiryong, Rolf,
>
> Much effort is currently focusing on the edge cloud infrastructure due 
> to many challenges still to solve. On the other hand, I’m also 
> interested in understanding what an apps developer has to consider if 
> a deployment of (parts of) an application on a Cloudlet is feasible.
>
> I assume that the CMU team has some good experience regarding 
> ‘application design for Cloudlets’ from the demos created in the past.
>
> Questions that come to my mind:
>
> - Is application development exactly the same as when I develop an app 
> for deployment on a mobile device + interaction with the SW in the 
> tier 1 cloud?
>
> - Is application development exactly the same as today for different 
> types of technologies: e.g. Android apps, web applications …?
>
> If things are not exactly the same and if the apps developer has to 
> “design with deployment on Cloudlets in mind”, then I would argue we 
> should run a workshop with the attendance of some selected apps 
> developers to i) explain what needs to be taken into account and ii) 
> to get their feedback.
>
> Once this is done, and once we have some “portable” or “recommendable” 
> reference platform for Cloudlet in place, one could consider a 
> hackathon to explore further with the apps developer community…
>
> Any thoughts about this?
>
> Guenter
>
>
>
> _______________________________________________
> oe-sync mailing list
> oe-sync at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/oe-sync

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/oe-sync/attachments/20150810/da1e62f0/attachment.html 


More information about the oe-sync mailing list