Tag Archives: Vdi

Cloud-Based VDI vs. DaaS - Is There a Difference?

With nearly all new technologies in the IT space comes confusion over terminology. Some of the confusion is simply because the technology is new, and we’re all trying to understand how it works and how – or whether – it fits the needs of our businesses. Unfortunately, some of the confusion is often caused by technology vendors who want to find a way to label their products in a way that associates them with whatever is perceived as new, cool, innovative, cutting-edge, etc. Today, we’re seeing that happen with terms like “cloud,” “DaaS,” and “VDI.”

“VDI” stands for Virtual Desktop Infrastructure. Taken literally, it’s an infrastructure that delivers virtual desktops to users. What is a virtual desktop? It is a (usually Windows) desktop computing environment where the user interface is abstracted and delivered to a remote user over a network using some kind of remote display protocol such as ICA, RDP, or PCoIP. That desktop computing environment is most often virtualized using a platform such as VMware, Hyper-V, or XenServer, but could also be a blade PC or even an ordinary desktop PC. If the virtual desktop is delivered by a service provider (such as VirtualQube) for a monthly subscription fee, it is often referred to as “Desktop as a Service,” or “DaaS.”

There are a number of ways to deliver a virtual desktop to a user:

  • Run multiple, individual instances of a desktop operating system (e.g., Windows 7 or Windows 8) on a virtualization host that’s running a hypervisor such as VMware, Hyper-V, or XenServer. Citrix XenDesktop, VMware View, and Citrix VDI-in-a-Box are all products that enable this model.
  • Run multiple, individual instances of a server operating system (e.g., 2008 R2 of 2012 R2) on a virtualization host that’s running a hypervisor such as VMware, Hyper-V, or XenServer. In such a case, a policy pack can be applied that will make the 2008 R2 desktop look like Windows 7, and the 2012 R2 desktop look like Windows 8. In a moment we’ll discuss why you might want to do that.
  • Run multiple, individual desktops on a single, shared server operating system, using Microsoft Remote Desktop Services (with or without added functionality from products such as Citrix XenApp). This “remote session host,” to use the Microsoft term, can be a virtual server or a physical server. Once again, the desktop can be made to look like a Windows 7 or Windows 8 desktop even though it’s really a server OS.
  • Use a brokering service such as XenDesktop to allow remote users to connect to blade PCs in a data center, or even to connect to their own desktop PCs when they’re out of the office.
  • Use client-side virtualization to deliver a company-managed desktop OS instance that will run inside a virtualized “sandbox” on a client PC, such as is the case with Citrix XenClient, or the Citrix Desktop Player for Macintosh. In this case, the virtual desktop can be cached on the local device’s hard disk so it can continue to be accessed after the client device is disconnected from the network.

Although any of the above approaches could lumped into the “VDI” category, the common usage that seems to be emerging is to use the term “VDI” to refer specifically to approaches that deliver an individual operating system instance (desktop or server) to each user. From a service provider perspective, we would characterize that as cloud-based VDI. So, to answer the question we posed in the title of this post, cloud-based VDI is one variant of DaaS, but not all DaaS is delivered using cloud-based VDI – and for a good reason.

Microsoft has chosen not to put its desktop operating systems on the Service Provider License Agreement (“SPLA”). That means there is no legal way for a service provider such as VirtualQube to provide a customer with a true Windows 7 or Windows 8 desktop and charge by the month for it. The only way that can be done is for the customer to purchase all the licenses that would be required for their own on-site VDI deployment (and we’ve written extensively about what licenses those are), and provide those licenses to the service provider, which must then provision dedicated hardware for that customer. That hardware cannot be used to provide any services to any other customer. (Anyone who tells you that there’s any other way to do this is either not telling you the truth, or is violating the Microsoft SPLA!)

Unfortunately, the requirement for dedicated hardware will, in many cases, make the solution unaffordable. Citrix recently published the results of a survey of Citrix Service Providers. They received responses from 718 service providers in 25 countries. 70% of them said that their average customer had fewer than 100 employees. 40% said their average customer had fewer than 50 employees. It is simply not cost-effective for a service provider to dedicate hardware to a customer of that size, and unlikely that it could be done at a price the customer would be willing to pay.

