Providing a VDI desktop to your users offers many benefits – Centralised management, simplified application deployment and flexible access being among the most obvious. However, the downside is that a significant investment is required in the backend infrastructure to support the VDI environment.
Many organisations are looking to avoid this cost by adopting cloud-hosted VDI platforms, where desktops are essentially leased monthly, and the costs become part of the operational budget.
This approach can work well but, as with all VDI options, mileage can vary and there are some significant design considerations to bear in mind.
Traditional Application Access (Client / Server)
In the ‘traditional’ desktop model below, our local application communicates with a server hosted in the datacentre, or directly with a backend database. This is how most users access and manage data – through locally installed applications which communicate directly with a backend server.
Latency or bandwidth issues on the WAN can directly impact the clients ability to communicate with the application server, leading to the dreaded egg-timer of doom, or even corrupt data if you are especially unlucky. The risk of data loss in this scenario is more likely simply because changes need to traverse the entire route from the local application, through the local office network, across the WAN and into the datacenter.
In-House VDI Application Access (Client / Server)
Hosting your VDI or terminal server locally to the application services removes this issue, as you are no longer dependent on the WAN to pass data between the application and the database. It is true to say that the VDI client or browser performance could suffer in the event of WAN connectivity issues, but the application session itself would still run optimally – you just might not be able to access it!
This is certainly preferable from an application performance and integrity perspective. It also means that in the event of true application performance issues, we can rule out the WAN as the source of the issue immediately, and move on to investigate the desktop, application servers or database.
This type of deployment also offers potential security benefits. I have worked with customers in the past to remove internet explorer from the local desktop and deploy a ‘hosted’ version of the browser to the desktop. The benefit here being that all web browsing is happening remotely on the terminal server, thereby removing the risk that local desktops could become infected by malware via the browser.
Cloud Desktop Application Access (Client / Server)
Now this is where it gets a bit tricky. If you have outsourced your server and desktop estate wholesale to a cloud service provider, then you should be able to replicate the model shown in the previous example, with VDI and application services running locally together in the same environment, then all you need to worry about is the link between you and your hosted services. However, if you are taking desktops as a service exclusively, there are additional considerations. Take a look at the diagram below.
Now our user’s experience is dependent on data both entering and exiting the corporate WAN via our VPN. We have latency between the office and the DaaS platform, and latency between the DaaS platform and the application servers. This is a highly simplistic model as it doesn’t take account of any application AD integration or other advanced components.
It could be that the latency introduced in the above model is negligible, and therefore doesn’t restrict your users. However the complexity it introduces into the solution should be weighed carefully against the perceived benefits.
Similarly, if you are making use of cloud based services such as Office 365, data will need to enter and exit the desktop platform as users work. This will generally occur through an internet connection provided by the DaaS vendor, as shown below.
So are you being charged for the movement of data between your DaaS solution and other cloud services? And if so, does this make the solution less viable? Some services do offer you the option to use your existing WAN connections for this type of traffic, which could certainly reduce expense, but would increase complexity and latency.
I’m not looking to knock DaaS providers here. Some are priced very competitively, and in the right scenario can provide a significant saving compared to traditional desktops or in-house VDI, but it is however important to fully understand how it aligns with your IT practices, and what the implications of change may be.
Cloud-hosted desktops offer businesses a route to delivering flexible desktop and application access to both internal users and partner organisations, without a requirement for the large capital outlays associated with ‘in house’ deployments. However, when exploring hosted desktops, you should be mindful of exactly what it is the desktops will be used for. If there is a large dependency on core services which reside outside the proposed desktop platform, you should look carefully at the costs associated with the WAN links or data flow required, and the complexity that such a solution may introduce.
In pretty much all instances, the best solution is to have the desktop or terminal servers hosted locally to your backend services, this should be investigated with the hosting provider prior to any agreements being signed. If practical, the desktop hosting provider should allow for core services to be hosted locally to the desktop, or even provide the ‘as a service’ desktop platform on hardware within your own datacentre, however the latter option would obviously come with less flexibility than standard ‘off the peg’ offerings.
SaaS options should also be investigated carefully. If you are going to the trouble of outsourcing your desktops, it would be worth discovering if your LOB application vendors offer an ‘as a service’ option. These services are designed to be used across the internet, and may remove the need for your in-house application servers completely. It may even be possible to layer something like Azure Single Sign-on or two factor authentication services over the top to make the user experience as seamless and secure as possible.