What is Citrix Cloud?
I recently published an article around the Virtual Apps and Desktops service, a Citrix Cloud offering that allows customers to host backend Virtual Apps and Desktops management components in the cloud. With Citrix Cloud, while the VDAs remain in the customer’s network / control, the control plane is hosted by Citrix and managed by them.
There are several advantages of Citrix Cloud. Some of the main incentives are that Citrix manages components on your behalf, Citrix makes those components available, and Citrix continually updates components hosted in the cloud for you. The benefit is extra time given back to your IT teams, which can be dedicated to other important tasks within your organization. These are the differences between hosting Citrix on-premises and using Citrix Cloud services.
|Citrix on-premises||Citrix Cloud|
|Management Layer||Hosted by you||Hosted by Citrix on Citrix Cloud|
|Access Layer||Hosted by you by using StoreFront and traditional Gateway||Hosted by Citrix by using Workspace and Gateway Service (optional)|
|Availability||Your responsibility||Citrix’s responsibility|
|Updates and Management||Your responsibility||Citrix’s responsibility|
While Citrix Cloud is relatively simple to set up, there are a couple of deployment options to keep in mind if you are thinking of moving your on-premises deployments to Citrix Cloud, or setting up a brand new Citrix Cloud deployment.
Deployment Options for Citrix Cloud Services
The deployment options are fairly simple to understand, however for each option there are some positives and negatives that you should at least be aware of that may help confirm your decisions when architecting a cloud deployment for your apps and desktops.
With the Virtual Apps and Desktops service, the following components that make up the control plane sit within Citrix Cloud hosted on Microsoft Azure. Each component is managed and maintained by Citrix:
- SQL Server
- Citrix Director
- Citrix Delivery Controllers
- Citrix Studio
- Citrix License Server
- Citrix StoreFront (Optionally you can still make use of StoreFront on-premises)
- Citrix Gateway (Optionally you can still make use of your own Citrix Gateway)
The other infrastructure components like your VDAs, application data, user profiles, directory services, and so on still remain within your control and are hosted on one or more resource locations. A resource location is simply a location under your control, which could be a private cloud running Hyper-V or ESX, or a public cloud such as Microsoft Azure or Google Cloud Platform.
As mentioned above, some additional components, such as StoreFront and Gateway can still be hosted within the resource location and used with a Citrix Cloud deployment of Virtual Apps and Desktops. There are reasons why you would and would not host these components yourself. I’ll cover some of the different use-cases and the reasons why you would pick one deployment strategy over another.
Should you use Citrix Workspace in Citrix Cloud?
Citrix Workspace is the front door to your virtual apps and desktops. Think of it as a StoreFront hosted by Citrix on the cloud.
Whenever you sign up to the Virtual Apps and Desktops service, Citrix Workspace is available to use as part of the deal. You configure your own Workspace URL, which is suffixed by the .cloud.com domain. Your end-users use this URL to get access to their apps and desktops.
If VDAs need to be accessed externally through Workspace, you can configure a traditional Gateway hosted in your resource location that has access to the VDAs or use the Citrix Gateway Service.
There are some advantages and disadvantages with using Citrix Workspace as the front-door as opposed to a local StoreFront deployment.
- Citrix manages the availability of Citrix Workspace, which means one less thing for IT to worry about keeping healthy.
- Citrix Workspace is available from anywhere on any device with an internet connection. There is no requirement to spend time configuring firewalls and networks like you would for a local deployment of StoreFront.
- Citrix keeps Workspace up to date with the latest code and patches. You receive the newest functionality and themes without having to do anything manually.
- You cannot configure a URL using your own corporate domain like myworkspace.mycompany.com. Instead, you are forced to use myworkspace.cloud.com. Include the fact that your custom URL may already be taken by somebody else.
- Local Host Cache is not supported when using Workspace, so if your resource location loses access to the Citrix Cloud control plane for any reason, you will have problems accessing your VDAs.
- Customization of Workspace is possible, but not to the extent of a local StoreFront deployment. If customizing the look and feel of StoreFront is important to your organization, this may become a limitation for you.
- Organizations prefer peace of mind and control when it comes to updates for components like StoreFront, to avoid causing issues with clients that connect in such as thin clients. At times thin clients need firmware upgrades to support newer features, protocols and so on, so closer planning an alignment to upgrades is required.
One of the main advantages of using Workspace is that it is ready to go and can be deployed by the flick of a switch. This allows you to get up and running with a Virtual Apps and Desktops deployment quicker and with less effort than deploying StoreFront in your resource locations. If your organization spans different regions, a StoreFront deployment can become even more time intensive to architect, whereas Workspace is available from anywhere on any device that has an internet connection.
On the other hand, Local Host Cache is a main disadvantage of using Workspace. If your organization cannot afford any downtime, having StoreFront deployed within your resource locations is a must. A resource location can lose access to the Citrix Cloud control plane for many reasons such as local network connectivity issues, or issues impacting Azure. With StoreFront deployed within your resource locations, end-users will still be able to launch new connections to their apps and desktops.
As such, one of your main decisions for using Workspace could be based on Local Host Cache. That said, it is also possible to use StoreFront under DR scenarios, for example staff only begin using the StoreFront access method under outage scenarios, and at other times, they use the Workspace URL you provide.
When to use StoreFront in the resource location?
This deployment option pretty much goes hand in hand with the Workspace deployment option I just discussed.
As previously mentioned, StoreFront provides more flexibility for deployment architecture, greater customisation and increased security. The other main advantage is that it supports Local Host Cache, protecting your business from an outage between any of your resource locations and Citrix Cloud.
That said, there are some obvious disadvantages because one of the main reasons customers move to cloud solutions in the first place is to offload their infrastructure.
- More flexible customization of the StoreFront theme, allowing you to brand the portal as per company requirements.
- Local Host Cache support, which will allow users to establish new connections to apps and desktops even when there is no Citrix Cloud control plane connectivity.
- You can architect your StoreFront deployments in any way you like, as you have full control over server placement and where they sit in the network, and how end-users connect to them.
- Increased security as StoreFront is not by nature opened up to the internet.
- Ability to have a URL matching your corporate domain name, albeit in most scenarios the StoreFront URL will use an internal domain name.
- Extra pairs of servers within each of your resource locations that you have to manage, keep available and up to date. This is typically the opposite of what organizations moving infrastructure to cloud desire.
- Extra time to deploy and network StoreFront servers and configure firewall policies etc. that allows your end-users to connect.
One of the main advantages of retaining StoreFront servers within your resource locations is that it supports Local Host Cache. For many organizations, downtime is just not an option that can be risked. That said, as previously mentioned, organizations can still use Workspace as the primary method for accessing apps and desktops, with StoreFront as a backup if connection to Citrix Cloud is lost for any reason.
The downside of retaining StoreFront servers within your resource locations is the extra man hours it will take to maintain those servers, keeping them available and up to date. I have personally heard in the past from customers who are frustrated that even though they move to a cloud solution, they may have to continue hosting some components within their own datacentres. With that said, other organizations feel it a small price to pay for extra redundancy.
Note, if you need to use Local Host Cache with your Virtual Apps and Desktops service deployment, keep in mind the additional Citrix Cloud Connector scale and size considerations: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/install-configure/resource-location/local-host-scale-and-size.html
Should you use Citrix Gateway service in Citrix Cloud?
The Gateway service is another offering from Citrix Cloud that you can use with your Virtual Apps and Desktops service deployment. Using the Gateway service is an effortless way to provide users with secure remote access to their applications and desktops through Citrix Cloud, and negates the need for you to deploy, configure, and manage Gateway within your own datacentres.
When using the Gateway service, you must use Citrix Workspace, which is the Citrix Cloud edition of StoreFront, for which I have mentioned the advantages and disadvantages above.
- Citrix manages the availability of the Gateway. This removes the effort involved with managing a Gateway within your resource locations.
- There is no requirement to spend time configuring firewalls and networks like you would for a local deployment of Gateway.
- Citrix keeps Gateway up to date with the latest code and patches. You receive the newest functionality and security patches without having to invest time doing this yourself.
- The Gateway functionality can be enabled in minutes, whereas a Gateway deployment often takes much longer and includes multiple teams to implement.
- Citrix has multiple Gateway PoPs (Points of Presence) across the globe hosted in Azure and AWS. This helps keep latency as low as possible for users connecting remotely to their apps and desktops, and obviously provides redundancy.
- You still cannot configure a URL using your own corporate domain, such as myworkspace.mycompany.com. Instead, you are forced to use myworkspace.cloud.com. Include the fact that your custom URL may already be taken by somebody else.
- Local Host Cache is not supported when using Workspace, and you need to use Workspace to make use of the Gateway service. That means, as previously mentioned, if your resource location loses access to the Citrix Cloud control plane for any reason, you will have problems accessing your VDAs both internally and externally.
- Customization of the Gateway service is not possible, it is simply an ICA Proxy and your end-users still browse to Workspace to launch their apps. Workspace as previously mentioned is not as customizable as a local StoreFront deployment.
- Enabling the Gateway service changes the traffic flow to your virtual apps and desktops. For example, traffic now flows from your Cloud Connectors, to the Gateway service and then back to your VDAs. This is true by default even if you are local to the VDAs and your endpoint can make a direct connection. There are two features in particular that can help with this called Rendezvous protocol and Direct Workload Connection (Limited Preview).
- ICA Proxy is the only feature available. Other features like Content Switching, Load Balancing, and VPN, etc. are not available.
- There are limited authentication solutions tied into Workspace and no advanced technologies, such as nFactor authentication.
The Citrix Gateway service is a very easy-to-enable solution that provides secure remote access to virtual apps and desktops for your end-users wherever they are, and from any device.
One of the main advantages is the simplicity and reward. At the push of a button you have a secure remote access solution to your corporate apps and desktops that otherwise would have taken weeks to plan and deploy if done on-premises.
However, choosing the Gateway service over a traditional Gateway solution brings some disadvantages such as a change in the traffic flow that needs manual intervention, otherwise you get undesired traffic flow and increased network latency especially for internal clients that have direct access to VDAs.
You also cannot use some of the other features a Citrix ADC is well known for, such as Load Balancing, AAA, and other remote access solutions that can bring further value to your organisation.
When to use Citrix Gateway in the resource location?
Citrix Gateway is one part of the overall ADC solution, and a product many organizations will already have investments in. You see, in a typical on-premises Virtual Apps and Desktops deployment, Citrix Gateway and notably the ICA Proxy capability is used to provide secure, remote access to your apps and desktops.
The traditional Citrix Gateway and ICA Proxy can be used with your cloud hosted Virtual Apps and Desktops, rather than opting for the Gateway service.
- Many organizations have already invested in Citrix ADC and make use of Gateway to provide remote access to their apps and desktops, so there is minimal effort involved in integrating the solution with the Virtual Apps and Desktops service.
- The Gateway component also provides full VPN, or clientless VPN functionality. For example, some organizations provide a full VPN solution to their corporate device users, and a ICA Proxy for BYOD users.
- You can use a bespoke URL for the remote Gateway rather than using a suffixed cloud.com domain name.
- The traditional Gateway supports many different authentication mechanisms, including nFactor which can support many different authentication scenarios for corporate device and non-corporate device users, or your authentication strategy can even be based on location or other factors.
- Unlike the Gateway service, you may not have a traditional Gateway in different parts of the globe. This presents an opportunity for increase latency if an end-user is working from a location far away from where the closest Gateway is placed.
- Citrix Gateway isn’t a solution you configure from scratch in a couple of hours. You will spend many days architecting the solution from placement, to networks, routes, firewall policies, redundancy, etc. However, if you already have an existing deployment and have no requirement to build new, a lot of work is cut out.
- IT will spend extra time maintaining the traditional Gateway, and this could multiply if you have more than one resource location or span different countries that each have Gateway presence.
The traditional Gateway is a more powerful solution that presents the customer with additional features and benefits over the Gateway service.
For example, you can build and host multiple Gateways for customers, third-party vendors and staff. Alternatively, you can make use of other features, such as full VPN and have full control over the placement of the traditional Gateway, along with flexible security mechanisms.
On the other hand, there are downsides especially if you are a new customer. As mentioned, it is not a simple task to deploy a Gateway. It takes planning and careful consideration to achieve success. There are multiple success factors that need to be met when deploying a Gateway in one or more of your resource locations. Add to the fact that your organization may only need a simple ICA Proxy, which may make the traditional Gateway hard to justify.
Choosing between different deployment options for Citrix Cloud Services
Obviously, there are different deployment options available to you whenever you begin your Virtual Apps and Desktops service journey. It is important you understand what you can and cannot do with each deployment in advance, rather than realize when you are already in the middle of your deployment project.
I do not believe it is a bad thing that you have options. Some cloud solutions are all or nothing, whereas with Citrix Cloud and the Virtual Apps and Desktops service, you do have some options and flexibility around where you want to place some components.
The components in question are generally the ones that provide you with the access into your apps and desktops. Of course, it is one of the more fundamental blocks of your deployment, the access method, and one you will want to make sure you get right and cover all angles.
For some organizations, security, and redundancy may be top of mind and you may choose to keep StoreFront managed. Some organizations may want extra flexibility surrounding authentication methods and customizations, so retain StoreFront and even Gateway within the resource location.
Then, there will be some organizations that want simplicity. The requirements are not too complex and there is no desire to have extra customizations or authentication methods outside of what Workspace already offers, and there is no existing Gateway deployment so using the Gateway service makes sense and is just what the organization needs.