On the other hand, both Microsoft and Citrix have clean, easy-to-understand license models for Remote Desktop Services and XenApp, which is the primary reason why nearly all service providers, including VirtualQube, use server-hosted desktops as their primary DaaS delivery method. We all leverage the policy packs that can make a Server 2008 R2 desktop look like a Windows 7 desktop, and a 2012 R2 desktop look like a Windows 8 desktop, but you’re really not getting Windows 7 or Windows 8, and Microsoft is starting to crack down on service providers who fail to make that clear.

Unfortunately, there are still some applications out there that will not run well – or will not run at all – in a remote session hosted environment. There are a number of reasons for this:

  • Some applications check for the OS version as part of their installation routines, and simply abort the installation if you’re trying to install them on a server OS.
  • Some applications will not run on a 64-bit platform – and Server 2008 R2 and 2012 R2 are both exclusively 64-bit platforms.
  • Some applications do not follow proper programming conventions, and insist on doing things like writing temp files to a hard-coded path like C:\temp. If you have multiple users running that application on the same server via Remote Desktop Services, and each instance of the application is trying to write to the same temp file, serious issues will result. Sometimes we can use application isolation techniques to redirect the writes to a user-specific path, but sometimes we can’t.
  • Some applications are so demanding in terms of processor and RAM requirements that anyone else trying to run applications on the same server will experience degraded performance.

There’s not much that a service provider can do to address the first two of these issues, short of going the dedicated-hardware route (for those customers who are large enough to afford it) and provisioning true Windows 7 or Windows 8 desktops. But there is a creative solution for the third and fourth issues, and that’s to use VDI technology to provision individual instances of Server 2008 R2 or Server 2012 R2 per user. From the licensing perspective, it’s no different than supporting multiple users on a remote session host. Once the service provider has licensed a virtualization host for Windows Datacenter edition, there is no limit to the number of Windows Server instances that can be run on that host – you can keep spinning them up until you don’t like the performance anymore. And the Citrix and Microsoft user licensing is the same whether the user has his/her own private server instance, or is sharing the server OS instance with several other users via Remote Desktop Services.

On the positive side, this allows an individual user to be guaranteed a specified amount of CPU and RAM to handle those resource-intensive applications, avoids “noisy neighbor” issues where a single user impacts the performance of other users who happen to be sharing the same Remote Desktop Server, and allows support of applications that just don’t want to run in a multi-user environment. It’s even possible to give the user the ability to install his/her own applications – this may be risky in that the user could break his/her own virtual server instance, but at least the user can’t affect anyone else.

On the negative side, this is a more expensive alternative simply because it is a less efficient way to use the underlying virtualization host. Our tests indicate that we can probably support an average of 75 individual virtual instances of Server 2008 or Server 2012 for VDI on a dual-processor virtualization host with, say, 320 Gb or so of RAM. We can support 200 – 300 concurrent users on the same hardware by running multiple XenApp server instances on it rather than an OS instance per user.

That said, we believe there are times when the positives of cloud-based VDI is worth the extra money, which is why we offer both cloud-based VDI and remote session hosted DaaS powered by Remote Desktop Services and XenApp.

The Elusive Windows “Companion Subscription License” - a Solution In Search of a Problem

In our post entitled “What Licenses Do I Need,” we discussed the licensing required, from both Citrix and Microsoft, for a XenApp or XenDesktop deployment. But there was still an unknown factor: When that post was published, Microsoft had recently announced something that, at the time, was being referred to as a “Companion Device License” – but no information was available yet on what it would cost or how it would be licensed.

The fog has finally cleared, and, unfortunately, it’s not particularly good news if you are a Small or Medium Enterprise.

The question at hand is what Microsoft licenses are required to legally operate a Virtual Desktop Infrastructure that serves up virtual instances of Windows 7 or Windows 8.x to your users. And the answer is that it depends on what the client device is that will be used to access the virtual desktop. If the client device is a Windows PC covered by Software Assurance, no problem – the right to access a virtual desktop instance is one of the benefits of Software Assurance. But if the client device is a Windows PC that is not covered by Software Assurance, or if it is not a Windows PC at all (e.g., Mac, Linux, thin client, etc.) then you must purchase a Virtual Desktop Access (“VDA”) license for that client device. That VDA license is available through Open Value Subscription licensing for roughly $100/year each.

