For years, IT organizations across many industries have relied on virtual application delivery, or “app publishing.” These solutions include offerings like VMware Horizon Apps and Citrix Virtual Apps and Desktops (previously Citrix XenApp). You see these solutions heavily represented in regulated industries like healthcare and financial services, as well as in government agencies, amongst others. In these sectors, app publishing is used to deliver secure access to regulated applications and data to users. A great example is when physicians use app publishing to access healthcare applications and patient data. This is largely a mature technology that has been in the market for decades. Over the years a common set of challenges has emerged that admin teams deal with every day. As such, this market is ready for disruption!
VMware is here to disrupt the app publishing market with the availability of a new “Apps on Demand” feature of App Volumes. The combination of App Volumes’ separation of operating system (OS) and application layers to simplify image management, plus the new on-demand app delivery of Apps on Demand, can have significant benefits for published app administrators in reducing app management time and farm infrastructure requirements.
Before we get too deep into App Volumes with Apps on Demand, let’s review the challenges of traditional app publishing. If you recognize any of these issues in your environment, then App Volumes with Apps on Demand may be the tonic for what ails you!
Common challenges with traditional app publishing deployments
The traditional deployment model for app publishing is based on dedicated “farms” or “silos.” These are logical collections of physical hosts that provide dedicated capacity to an app or group of apps. Each host in the farm has the underlying OS with the needed applications installed on it. There are, however, several common challenges with this farm-based model.
The most prominent issue with the farm model is managing OS and app updates to the host images on the farms. Any time the OS or any of the applications need to be updated, all the host images of a specific farm need to be updated. If it’s a Windows OS, you have semi-annual service branches, Patch Tuesdays, and patches for high-severity vulnerabilities to apply. The timing for application patches varies by vendor and changes as new vulnerabilities are discovered in the wild.
Once patches are applied to the host image, IT will perform user acceptance testing (UAT) to a limited set of test farms, prior to rolling out in production. During production rollout, there may be failures that require rollbacks (however, uninstalling applications is not a true rollback and in fact can leave files behind on the OS that have a residual impact). If updates install properly on the hosts, then the hosts in the farm typically need to be rebooted, which is always painful.
The app management lifecycle is a well-known challenge to published app teams and is cumbersome and costly.
Other common published app management issues include:
- Team coordination. There may be division of ownership between the host OS team and the application teams, such that the app updates can only be done subject to timing windows offered by the host team. Delays can impact security and performance.
- Business continuity. In order to update a farm, it has to be brought offline. For critical applications, a temporary farm may need to be configured to house the users, who must be “drained” from the production farm and then brought back once the update is completed.
- Entitlements. App publishing is often provisioned to users on a machine-based model. This method requires entitlement for users on each host, in the farms for which the applications they need are housed. As farms grow in number and size, this can become increasingly complex to manage.
Entitlement management requires balancing the needs of users with management of images and apps. Users need to be entitled to apps on the hosts in the farms where their specific apps reside. If there are any changes, then the admin needs to re-rationalize the entitlements. When there are multiple app combinations requiring specific apps to be deployed in multiple farms, users need the entitlement to the farms with the specific combination of apps needed.
In sum, managing app publishing environments can be difficult and cumbersome work, and the challenges can become more acute the larger the environment. These common issues create yet larger downstream challenges that compound the issues with more complexity.
- Image sprawl. As more applications are rolled out via app publishing, typically more and more different OS images are created to support different user groups with entitlement to different combinations of applications. Environments become increasingly complex and time consuming to manage.
- Version sprawl. Users may want to continue using a version of an app they prefer, even after new versions are made available. Often, rather than force users to use newer versions of apps, multiple versions of the same app are published to users. This can cause confusion on which app to use and can result in an increase in helpdesk tickets.
- App security risk. When high-severity vulnerabilities are found that require immediate action to patch or update, often systems may go unpatched due to the complexity of updating all the required host images and the coordination across teams, which creates risk.
- App “diversity.” Because app publishing can support legacy data center applications, these applications often don’t get the modernization they probably need. Developers may have left the organization, making it difficult to re-code the apps they developed. Instead, these apps can only be delivered via app publishing. Meanwhile new modern apps are built, and the overall app fleet grows more diverse — and, therefore, more complex and costly to manage.
Finally, the farm-based model means you are essentially building capacity to support the peak user access to those applications, even if your farm never reaches that capacity. Customers often tell us that their farms are overbuilt and operating far below capacity. This actually defeats the purpose of virtualization: to optimize usage of your infrastructure! And, that overinvestment in hardware also brings associated image and entitlement management burdens for those additional hosts!
Attempts have come close, but no cigar
VMware tried to address the difficulties of app management with App Volumes 2.x, which introduced AppStacks app layering. This release was cumbersome in that it required multiple AppStacks (layers) to be grouped together. It also impacted users who experienced delays in accessing their desktops at runtime as multiple AppStacks were attached to desktops. VMware reinvented App Volumes 4 by removing AppStacks and streamlined app attach, which proved to improve performance. (Customers now love it!)
Similarly, Citrix introduced Citrix App Layering to address app management issues. Implementing Citrix App Layering requires a complete change in how admins manage the published app environment because you need to control the OS, as there was no separation between app and OS layer. DLL compatibility issues were also reportedly common, causing performance issues.
Introducing App Volumes with new “Apps on Demand” to reduce app management time and infrastructure needs!
As stated, Apps on Demand is a new capability of App Volumes. It is the combination of App Volumes’ separation of OS and app layers and new on-demand app delivery (of Apps on Demand) that can have significant benefits in reducing app management time and farm infrastructure requirements.
With App Volumes, an abstraction layer separates the application from the host OS. The application runs in its own virtual container, which can be attached to the OS in real time, so it doesn’t have to be installed to the OS of the app publishing host. This means IT can strive to use a single evergreen OS image for app publishing — with no apps installed! This has huge benefits:
- Admins can update the OS image and the applications when needed without the headache of coordination.
- Hosts do not need to be rebooted on application changes because apps are not installed on the OS image.
- Only a single app copy is needed to support all users.
- A single user entitlement in App Volumes is all that’s needed, eliminating entitlement management challenges.
Before Apps on Demand, App Volumes allowed applications to be attached to a non-persistent desktop at initiation of the desktop session by the user, so all the user apps are attached to the desktop at runtime. Remember, the apps are not installed to the OS, but attached running in their own virtual containers.
But now, when coupled with the new Apps on Demand capability for published apps, App Volumes applications are attached to published app (RDSH) hosts in real time: only when the user clicks on a given application! As users access individual applications, the host capacity is used as it reaches an admin-defined capacity threshold (e.g., 90%), and then a new host is spawned for the next user session, and so on. So, dedicated farms built to peak user capacity are no longer needed, which potentially reduces infrastructure requirements and associated management.
Every user session is essentially randomly built in real time, based on what apps the users access.
To net this out, what value does new Apps on Demand add to App Volumes for app publishing administrators?
- No need for traditional dedicated app publishing farm models! You can strive to use a single farm with an evergreen OS image and attach the applications in real time.
- As one host fills up with published app sessions to capacity, then another host is spun up. This results in elimination of overbuilt dedicated farms and increases the potential for infrastructure reduction and cost savings.
- Each user session is dynamically created based on user behavior. Because the apps are all on a common OS and host, inter-application features common in Windows (e.g., copy/paste) all behave as the user expects.
This is AWESOME! But will App Volumes support all my applications?
One of the reasons App Publishing is still so popular all these years later is that it can support older, legacy applications in the data center that have not been re-coded to more modern file types. They often run on older operating systems. Virtualization has become a common answer for legacy application longevity.
App Volumes can support most application types. Recent enterprise customers have reported 99% compatibility with App Volumes capture, which can be accomplished with a single click for most of your applications.
App Volumes also supports MSIX app attach natively for your modern Microsoft apps. In addition, VMware ThinApp comes with App Volumes and can run isolated applications on many legacy operating systems, including XP, Vista, and Windows 7 applications.
Support what you got: VMware Horizon, Citrix, and Microsoft deployments
Today organizations are looking at DaaS and multi-cloud to augment or extend their legacy on-premises VDI and RDSH deployments. The great news is App Volumes with Apps on Demand offers support far beyond Horizon Apps. It can also be used with Citrix app publishing and Horizon Cloud on Microsoft Azure deployments with Azure Virtual Desktop Windows 10 or 11 multi-session. You may have one of these solutions, or even all three.
It’s easy to deploy an App Volumes server to get started, so talk to VMware about reducing the management burden and infrastructure cost of your app publishing environment.
