How to move your VDI workloads to the Public Cloud?
Article originally posted by Citrix CTP, Marius Sandbu
A couple of weeks ago, I had a webinar together with Goliath Technologies about what we need to consider before moving your VDI workloads to Public Cloud. In this blog post I will try and write a summary of the various stages that should be part of the journey and also some of the pitfalls that you can encounter when moving your VDI workload to Public Cloud. Moving a VDI service to Public Cloud is not a simple task, and also with new services such as WVD from Microsoft, which one should you choose for your organization when starting your cloud journey?
One of the first things that we should always consider is understanding the destination. Moving to Cloud might mean moving heavy services and business critical applications to a datacenter which might be a lot further away than it is today. That latency increase will affect the end-user performance, and secondly VDI workloads should always be placed together with the data to ensure that when moving or building these new services that they are grouped together.
The different building blocks of the journey
Since the pandemic started, many organizations have accelerated their cloud journey to take advantage of the properties and innovation the cloud provides. However, the move to a cloud platform is moving to an entirely new ecosystem which requires understanding, expertise, tooling and ensuring that existing services can properly run in the new ecosystem or if it requires changes. The journey needs to be split into different workflows to first give the organization insight into the provider(s) then into an assessment to ensure compatibility of application and services and once that is complete look into what kind of tooling and expertise needed to run services in the cloud. Once that main material is in place you need to build a foundation which typically consists of network design including security and governance mechanisms, including other monitoring services to ensure that we can properly monitor the availability of services on public cloud.
Change in tooling and expertise
As mentioned, moving to the public cloud requires a lot of new knowledge, just to showcase how many changes there can be for a small part of the infrastructure, when moving from an on-premises datacenter running VDI to a Public Cloud based service.
In addition, the main cloud providers announce close to 1,200 new changes and new services on a yearly basis, which requires that we pay more attention to what new capabilities cloud providers are building.
The different options and platforms
Moving to a Cloud based ecosystem might also mean you need to change to a new VDI platform, depending on what is supported and not. For instance, if you plan to move your VDI workloads to AWS because the entire organization is moving its services there, then you need to either use the cloud provider’s native offerings or use a vendor that supports AWS.
There are also some differences in terms of image management. For instance, while Citrix and VMware provide cloud based image management, Windows Virtual Desktop has no native imaging mechanism, which means that you either need to rely on other Azure services or use 3rd party management tools for your WVD environment. Either that or you have to wait for Windows365 which provides its own provisioning mechanism which is built into the service.
Building the foundation
Before we start to build services or migrating workloads we should always have a foundation in place, here we recommend looking at what the cloud providers already offer of predefined templates, as with Microsoft and enterprise-scale architecture here → Cloud Adoption Framework enterprise-scale landing zone architecture – Cloud Adoption Framework | Microsoft Docs
The cloud providers also have different reference architectures for certain compliance standards as well, such as with PCI-DSS and such which can also be used as a baseline.
Some pitfalls you should avoid
Before moving your VDI environment to a cloud-based one, there are still some pitfalls you should remember to avoid.
- Plan and assess properly – Most of the cloud providers have tools and services that can help to assess current environments to give you insight into which virtual machines are supported to run in Public Cloud (and can also show cost!) and also give you an idea on what resources that cannot be moved.
- Pre-allocate resources – Once you have a plan in place and decided for a cloud provider and you are starting on a project, it is important to try and pre-allocate quotas for virtual infrastructure early. There have been scenarios where cloud providers have run out of capacity and therefore customers needed to wait to get access to required hardware.
- Not all cloud regions are equal – Even if the cloud providers have multiple datacenter regions around the world, not all regions are equal. There might be services that are available in one region but not in another. For instance, if you plan to use a specific storage service to host User and application profiles, make sure that the service is available in the other regions you plan to deploy a VDI platform to as well.
- Latency and Proximity > Availability – Some applications might be extremely picky in regards to having ~1MS latency. The cloud provider data centers are pretty large and having services fragmented into the cloud datacenter might also drive the latency up to a level that affects the end-user experience. Most cloud providers have options to group virtual infrastructure as close together as possible within the same datacenter. This however reduces the SLA availability that the cloud provider can provide.
- Not everything can be migrated – We will also encounter services that cannot be migrated or rebuilt. This can be specific workloads running on specific hardware or locked down virtual appliances that are not supported. This is important to figure as part of the initial assessment.
- Cloud native security – In regard to security, it should be redesigned to fit into the cloud platform. Most cloud providers have an extensive list of services that is tightly integrated into the rest of the cloud platform. Look into using as much cloud native as possible and not lift and shift the existing security platform.
- Data gravity – When migrating, ensure that the VDI platform and applications have fast access to backend data that it requires, and ensure that you do not have a lot of application traffic going back and forth over a VPN connection.
- Network and support – As part of all cloud providers, you get access to a software defined network, but this implies some restrictions in terms of what kind of network protocols are supported. Some network appliances use GARP/RARP as a protocol to provide high-availability, which is not supported in Public Cloud. Therefore, in most cases you will need to rebuild services such as edge firewall clusters or we can replace it with a cloud native backup service.
- Monitoring – And the final aspect is monitoring. When moving to a cloud-based platform, you should look at using the cloud native monitoring tools to get insight and information about the platform. However, you should also have external eyes on the platform. So having an external monitoring tool that can monitor availability from an end-user perspective is important, because you want to get notified before the end users notice that the cloud platform is having issues. One good tool for this is the Goliath Performance Monitor from Goliath Technologies.
Rinse and Repeat
After you have gotten through all the pitfalls and successfully built a new VDI solution on a cloud-based foundation, it is important to properly allocate time and resources that can pay attention to all the updates that both the cloud provider and the VDI vendor is adding. There might be new services introduced that can increase the security, provide more flexibility or even introduce new hardware that we can take benefit from to reduce the overall cost of the VDI platform.