So far, so good. But things start to get more complicated if you want to access that virtual desktop from a personally-owned client device.

According to the Microsoft Product Use Rights document (on pages 74 & 75 of the April, 2014, edition, in case you want to read along), the primary user of a Windows PC covered by Software Assurance, or of another client device to which a VDA license has been assigned, has “roaming use rights” that allow a virtual desktop to be accessed from a “Qualifying Third Party Device” such as a personal PC, MacBook, iPad, etc…”from anywhere off your or your affiliates’ premises.” And therein lies the problem: The user is not entitled to bring a personal device into the office and use it there to access a virtual desktop.

So, if your objective is to enable BYOD and let your people bring in whatever kind of device they want to use, and then use that device to access your virtual desktop infrastructure, what do you have to do? This question is what Microsoft attempted to address with what is now called a “Windows Companion Subscription License.” But it doesn’t address it very well. First of all, the Companion SL must be associated with another client device that is…yep, either a Windows PC with Software Assurance or some other client device that you’ve assigned a VDA license to. For every one of those you have, you can purchase a Companion SL, which will entitle the primary user of that device to access a virtual desktop from up to four Companion Devices in any given 90 day period. Therefore, the Companion SL doesn’t truly enable BYOD in the sense of eliminating the need to purchase company-owned client devices that are covered by either Software Assurance or a VDA license – because you have to have one of those before you can even purchase a Companion SL.

To make matters worse, unless your organization is large enough to have a Microsoft Enterprise, Select, or Select Plus agreement, you’re out of luck, because the Companion SL is not available through any Open License program. So, if you’re an SMB, your only option for legally licensing employee-owned devices for use on your premises to access your virtual desktop infrastructure is to purchase VDA licenses for those employee-owned devices.

If you do have an Enterprise or Select agreement, you can expect to pay an estimated $48 - $84 per year for a Companion SL, depending on your agreement, the size of your organization, and the concessions you’ve been able to wrangle out of your Microsoft account rep. So that may offer some cost savings for large enterprises that want to institute a BYOD policy – although it’s not clear to me how great the savings would be considering that you have to have a client device with either Software Assurance or a VDA license before you can even purchase the Companion SL.

For most organizations, in our opinion, the Companion SL is a solution in search of a problem.

Some Straight Talk about VDI-in-a-Box

Update: The advent of solid-state drives allows you to eliminate IOPS as a potential bottleneck. The calculations below are based on 15K SAS drives that support roughly 175 IOPS each. A typical 200 Gb SSD will support tens of thousands of IOPS. On the other hand, although SSD prices are coming down, they’re still rather pricey. Replacing the eight 146 Gb, 15K SAS drives in the example below with eight 200 Gb SSDs, and loading it up with RAM so you can support more virtual desktops, will push the price of the server to nearly $20,000. So the primary point of this post still stands: While VDI-in-a-Box is a great product, and can be competitive with physical PCs when the entire lifecycle cost is compared, you’re just not going to see significant savings in the capital expense of ViaB vs. physical PCs. That doesn’t mean it isn’t a great product, and it doesn’t mean you shouldn’t consider it. It just means that you need to validate what it’s really going to cost in your environment.

Original Post (April, 2012):
There is a lot of buzz about Citrix VDI-in-a-Box (“ViaB”), and rightly so: it’s a great product, and much simpler to install and easier to scale than a full-blown XenDesktop deployment. You don’t need a SAN, you don’t need special broker servers, you don’t need a separate license server or a SQL Server to hold configuration data. Unfortunately, some of the buzz - particularly some of the cost comparisons you see that show a $3,000 - $4,000 server for 30 or more virtual desktops, is misleading. So let’s talk seriously about the right way to deploy ViaB. For this exercise, I’m going to assume we need 50 virtual desktops. Once we’ve worked through this, you should be able to duplicate the exercise for any number you want.

