Top 5 DaaS Mistakes and How to Avoid Them - Data Locality

While customers would love nothing more than to consume virtual apps and desktops as a commodity service, the truth is that even in 2021, there are a number of design considerations that ultimately determine whether your Desktop-as-a-Service (DaaS) implementation is successful or not.

To paint the bigger picture, the following topics have (and will) be covered in this blog series:

• Part 1: Sizing & Optimizing Workload VMs
• Part 2: Single User vs. Multi-User
• Part 3: Data Locality
• Part 4: DaaS in Public Cloud vs. On-premises
• Part 5: User Experience

In this blog post, we discuss the concept of data locality--what it is, why it's important, and how to avoid mistakes regarding it as it relates to designing, and implementing your DaaS environment.

Based on the definition above, Data Locality is simply the position or location of data. Simple enough right? However, it's important to understand the context of the data we are referring to when it comes to DaaS.

Data in the context of the end-user typically includes:

1. User data
2. User profiles
3. Application databases
4. File servers and services

Typically, the best user experience comes from running your applications close to where the data is hosted, logically speaking, to minimize latency. After all, at the end of the day, apps are simply a mechanism by which users can access and interface with data.

On the other hand, data in the context of the workload VMs (which are the on-premises or public cloud-hosted VMs that are hosting your user sessions) encompasses the storage for the VMs itself. In this context, the best performance occurs when the VM storage is logically close to the VM compute.

For the purposes of this blog, we focus on the end-user context and some of the common mistakes we see customers make when it comes to addressing data locality with their DaaS deployment.

Mistake #1: Taking a Siloed Approach​

It's not uncommon for IT organizations to be siloed into different teams for end-user computing (EUC), Windows® OS, server virtualization, networking, security, databases, public cloud, and so on.

It shouldn't be a surprise, then, that one of the most common mistakes we see is when one team is tasked with implementing DaaS and they do so in a very siloed approach and make incorrect assumptions regarding data locality that can significantly impact user experience, budget, data governance, and security.

The first (and most important) step toward a successful DaaS implementation is communication and collaboration among all functional teams on what is and isn't feasible when it comes to where and how user and application data are hosted.

Mistake #2: Over-Reliance on Networking Capabilities​

The impact of network latency, jitter, packet loss, and overall bandwidth on application performance is often underestimated.

I often hear from my customers who simply assume that the network connection between their public cloud VNET/VPC and their private cloud are more than sufficient to support having their front-end applications hosted on workload VMs in the public cloud, while the back-end application databases remain hosted on-prem.

The reality is that many applications do not perform well when there is latency between the front-end and the back-end. I strongly recommend validating this assumption early-on in the design process, as this will have significant implications in terms of data locality, security, and replication requirements.

Mistake #3: “We'll Just Put All Our Data in Cloud Storage”​

There is certainly tremendous value in using cloud storage solutions like Microsoft OneDrive®, Google® Drive, Dropbox, Box, and Citrix® ShareFile solutions, as they provide easy and anywhere access to data around the globe. Leveraging the cloud storage vendors' native client to store and retrieve data from the Windows User Profile, cache, and synchronize data on the end-point can also improve user experience.

However, most cloud storage providers do not support application databases and can only support file-based data. These solutions also do not have advanced file locking mechanisms, which many applications require.

Mistake #4: One Storage Platform to Rule Them All​

It's important to understand that different types of applications have different data storage requirements.

Below are some examples:

• Microsoft O365 works very well with most cloud storage solutions (including the ones we just discussed above).
• Large ERP systems tend to employ their own proprietary databases and associated database services (e.g., SAP HANA®, Oracle® EBS, etc.)
• Engineering and Design applications leverage Product Lifecycle Management (PLM) and Product Data Management (PDM) systems with modern file services.
• Electronic Medical Records (EMR) applications often require high-performance and highly-available datastores.
• IoT and mobile applications store data in relational databases that are usually stored in data lakes.

Customers looking for a silver bullet when it comes to data storage for the purposes of simplifying their DaaS implementation usually end up disappointed. Determine the best platform for the application first and then focus on how to best integrate with your DaaS solution.

Mistake #5: Assuming Data Locality Always Takes Precedence Over User Locality​

All DaaS solutions share the same Achilles' Heel - vendors utilize some type of remoting protocol to allow end-users to interface with the virtual desktop or applications from their device.

As a result, user experience is impacted by their network latency, bandwidth, packet loss, jitter, etc. Although some vendor remoting protocols work better in a network-constrained environment than others, generally it is impossible to support a global workforce from within a single region.

This is why it's also very important to factor in user locality into the overall design. If a customer focuses only on data locality relative to the workload VMs accessing the data - and that ultimately increases the distance between the end-user and the workload VM - the resulting end-user experience may still be poor.

If your DaaS solution simply cannot support the distances and latencies required between your end-users and their workload VMs (based on data locality requirements), then a multi-region design with a data replication strategy may be required. This was the case for Kohn Pedersen Fox (“KPF”), a leading architecture firm with projects around the globe. KPF utilizes Nutanix Frame VDI to deliver business critical applications such as Autodesk AutoCAD and Revit, 3DS Max, and Rhino to their end-users. To deliver the most optimal performance for these applications, KPF has a multi-geo deployment with Frame Accounts deployed in AWS Regions in the US, UK, and Southeast Asia. To ensure their data is available in all three regions, KPF leverages Panzura for global data replication and synchronization. The following figure shows KPF's custom front-end site for access to Frame - users simply choose the region that they are closest to.

Summary​

Data locality is one of the most important design decisions for any DaaS deployment. Validating assumptions and limitations with how and where your data is hosted, replicated, and accessed influences all other aspects of your environment. Further complicating the situation is that, for most customers, there isn't a silver bullet solution for the different types of data that are usually required for DaaS. While keeping application data as close as possible to the front-end applications is generally the best approach to achieve the best performance, customers still need to take into consideration user locality as it pertains to networking thresholds of the remoting protocol leveraged by their DaaS vendor.

The good news is that, with hybrid cloud and multi-cloud DaaS solutions such as Nutanix Frame, customers have the ability to quickly and easily leverage their cloud and region of choice to deploy workload VMs around the globe to find the best balance between data and user locality.

If you want to learn more about how to integrate your various storage solutions with Nutanix Frame, details on networking thresholds, and expected user experience for our Frame Remoting Protocol (FRP), check out the following blogs:

• https://www.nutanix.com/blog/storage-and-frame-options-explained
• https://www.nutanix.com/blog/ux-with-frame-including-wan-and-mobile-scenarios-explained

Happy Reading!​

Not all DaaS are created equal. Check out this blog to learn how Nutanix Frame is different from Amazon, Citrix, Microsoft, and VMware solutions. If you just gotta have more of my scintillating prose, all of my blogs are available in one simple overview here. Happy reading!

And don't forget you can take a free Nutanix Frame test drive in a matter of minutes, so you can see Frame's simplicity and flexibility for yourself.