ra2 studio - Fotolia
- Tim Mangan, TMurgent Technologies, LLP
There are often valid reasons to include both application and full desktop delivery in the same organization, either on premises or in the cloud.
For decades, businesses have used Microsoft Windows operating systems and applications to create productive workflows. At the center of this approach is the desktop PC, which stores data and serves as an access point for a variety of physical, virtual and web applications.
Over time, much of the work within companies became more collaborative. At the same time, especially in large enterprises, control of sensitive data became more important. These two trends have led IT to keeping more data and applications on back-end servers where they can be both accessible and protected.
Meanwhile, there is considerable focus on moving to the cloud. All organizations must consider what applications and data to put in the cloud and what to keep local. Improvements in networking and remote display protocols have made it possible to deliver a wider variety of applications from data centers to desktops.
These trends mean IT departments need to put more thought into how they deliver applications to end users. There are two main remote application and desktop delivery methods:
- providing a full desktop via Remote Desktop Session Host (RDSH), VDI or desktop as a service (DaaS); and
- providing individual published applications.
With RDSH and VDI, applications run inside the data center alongside their data, while graphics are remoted to the end-user device. DaaS is, in essence, managed VDI hosted in a public cloud.
Published applications are available from the major vendors (Citrix, VMware and Microsoft) for RDSH and VDI, but a DaaS offering might not provide this capability. Published applications are used more often with RDSH than with VDI, primarily because it is a more mature technology.
Application vs. desktop delivery
Because of operating system and application migrations, there is often a need to separate different applications into silos in the data center. But whenever a user's applications are in more than one place -- either on different servers or on the server and local -- full desktop delivery makes the user experience more difficult. Users must navigate multiple start menus to find the application they want, and there are often issues with locating data stored on the different desktops. In these cases, it is better to publish individual remote applications instead of providing full desktops.
Remote applications technically run on a secondary desktop, but the user doesn't see it, and only the application-specific graphics are remoted and integrated into the local desktop. Unlike with full desktop delivery, remoting at the application level does not usually adversely affect performance of the systems and networks involved. In fact, choosing individual remote applications allows IT to support the needs of each application independently, which can significantly improve performance and usability. Remote applications provide more flexibility as well; for example, they allow for server-side or client-side graphics rendering on a per-app basis.
Remote applications force IT to better plan for providing access to user data, however. If not, synchronization issues can occur because Microsoft's roaming user profiles and many third-party replacements do not handle simultaneous logon sessions by a single user account.
For each unique application use, IT should choose application and desktop delivery methods based on what makes sense for both admins and end users.
Virtual apps or native apps?
Add app layering to your virtualization tool belt
Resolve the virtual vs. web app debate