First of all, I’m going to assume that we are building a system that will support Windows 7 virtual desktops - because I can’t see any valid reason why someone would invest in a virtual desktop infrastructure that couldn’t support Windows 7. There are two important data points that follow from this: (1) We should allow at least 1.5 Gb per virtual PC, and preferably 2 Gb per virtual PC. (2) We should design for an average of about 15 IOPS per Windows 7 virtual PC, because, depending on the user, a Windows 7 desktop will generate 10 - 20 IOPS. Let’s tackle the IOPS issue first.

Thanks to Dan Feller of Citrix, we know how to calculate the “functional IOPS” of a given disk subsystem. Here are the significant factors that go into that formula:

  • A desktop Operating System - unlike a server Operating System - has a read/write ratio of roughly 80% writes and 20% reads.
  • A 15K SAS drive will support approximately 175 IOPS. The total “raw IOPS” of a disk array built from 15K SAS drives is simply 175 x the number of drives in the array.
  • A RAID 10 array, which probably offers the best balance of performance and reliability, has a “write penalty” of 2.

With that in mind, the formula is:

Functional IOPS=((Total Raw IOPS x Write %)/(RAID Penalty)) + (Total Raw IOPS x Read %)

If we put eight 15K SAS drives into a RAID 10 array, the formula becomes:

Raw IOPS = 175 x 8 = 1,400

Functional IOPS = ((1,400x.8)/2)+(1,400x.2) = 560 + 280 = 840

If we are assuming an average of 15 IOPS per Win7 virtual PC, this suggests that the array in question will support roughly 56 virtual PCs. So this array should be able to comfortably support our 50 Win7 virtual PCs, unless all 50 are assigned to power users.

That’s all well and good, but we haven’t talked yet about how much actual storage space this array needs. That depends on the size of our Win7 master image, how many different Win7 master images we’re going to be using, and whether we can use “linked clones” for VDI provisioning, in which case each virtual PC will consume an average of 15% of the size of the master, or whether we’re permanently assigning desktops to users, in which case each virtual PC will consume 100% of the size of the master. For the sake of this exercise, let’s assume we’re using linked clones, and that we have three different master images, each of which is 20 Gb in size. According to the Citrix best practice, we need to reserve 120 Gb for our master images (2 x master image size x number of master images). We then need to reserve 3 Gb per virtual PC (15% of 20 Gb), which totals another 150 Gb. The ViaB virtual appliance will require 70 Gb. We also need room for the hypervisor itself (unless we’re provisioning another set of disks just for that) and for swap file, transient activity, etc., so let’s throw in another 150 Gb. That’s 490 Gb minimum. So we need to use, at a minimum, 146 Gb drives in our array, which would give us 584 Gb in our RAID 10 array.

How about RAM? If we allow 1.5 Gb per Win7 desktop, then 50 virtual desktops will consume 75 Gb. We need at least 1 Gb for the ViaB appliance, at least 1 Gb for the hypervisor, plus some overhead for server operations, so let’s just call it 96 Gb.

We can handle 6 to 10 virtual desktops per CPU core - more if the cores are hyper-threaded - so we’re probably OK with a dual-proc, quad-core server.

Now, I don’t know about you, but if I’m going to put 50 users onto a single server, I’m going to want some redundancy. I will at least want hot-plug redundant power supplies, and hot-plug disk drives. Ideally, I would provision “N+1″ redundancy, i.e., I would have one more server in my ViaB array than I need to support my users. I’m also going to want a remote access card, and probably an uplift on the manufacturer’s Warranty so if it breaks, the manufacturer will come on site and fix it.

By now, you’ve probably figured out that we are not talking about a $4,000 server here. I priced out a Dell R710 - using their public-facing configuration and quoting tool - with the following configuration, and it came out to roughly $11,000:

  • Two Intel E5640 quad-core, hyper-threaded processors, 2.66 GHz
  • 96 Gb RAM
  • Eight 146 Gb, 15K SAS drives
  • PERC H700 controller with 512 Mb cache
  • Redundant hot-plug power supplies
  • iDRAC Enterprise remote access card
  • Warranty uplift to 3-year, 24×7, 4-hour response, on-site Warranty

(NOTE: This is a point-in-time price, and hardware prices are subject to change at any time.)

