Computing power and bandwidth are like money; the more you have the more you spend in fancy stuff, and no matter how much you have it’s never enough. New applications tend to include more functions and consume more resources than their predecessors, which is possible because new computers have more resources available. The now ubiquitous mobile applications are not an exception.
Think about mobile devices. Thanks to the development of faster processors, my smartphone has more computing power than my first personal computer (a Commodore 16 if you need to know), so I can run great applications on it. However, this doesn’t mean I can run on it all the workloads I need in my daily life, since most of them consume more resources than what’s available on the tiny box.
Mobile devices are intrinsically resource poor compared to contemporaneous servers since they are subject to additional size, weight and power restrictions.
An obvious solution is to run applications on the cloud and let the mobile device play the role of the user interface while the resource intensive work is done by Internet-accessible servers.
This solution works well if the mobile network meets the application latency requirements, which is usually the case with asynchronous applications; nevertheless, in the case of interactive applications aimed to provide near real-time feedback, the time required to access the service through the Internet may harm application performance. That’s when you want local area network (LAN) access to the server where computing intensive work is being executed.
Cloudlets may be a good fit for this use case.
What is a cloudlet?
As far as I know this term was first suggested by Satyanarayanan and coauthors: a cloudlet is “a trusted, resource-rich computer or cluster of computers that is well-connected to the Internet and is available for use by nearby mobile devices.”
Imagine you enter your favorite coffee shop and suddenly your mobile device finds a local server capable of running workloads for you. When you use an application the server starts a matching service, and resource-intensive, latency-sensitive functions can be turned on in your mobile application, enhancing your user experience.
For this to be possible some requirements have to be met:
- Unsupervised management: As the infrastructure for the cloudlet is hosted in the wilds, we can’t expect specialized technical support to be available, so servers better have the ability to perform most of their functions autonomously.
- Role-based access control: You want to be sure people are provided only with services they are supposed to use and data they own.
- Service availability: The cloudlet has to provide the service you are looking for. This implies that either the service is already running on it or it is instantiated when needed and destroyed when no longer required, as expected in a cloud environment.
- Access to application packages: For services to be dynamically provisioned, the cloudlet needs a mechanism to obtain the required packages to provision and run the current version of the service.
The biggest challenge seems to be ensuring the cloudlet can deploy a service by itself when required. Automated provisioning requires from applications to use a common platform and set of instructions to be deployed in the cloudlet. What if we use virtual application patterns to ease this task?
In the second part of this post I’ll write about what a cloudlet environment using patterns to deploy services may look like. Please stay tuned.