How to Put the Cloud on Your Device

ZapThink is always on the lookout for innovative, iconoclastic approaches to Agile Architecture, which is why we were excited to discuss IT innovation at the US Coast Guard (USCG) in a ZapFlash last year. So when USCG Chief Information Officer Rear Admiral Robert Day discussed a novel approach to securing their enterprise email, we knew we had another story to tell. He said, “I’m not going to make this device an endpoint on my network. There’s just no way. What we’ve done is create a secure sandbox inside of the device that can be managed, fixed and certified to operate our enterprise email capability.”

At first blush this solution is a straightforward example of application virtualization. What caught our eye, however, was the conclusion that running email on a secure sandbox on a mobile device was an alternative to treating the device as an endpoint on their network. So, if mobile devices aren’t network endpoints, then what are they? And what other problems might we be able to solve if we no longer consider mobile devices as endpoints?

Playing in the Sandbox

We asked these questions before in our ZapFlash on Cloud-Oriented Architecture and the Internet of Things. In that article we pointed out that under certain circumstances, mobile devices can host little pieces of the Cloud, instead of simply being client endpoints. As a result, the Internet of Things doesn’t simply have to consist of hypermedia-linked devices, but can actually be part of the Cloud itself.

Fascinating perspective to be sure, but we’re the first to admit that the COA article left us wanting more. Thanks to the USCG, it’s time to put more meat on the bones of COA, beginning with the application virtualization that Admiral Day referred to. With application virtualization, the application (in this case, an email client) runs in a virtual machine (VM) on a server, as shown in the figure below.

The mobile device then runs a secure virtual partition we call a sandbox, and in the sandbox is a special app that accesses the server-based email client remotely. Once the user has properly authenticated themselves to the sandbox, their experience interacting with their email client is the same (or almost the same) as if the client were resident on their device, except that it remains on the server. The result is that the device itself may be untrusted (since it’s on the Internet and could also be stolen), but the email remains secure.

Except for one problem: that’s not really how sandboxes work. The central notion of a sandbox is that it protects untrusted activity inside the sandbox from compromising the host device, instead of the other way around. In the case of application virtualization, we have what some people are starting to call a reverse sandbox, as illustrated below.
For example, browsers provide sandboxes for Java applets. Since a Java applet might contain malware that could potentially damage or comandeer the host computer, the sandbox is supposed to isolate the applet and protect the host system. But in the case of application virtualization, we’re assuming the device is the risky environment and we want to protect the app in the sandbox. Another application of a reverse sandbox would be to protect a Web session from keylogger malware, for example.

The Lesson of Desktop Virtualization

There are two main problems with application virtualization: first, the server and host must run the same operating system (which in practice usually means Windows), and second, a flaky network connection hoses the entire interaction. An approach to desktop virtualization called remote synchronized virtual desktop addresses these issues. With remote synchronized virtual desktop, the client device fetches a copy of a VM instance of the user’s desktop from the server and runs it locally. (Sometimes the instance is generic while other times it’s specific to the user, but that distinction isn’t relevant to our discussion). See the figure below:

With a remote synchronized virtual desktop a sandbox separate from the local VM is optional, since the desktop hypervisor that hosts the VM typically provides the security of a sandbox. Furthermore, since the entire remote desktop environment is running in the local VM, continuous connectivity isn’t essential. You need sufficient connectivity to synchronize the local and server VMs, but an occasional dead spot or plane flight won’t crash your virtual desktop.

Of course, remote desktops have their limitations as well. The VM image file size tends to be quite large, so downloading it over a slow connection would be painful, and it likely won’t fit on a smartphone (at least for now). The virtual desktop may also expect a standard keyboard and mouse, so a phone or iPad client may be impractical (although the Windows 8 touch interface is bound to improve this situation to some extent).

Desktop virtualization is an important technology, to be sure, but there’s more to this story. The current marketplace for such products is stuck in a “horseless carriage” scenario. We have sandbox technology (regular as well as reverse), and we can also put virtual environments on mobile devices. Combine those with the existing state of Cloud Computing and what do you get? Hint: desktop virtualization is only the tip of the iceberg.

Leveraging Desktop Virtualization Technologies for Cloud-Oriented Architecture

The core realization behind Cloud-Oriented Architecture (COA) is that everything is potentially part of the Cloud. There’s nothing in the NIST definition of Cloud Computing that requires Cloud resources to live in data centers, after all. We don’t mean to say that mobile devices are inherently part of the Cloud, however. To qualify as Cloud resources, it must be possible to provision and deprovision them automatically, with minimal management effort or service provider interaction.

Now we’re getting somewhere. We have the technology to dynamically provision and deprovision VM instances on mobile devices, since that’s what remote virtual desktops are all about. We simply need to expand the approach, as shown in the figure below.

Instead of porting desktops in VMs to remote devices, we can use a similar approach to automatically provision any VM instance into a reverse sandbox on any device, since reverse sandboxes can run on anything, including smartphones, iPads, laptops, or even embedded systems like the computer in your car or proverbial fridge. From the perspective of the Cloud provider, remote environments are simply an extension of their data centers that they can automatically manage and provision. From the user’s perspective, they can have any Cloud capability they desire running locally, within the physical constraints of the remote environment.

Such constraints, including bandwidth, reliable connectivity, memory, storage space, and UI limitations, present both challenges and opportunities. Yes, smartphones have less physical resources than servers to be sure, but the resources they have are each riding their own Moore’s Law curve into the stratosphere. Think your phone is too slow or small to run part of the Cloud? Wait a week or two.

The ZapThink Take

So, what are dynamically provisioned Cloud instances on remote devices actually good for? Security is the obvious answer, but only the starting point. The reverse sandbox protects the VM instance on the device from outside attacks, and gives the Cloud provider centralized control over the instance.

COA also resolves the problem of remote wiping. IT managers are concerned about devices falling into the wrong hands, and often require the ability to fully erase such devices remotely. For employees bringing their own devices (BYOD) to work, such draconian measures are understandably unacceptable. But if all the sensitive corporate data and application access resided in a VM instance on the device, separated from the rest of the device by a secure sandbox, then the remote wipe would simply mean deprovisioning this instance. The device would remain fully functional, except for the secure capabilities in the sandbox.

Those security examples, however, are only the price of admission. The potential for COA is limited only by your imagination, as the limitations of bandwidth, memory, and storage get Moore’s Law-ed into irrelevance. For example, what kind of massively multiplayer game could you build that ran entirely on mobile Cloud instances? Or perhaps COA will enable Facebook’s Next Big Thing, keeping them from being an immense one trick pony? And remember the Search for Extraterrestrial Intelligence (SETI) screensaver from the 1990s? It processed chunks of raw data on individual PCs while they were idle. If we could look for aliens with 1990s technology, what Big Data mysteries do you think we can solve this decade?