The ViaB licenses themselves will cost you $195 each. Be careful of the comparisons that show the price as $160 each. ViaB is unique among Citrix products in that the base cost of the license does not include the first year of Subscription Advantage - yet the purchase of that first year is required (although you don’t necessarily have to renew it in future years). That adds $35 each to the cost of the licenses.

Finally, If you don’t have Microsoft Software Assurance on your PC desktops - and my experience is that most SMBs do not - you need to factor in the Microsoft Virtual Desktop Access (VDA) license for every user. This license is only available as an annual subscription, and will cost you approximately $100/year.

So, your up-front acquisition cost for the system we’ve been discussing looks like this:

  • Dell R710 server - $11,000
  • 50 ViaB licenses @ $195 - $9,750
  • 50 Microsoft VDA licenses @ $100 - $5,000

Total aquisition cost: $25,750, or $515/user. Not bad.

But wait - if we’re going to compare this to the cost of buying new PC, shouldn’t we look at the cost of ViaB over the same period of time that we would expect that new PC to last? If we assume, like many companies do, that a PC has a useful life of about 3 years, then we should actually factor in another two years of VDA licenses, and two years of Subscription Advantage renewal for the ViaB licenses. That pushes the 3-year cost of the ViaB licenses to $13,250, and the cost of the VDA licenses to $15,000. So the total 3-year cost of our solution is $39,250, or $785/user.

If you want N+1 redundancy, you’re going to need to buy a second server. That would push the cost to $50,250, or $1,005/user.

What conclusions can we draw from all this? Well, first, that VDI-in-a-Box is not going to be significantly less expensive than buying new PCs, if you actually do it right. However, it is competitive with the price of new PCs, which is worth noting. As long as the price is comparable, which it is, we can then start talking about the business advantages of VDI, such as being able to remotely access your virtual desktop from anywhere, with just about any device, including iPad and Android tablets, and about the ongoing management advantages of having a single point of control over multiple desktops.

Also, as you scale up the environment, the incremental cost of that extra server that’s required for N+1 redundancy gets spread over more and more users, and becomes less significant. For example, if we’re building an infrastructure that will support 150 virtual desktops, we would need four servers. Total 3-year cost: $128,750, or $858.33/user for a robust, highly redundant virtual desktop infrastructure. In my opinion, that’s a pretty compelling price point, and you won’t be able to hit that price point with a 150-user XenDesktop deployment, because of the other server and storage infrastructure components that you need to build a complete solution. On the other hand, XenDesktop does include more functionality, like the rights to use XenApp for virtual application delivery, ability to stream a desktop OS to a blade PC or a desktop PC, rights to use XenClient for client-side virtualization, etc.

But if all you want is a VDI solution, ViaB is, in my opinion, the obvious choice. It’s clear that Citrix wants to position VDI-in-a-Box as the preferred VDI solution for SMBs, meaning anyone with 250 or fewer users…and there’s no reason why ViaB can’t scale much larger than that.

For more information on ViaB, check out this video from Citrix TV, then head on over to the Citrix TV site to view the entire ViaB series

**** EDIT April 12, 2012 ****
You may already be aware of this, but Dell has announced a ViaB appliance that comes pre-configured, with both XenServer and the ViaB virtual appliance already installed. Oddly enough, even though Moose Logic is a Dell partner, I couldn’t get Dell to tell me what one would cost. Their answer was that I should call back when I had a specific customer need, and they would work up a specific configuration and quote it. I considered calling back with a fictitious customer requirement, but decided that I didn’t want to know badly enough to play that game.

They did, however, tell me what the basic server configuration was - and it was very close to the configuration I’ve outlined above: two X5675 processors, 96 Gb of RAM, eight 146 Gb drives in a RAID 10 array, Perc H700 array controller (don’t know how much cache, though), and iDRAC Enterprise remote access card. I do not know whether it has redundant power supplies (although I would certainly hope so), nor exactly what Warranty is included…perhaps that option is left up to the customer.

That gave me at least enough information to run a sanity check on the configuration. The array would provide 960 functional IOPS, which should be adequate for an 80 user system - which is how the appliance is advertised - depending, of course, on the percentage of power users. Also, the array should provide enough storage to handle the needs of most SMBs, unless they have an unusually large number of images to maintain.

