chanpipat - Fotolia
VMI has many of the same benefits and drawbacks that come with desktop virtualization. And just like VDI isn't for everyone, VMI doesn't suit every use case.
I wrote about virtual mobile infrastructure (VMI) in late 2014 as an attempt to raise awareness that a few vendors were working on products that allowed companies to deliver mobile -- specifically Android -- applications from a data center. It works in much the same way that we have been delivering applications via Remote Desktop Services (RDS) for the past twenty years.
Despite two decades of separation, the advantages of VMI are nearly identical to those of desktop virtualization: No data lives on the endpoint device, the application can be close to their data and you can deliver applications made for one OS to an otherwise incompatible OS. Of course, the same disadvantages apply, too. For example, you can't use the apps offline.
But how does VMI fit into an organization? Do you view it as a neat parlor trick that's in the "Just-because-you-can-do-it-doesn't-mean-you-should" category, or could it be used strategically in certain use cases? Additionally, do the advantages and disadvantages of this kind of remote application technology carry the same weight with mobile use cases as they do with more static, office-based ones?
Early in the development of desktop virtualization, many people viewed what we then called Terminal Services (now RDS) as frivolous. Many doubters turned into believers after they saw the technology and applied it to the various issues they had with remote access, three-tier applications and branch offices. Since then, the technology has seeped into all corners of desktop infrastructure, and even into the cloud.
VMI might be on a similar trajectory, but there are some differences that may or may not be its undoing.
What makes virtual mobile infrastructure different
Let's start with the benefits. Yes, VMI offers some of the same advantages as desktop virtualization in that you can store data in your data center rather than on the endpoint, reduce latency, deliver applications to unmanaged endpoints, and run Android applications on iOS. If you have a mission-critical Android application that can't run on any other platform (the thought of which sounds preposterous, but hey, it could happen) and these things are important to you, then VMI is a great way to go.
But let's say you're starting from scratch. You need to support mobile users securely. You don't necessarily trust the endpoint device. You don't want any data to reside on it. What's your next step? Do you build an Android app and deploy it with VMI, an app for each OS that your users have, or do you build a Web app? I don't know if VMI is the best option from a green-field perspective.
Now you might be wondering about offline use. From the very early days of desktop virtualization, we could point to the mobile workforce as the bane of our existence. Our dream of removing laptops that require maddening remote support sessions went up in smoke as soon as we realized that not only did the user have to have Internet connectivity, but that connection also had to be of a certain quality. In the Windows world, we managed to get used to that because users are more-or-less tethered to a device that is on the network or has access to broadband Internet. The mobile workforce represented a relatively small percentage of our overall users at that time, so they were the exception to the rule.
With VMI, we're flipping that ratio around. The entire point of VMI is to deliver applications to mobile users, and that means only a small portion of our users will have consistent, reliable access to the backend application servers. The rest are mobile, and are subject to the conditions of the airwaves on any given day. Is our mobile data access fast, reliable and expansive enough to support a mobile use case? Are the VMI protocols good at dealing with the issues inherent to mobile data connections?
Who should try virtual mobile infrastructure?
On one hand, you could say that mobile data has never been better; the only time anyone is ever truly offline nowadays is in a plane or on the subway, and it's not a big deal to require connectivity. On the other hand, you could say that because the vast majority of VMI users are out in the mobile wilderness, you can't just take for granted that mobile data access is "pretty good these days."
Users are conditioned to deal with shaky mobile connection from time to time, but that manifests itself differently in a native app as opposed to a remote app. Native apps work, but work slowly. Remote apps stop responding to clicks and stop updating the screen. If a user experience is slow, that's one thing; unresponsive is another.
So that's where I'm at on VMI today. I think it could prove useful in certain situations, but I'm not convinced that people will choose to deploy an Android app/VMI stack when starting from scratch. The disadvantage of not being able to use it offline doesn't feel like an issue to me as long as we can have a good user experience when online, regardless of the connection. It means there's one more thing that VMI has in common with the early days of desktop virtualization: The company with the best remote display protocol will have the most success.
Just got used to VDI? Now try VMI