Our first article explained a little about virtual mobile infrastructure (VMI) and what exactly it is. In this article, let’s explore how virtual mobile infrastructure works.
Primer on The Cloud and Virtual Machines
Firstly, let’s discuss the cloud. Traditionally, computer information was stored and processed locally (aka on the physical device). It wasn’t necessary to maintain an internet connection, because the data on your hard drive and the processor was in the same “box.” You may retrieve processed data from a network, but most processing and storage was done locally.
In the modern world, this is still true to a great extent but more and more, services and products live mostly online: Google Docs, Microsoft Office 365, and social media are excellent examples of services that live almost entirely in the cloud. The data is not on your computer, nor are most processing instructions executed on your computer. An internet connection is required to interact with your online data, and only minimal storage and processing is performed locally on the physical device.
This is a great way to collaborate because data is centralized “out there” and every participant simply logs onto the same service to interact with the data. It is also a great way to keep data backed up remotely, so even if your house burns down, your data safely remains in a climate-controlled, protected server farm somewhere.
Next, virtual machines are a way to set up an OS-within-an-OS. You can even put a VM within a VM on a physical device, Inception-style. If so decided, the inner OS (the guest) is sandboxed from the original OS (the host), which protects the host from viruses that infect the guest. See my last article for a more thorough description.
VMs on the Cloud
In a VMI scenario, the guest OS lives on the host machine, which itself is a remote server in the cloud. When a user wants to access or process information, they interact with the VM (the guest) via a display window on the client’s (user’s) smartphone. The display window produces a kind of hologram of the VM on the client device.
This image is pixel information only, which means the client device’s operating system is unable to read, analyze or manipulate any of the information on the display. The only thing a smartphone’s OS can see is an image. There are no buttons to push, text to copy, fields to fill, or – and this really important – processes to run, because all of this is rendered as pixel and image information, not button, text, or field information.
To interact, the display window captures input information from the client device and sends it to the remote server, where the input is translated into actions on the VM. Let’s walk through an example.
The user wants to login via the login button in the upper right corner of the window. The user taps that area of the image on the client device, and the client device captures the location of the tap. The location information is sent to the remote VM, which deduces that the location of the tap corresponds to the “Login” button. The VM then executes the steps to open the login screen, converts the screen image to pixel information, and ships the pixels off to the client device. The client display window receives the image and displays the login screen, which the user taps to place the cursor, the VM recognizes the location, and so on. The user, client device, display window, and VM continue to interact in a circular fashion.
It is a bit like an interactive television, where the image information is updated for every change and the update is displayed by the client device.
Notice that all information is held and processed off-device. The confidential corporate data never arrives or is processed at the client device, even in RAM, except as image information. The user cannot simply copy/paste or modify the data like normal. This is very different from traditional systems, wherein the browser or app on the client device receives data and instructions to render or generate input fields, buttons, and text locally.
Containers, Sandboxing, and Data Storage
For enterprises, the VM is usually a container, which is just a lightweight, task-specific VM. It lives on the remote host alongside many other containers, each of which may be assigned to a different user. 200 employees can share the same physical machine this way, completely segregated from each other’s data and processes. If Container 061 is corrupted by a virus, it is already isolated and won’t affect all the other containers.
Centralized data, such as a customer database, may live in another part of the host machine. It generally won’t be fully reproduced within each container, as this is inefficient and less secure. Each container, assigned to a particular user, can digitally sign every interaction with the database so all changes are recorded, and changes may even be verified outside the container before they are committed to the central database. This ensures malicious operations from an infected container or hostile client device never reach the database.
The network is a critical component of any VMI setup. Because no processing occurs locally and because the client device is essentially just displaying images sent by the remote container/VM, if the network connection is lost, everything halts. No interaction information is delivered to the remote machine, and no updated images are received by the client device.
Fortunately, modern mobile internet infrastructure allows for a low-latency connection, making lag times mostly imperceptible. As long as a connection can be established, VMI will perform and its security benefits will protect internal corporate data and infrastructure.
Ready to get started with Hypori virtual mobile infrastructure? Request a 14-day trial of Hypori.