One of my Citrix contacts recently told me that the Dell appliance was priced at $440/desktop for an 80 concurrent user configuration, which is very much in line with the cost per user in the post above, considering that $100 of my $515/user number was for the first year of Microsoft VDA licenses, which, to my knowledge, are not included with the Dell appliance.

Why Desktop as a Service?

This morning, I ran across an interesting article over on techtarget.com talking about the advantages of the cloud-hosted desktop model. Among other things, it listed some of the reasons why businesses are deploying DaaS, which align quite well with what we’ve experienced:

  • IaaS - Businesses are finding that as they move their data and server applications into the cloud, the user experience can degrade, because they’re moving farther and farther away from the clients and users who access them. That’s reminiscent of our post a few months ago about the concept of “Data Gravity.” In that post, we made reference to the research by Jim Gray of Microsoft, who concluded that, compared to the cost of moving bytes around, everything else is essentially free. Our contention is that your application execution platform should be wherever your data is. If your data is in the cloud, it just makes sense to have a cloud-hosted desktop to run the applications that access that data.
  • Seasonality - Businesses whose employee count varies significantly over the course of the year may find that the pay-as-you-go model of DaaS makes more sense than building an on-site infrastructure that will handle the seasonal peak.
  • DR/BC - This can be addressed two ways: First, simply having your data and applications in a state-of-the-art data center gives you protection against localized disasters at your office location. If your cloud hosting provider offers data replication to geo-redundant data centers, that’s even better, because you’re also protected against a catastrophic failure of the data center as well. Second, you can replicate the data (and, optionally, even replicate server images) from your on-site infrastructure to a cloud storage repository, and have your hosting provider provision servers and desktops on demand in the event of a disaster - or, although this would cost a bit more, have them already provisioned so they could simply be turned on.
  • Cost - techtarget.com points out that DaaS allows businesses to gain the benefits of virtual desktops without having to acquire the in-house knowledge and skills necessary to deploy VDI themselves. While this is a true statement, it may be difficult to build a reliable ROI justification around it. We’ve found that it often is possible to see a positive ROI if you compare the cost of doing a “forklift upgrade” of servers and server software to the cost of simply moving everything to the cloud and never buying servers or server software again.

It’s worth taking a few minutes to read the entire article on techtarget.com (note - registration may be required to access some content). And, of course, it’s always nice to know we’re not the only ones who think there are some compelling advantages to cloud-hosted desktops!

So You Want to Be a Hosting Provider? (Part 2)

In Part 1 of this series, we talked about the options available to prospective hosting providers, and specifically about the costs of purchasing your own equipment. In this post we’re going to drill down into the costs of building a Citrix Service Provider hosting infrastructure on Amazon.

Amazon has some great offerings, and Citrix has spent a lot of time lately talking about using the EC2 infrastructure as a platform for Citrix Service Providers. There was an entire breakout session devoted to this subject at the 2014 Citrix Summit conference in Orlando. Anyone who signs up as a Citrix Service Provider can get access to a spreadsheet that allows you to input various assumptions about your infrastructure (e.g., number of users to support, assumed number of users per XenApp server, number of tenants in your multi-tenant environment, etc.) and calculates how many of what kind of compute instances you will need as well as the projected costs (annualized over three years). At first glance, these costs may look fairly attractive. But there are a number of assumptions built into the cost model that should make any aspiring service provider think twice:

  • It assumes that you’ve got enough users lined up that you can get the economies of scale from building an infrastructure for several hundred, if not thousands, of users.
  • It assumes that you’ve got enough free cash to pay up front for 3-year reserved instances of all the servers you’ll be provisioning.
  • It assumes that, on average, your servers will need to run only 14 hours per day. If your customers expect to be able to work when they want to work, day or night, this will be a problem.
  • It assumes that you will be able to support an average of 150 concurrent users on a XenApp server that’s running on a “Cluster Compute Eight Extra Large” instance. Anyone who has worked with XenApp knows that these assumptions must be taken with a very large grain of salt, as the number of concurrent users you can support on a XenApp server is highly dependent on the application set, and doesn’t necessarily scale linearly as you throw more processors at it.

