How to Architect your VDI Test Environment for Success

October 6, 2022

VDI test environments play a critical role in delivering a high-performing service to end users. These test environments are the last defense in catching defects before issues ultimately impact the end-user experience.

In most industries, a lack of proper testing can result in poor-performing systems that decrease productivity, decrease revenue, or impact the overall brand. In severe cases, such as healthcare, poor performance impedes doctors and clinicians from providing the best care to their patients. Organizations that utilize a suitable VDI testing environment create a competitive advantage in their high availability and performance.

In this blog, we’ll discuss some of the challenges presented to those responsible for architecting and developing VDI test environments, including tips and tricks to set yourself up for success.

Challenges

Change is a constant, but the speed at which major changes, including patches and upgrades, become available has never been faster. Alongside the rapid pace of change are increasingly complex technology stacks that constantly optimize policies and integrate new solutions.

Building a VDI testing environment that accounts for the entire production stack—from the hypervisor to your line-of-business applications—has become daunting. Any concerns raised about the cost of managing such an environment are justified. How can a VDI test environment mirror production without the exact cost of ownership?

My Experience

I recently went through a similar experience developing and deploying an internal testing sandbox.

We started by outlining our requirements. We wanted to create common scenarios we saw in the field to demonstrate our use cases better. A requirement was that the environment emulated what we commonly see in customers and the field, so we designed a small-scale Citrix site.

We wanted the environment to be simple to use and deploy, so we required a fully automated solution. Azure Cloud made sense to host our environment, as it could be centrally managed and accessed from any device, from anywhere. To streamline the process and adapt to any changing requirements, Terraform was chosen as the configuration language to define and provision the resources. Eventually, PowerShell was used to configure each server respective to their roles.

The project was ultimately a success, but there were a few changes that would have streamlined the process.

Planning

It all starts with planning. As with any complex project, your level of success will ultimately stem from your level of planning. It sets the stage and direction going forward by identifying the essential requirements of the environment.

Start by using a centralized project management system like a Kanban board. You can outline the higher-level tasks and identify any subtasks that might be required. Consider some predictable issues that might arise and plan contingencies for them. By accounting for predictable roadblocks and having a Plan B, more time is afforded to deal with the more challenging and unpredictable issues.

To prevent any delays in progress, pre-emptively consider any siloed teams that might be required. The Active Directory team might be needed to create test accounts and apply their policies, testing data might require some assistance from the Database team, and your Asset Management team will likely deliver any software licenses. Act before it’s necessary to give your team—and others—time to fulfill those requests.

As you plan your requirements and how to address them, aim for an environment that is simple to manage and easy to maintain. Suppose you are responsible for planning, designing, and developing the environment. In that case, it might be easy to forget who will take ownership—plan for easy management and maintenance down the road—for the owner’s sake.

Plan for automated deployment. It’s important to consider who will own the environment and equally important to consider who will be using it. Creating a fully automated deployment removes the error-prone configuration steps and simplifies usability. It also accounts for scenarios where two stakeholders might request the same testing environment. While it’s admittedly not so easy in an on-premises environment, for VDI Cloud-hosted environments, it’s as easy as “terraform apply.”

Design

From a design perspective, lean on your reference architecture and consider your unique service chain. Outline components that are crucial and required or peripheral and out of scope. An essential part of managing the cost is deploying only what is necessary to observe the desired outcomes.

Test cases and their desired outcomes often dictate many of the design requirements. For example, consider how the requirements for a system integration test differ from a user acceptance test. System integration is among the first testing stages, concerned with the functionality of intertwined dependencies between your security, networks, databases, and applications. Compare that with user acceptance, which is one of the final testing stages. Here, the concerns shift from functionality to acceptable performance and end-user experience.

As you progress through your VDI testing stages and get closer to production, it’s important to have an environment that gets closer and closer to mirroring production. The scale of your environment should not be as important as the configuration. It’s easier to extrapolate host and cluster capacities than to understand performance differences between security agents.

In my environment, when we tried to automate the creation of an Azure storage account, it introduced timing errors between some of the dependencies. When the servers would request access to download a file, it wasn’t initialized or ready for requests. We had not considered this in our initial design, and handling these errors was difficult. Ultimately, we decided to design a persistent storage solution that alleviated the timing issues altogether. While careful planning is essential and required, don’t be afraid to pivot.

Choosing Automation Tools

For developing such an environment, there are numerous automation tools that can be used to get the job done. Terraform was an easy choice for our implementation. It made creating, changing, and deploying the environment much simpler. We could use variables to account for different configurations and deploy a subset of the infrastructure at any time to validate our development. Using PowerShell made it straightforward to configure the resources and execute silent processes. Tying it together with a pipeline tool lets you manage any changes to your environment. Using Jenkins or Azure DevOps enables you to continuously integrate and deliver rapid changes in code and test the most up-to-date progress made by your developers.

Don’t try and reinvent the wheel. Consider your team’s experience and skillsets to choose the right tool for your organization. Use what’s already in your stack, eliminating learning curves and streamlining the entire project. When we began our project, Terraform was relatively new, and we weren’t aware of all its nuances. Knowing what I know now would have made it much easier.

Takeaways

The opportunity cost of an effective VDI test environment is high. The alternative leaves your organization vulnerable to defective code that results in poor performance or outages in production. In some instances, like healthcare, this is unacceptable.

There is no perfect VDI test environment. Because of some of the cost and infrastructure limitations discussed, creating an environment that mirrors production and collects accurate, actionable data can be challenging. That means it’s up to the architects and developers to deliver a viable product.

Because of this, there is no one-size-fits-all approach. Every organization has a unique technology stack, which means their requirements and the approach they take will be different. Stay flexible in your planning and design to leave yourself room to change course.

You should take time to carefully design an environment that addresses your testing needs, consider your test cases and the desired outcomes that need to be observed, and outline your requirements. It is always recommended to reference architectures and compare your chain of service.

When you use a centralized project management system, like a Kanban board, increased visibility into completed work and work-in-progress can lead to increased accountability. By laying out every process and task that needs to be accomplished, you won’t have to try and get everything done at once. Instead, develop with a building block mentality validating successful dependencies before you move on.

Conclusion

I hope you found this information interesting, and hopefully, there are one or two things to take with you as you build a VDI test environment for your organization.

For more information on this topic, you might want to check out my recent session at the Login VSI Vision 2022, where I presented Architecting Your Test Environment for Success.

If you have any questions or want to dive a little deeper, feel free to reach out via email or LinkedIn.