Session-based remote computing: The path of least resistance to mobile app transformation

It was with great interest today that I read my ZDNet colleague Matthew Baxter-Reynolds' Building tablet and smartphone apps for the enterprise.

I knew this article was in the making, and I was curious to see his take on mobile application transformation.

This is a subject a lot of enterprises are now struggling with, as there are a great number of Line of Business (LOB), in-house-designed and commercial off-the-shelf (COTS) applications that they want to get out to tablets, smartphones and ultrabooks.

I was a bit disappointed to see this, however, so early in his article:

"The most basic thing you can do is let them dial into a Windows desktop through virtual desktop infrastructure (VDI). The problem with this approach is that you're trying to use a post-PC device to access a PC-era device. It can be very unsatisfying for users to operate systems in this way. It's an approach that works well enough if the user has to make very occasional access to a system, but if you're expecting that as the be-all and end-all of your solution, you should expect some light rebellion."

As a disclaimer, I happen to work at Microsoft, and part of what I am tasked to do at the company is to assist service providers in helping their enterprise customers as well as ISVs enable desktop applications for mobile consumption.

So you can either listen to me very seriously as a SME in this area, or take it with a grain of salt as vendor-motivated diatribe.

Now, with that bit of business out of the way, I think there are a lot of misconceptions about the role of a mobile device in terms of how to best enable it for enterprise applications. 

With a mobile app, as Matthew lays out in his article, it is possible to present it as web/HTML, or expose it as web services on the server and have the app on the device interact with those web services, like most Windows Store (WinRT API) apps do today.

You can also have "fat" WinRT API and iOS and Android apps on ARM, but then you run into serious memory and processor limitations. So the question is, do you take a desktop app and turn it into SaaS and optimize it for remote viewing/execution and multi-user concurrency, or do you completely port it over to a new methodology entirely, which is a lot more work?

That's a big decision point for ISVs and enterprises today.

Because there's no easy way you can port a traditional Win32 desktop app to an ARM-based device. The memory and CPU constraints on a lot of these home-grown apps would not make a tablet or a smartphone an ideal platform for running them locally.

Dalvik and Android especially have issues with with large amounts of memory, as does native iOS code. In these cases, you are better suited to something like a SaaS approach like I described above.

Let's not even get to the real issue as it relates to the level of effort to do an application transformation to something a mobile device can consume natively. Any complex enterprise application will require separating the UI from the business logic and transactional processing engine, in order to make it multi-tier. 

If the enterprise has already done this, such as part of an overall SOA effort that might have taken place a few years ago, the application transformation approach Matt describes makes a lot of sense.

But the reality is that many enterprise apps are monolithic in nature, may have been running in their environments for a very long time, may lack appropriate documentation and original source code, and there may be institutional knowledge loss due to the fact that the original authors of the code may no longer be employed by the enterprise.

There's also the issue that many enterprises or SMBs just do not have the core competencies in-house to port desktop applications over to mobile platforms, or the budget for a systems integrator to do this for them.

In these cases, the quickest, most painless way to get your mobile devices running these apps are through DaaS technologies such as Microsoft Remote Desktop Services and Citrix XenApp.

There are VDI technologies avaliable from these and competing vendors as well, but if we are specifically talking about application enablement, session-based methods make a lot more sense than what is bandied about as "VDI."

First, let's describe that "VDI" is. VDI is assigning an individual virtual machine (VM) running an instance of Windows for each user session running on a Type-1 hypervisor (Hyper-V, VMWare ESX, Xen, KVM) coming in over the network connection using VDI client software.

This is expensive on resources because you aren't getting the best possible density for the purposes of deploying an application to mobile users. There are a number of reasons why VDI makes sense for specific-use cases, which is too complicated to go into detail for the purposes of this article, but mass-deployment of a LOB enterprise or ISV app to a fleet of mobile users is not one of them.

For application deployment at the best scale, you want to look at session-based technology. Not VDI.

What's session-based technology? Well, it's been renamed a whole bunch of times over the years, but many of you may remember it originally as Citrix Winframe or Metraframe and on the client-side as the ICA session protocol, and on the Microsoft side as the RDP protocol, which was introduced into Windows NT 4.0 Terminal Server in 1996. 

Today those technologies are branded as Citrix XenApp and Microsoft Remote Desktop Services (RDS). RDS is built into Microsoft Windows Server 2012, and RDP is now at version eight.

Neither XenApp nor Microsoft RDS need to be deployed using virtualization, although it is not uncommon to virtualize the session hosts themselves, as well as combine either of  these session-based technologies with App-V, for "sequencing" or streaming apps to the remote desktop to improve scalability of a session-based solution as well as to address application compatability concerns.

In any case, with session-based remote desktop and remote app implementations, you can expect at least double, if not quadruple or even eight times or higher the density of "pure VDI" solutions.

Why would you want to use one or the other? It depends on a number of factors, including which kinds of target devices you want the application to run on.

The Microsoft RDS client is native to Mac OS X, Windows XP, Windows 7, Windows 8 and Windows RT and Windows Phone 8, and there are some third parties actively developing RDPv8 clients for Android and iOS. 

Citrix, on the other hand, has the widest array of endpoint device support, with native versions of their Receiver avaliable for iOS, Android, Linux, Windows RT, and Windows XP/7/8.

Additionally, from a Provider/Enterprise application management and endpoint provisioning perspective, as well as the ability to provide an excellent portal that ties together a lot of the automation and device management needed to make a remote mobile application scale, Citrix brings a lot to the table. Although this is at extra cost, since their client license sits on top of Microsoft's RDS client access licenses and server.

Citrix has also recently released a Mobile Application SDK that allows Windows applications to be optimized for viewing and remote execution on mobile platforms. In addition to better enablement for touch devices, remote applications that are optimized with this SDK are able to utilize on-board GPS, sensors, cameras, and device buttons in the same way that locally running, native applications do.

The bottom line is this: If you want to transform a desktop application and make it available to mobile devices, the quickest path and the one of least resistance is to seek a session-based solution.

Are you looking to enable your Desktop Application for use in your enterprise's mobile devices? Talk Back and Let Me Know.