If all of these assumptions are correct, the Citrix-provided spreadsheet says that you can build an EC2 infrastructure that will support 1,000 concurrent users (assuming 10 customers with 100 users each for the multi-tenancy calculation) for an average cost/user/month of $45.94 over a three year period. But that number is misleading, because you have to come up with $377,730 up front to reserve your EC2 instances for three years. So your first-year cost is not $551,270, but $803,081 – that’s actually $66.92/user/month for the first year, and then it drops to $35.45/user/month in years two and three, then back to $66.92/user/month in the fourth year, because you’ll have to come up with the reservation fees again at the beginning of year four.

There are a couple of other things about this model that are troublesome:

  1. By default, it assumes only a single file server for 1,000 users, meaning that you would administer security strictly via AD permissions. It also means that if anything happens to that file server, all of your tenants are impacted. If we instead provision ten file servers, so that each of the ten tenants has a dedicated file server, it bumps the average cost by roughly $5/user/month.
  2. If your user count is 100 users per tenant, but you’re expecting to support 150 users per XenApp server, you’ll obviously have users from multiple tenant organizations running concurrently on the same XenApp server. This, in turn, means that if a user from one tenant organization does something that impacts XenApp performance – e.g., launches the Production Planning Spreadsheet from Hell that pegs the processor for five minutes recalculating the entire spreadsheet whenever a single cell is changed – it will affect more than just that tenant organization. (And, yes, I know that there are ways to protect against runaway processor utilization - but that’s still something else you have to set up and manage, and, depending on how you approach the problem, potentially another licensing component you have to pay for.) If we assume only 100 users per XenApp server, so that we can dedicate one XenApp server to each tenant organization, it bumps the average cost by roughly another $1.50/user/month.

“But wait,” you might say, “not many VARs/MSPs will want to – or be able to – build an infrastructure for 1,000 users right off the bat.” And you would be correct. So let’s scale it back a bit. Let’s look at an infrastructure that’s built for 250 users, and let’s assume that breaks down into five tenants, with 50 users each. Let’s further assume, for reasons touched on above, that each customer will get a dedicated file server, and one dedicated XenApp server. We’ll dial those XenApp servers back to “High CPU Extra Large” instances, which have 4 vCPUs and 7.5 Gb of vRAM each. Your average cost over three years, still assuming 3-year reserved instances, jumps to $168.28/user/month, and you must still be prepared to write a check for just over $350,000 for the 3-year reservation fees. Why the big jump? Primarily because there is a minimum amount of “overhead” in the server resources required simply to manage the Citrix infrastructure, the multi-tenant Active Directory and Exchange infrastructure, etc., and that overhead is now spread across fewer users.

Now consider that all of the prices we’ve been looking at so far cover only the compute and storage resources. We haven’t begun to factor in the monthly cost of Citrix or Microsoft Service Provider licensing. In round numbers, that will add another $25/user/month or so to your cost, including MS Office. Nor have we accounted for the possibility that some of your users may need additional SPLA applications, such as Visio or Project, or that some tenants may require a SQL server or some other additional application server. Nor have we accounted for the possibility that some of your tenants may require access to the infrastructure on a 24×7 basis, meaning that their servers have to run 24 hours per day, not just 14.

This is why, at the aforementioned session at the 2014 Citrix Summit conference in Orlando, the numbers presented in the session were challenged by several people during the ensuing Q&A, the general feedback being that they simply didn’t work in the real world.

So let’s quickly review where we are: As stated in Part 1 of this series, an aspiring hosting provider has four basic choices:

  1. Buy hardware and build it yourself. This was discussed in Part 1.
  2. Rent hardware (e.g., Rackspace) and build it yourself. This was not covered in detail, but once you’ve developed the list of equipment for option #1, it’s easy enough to get quotes for option #2.
  3. Rent VMs, as we have discussed above, and build it yourself.
  4. Partner with someone that has already built the required infrastructure.

We would respectfully submit that, for most VARs/MSPs, option #4 makes the most sense. But we’re biased, because (full disclosure again) VirtualQube has already built the infrastructure, and we know that our costs are significantly less than it would take to replicate our infrastructure on EC2. And we’re looking for some good partners.

In Part 3, we’ll go into what we believe an infrastructure needs to look like for a DaaS hosting provider that’s targeting the SMB market, so stay tuned.