To Silo or not to Silo: What application installation strategy is best for you?

One of the most important steps in a MetaFrame Presentation Server farm design is to decide what applications you’re going to install on which servers. As many of you know, I’ve spent the past three months traveling and talking about Citrix throughout the world.

One of the most important steps in a MetaFrame Presentation Server farm design is to decide what applications you’re going to install on which servers. As many of you know, I’ve spent the past three months traveling and talking about Citrix throughout the world. From a design standpoint, this application issue is huge.

Fundamentally, you have two basic options:

  • Install all your applications on all MetaFrame servers and then publish the desktop.
  • Install a few related applications on each MetaFrame server, creating several different server configurations. Then, publish individual applications.

Option 1. Install All Applications on All Servers

If your environment is not to large and if you want all of your MetaFrame servers to be 100% identical, you could choose to install all of your applications onto all of your servers. If there are a total of five applications in a server farm, then every server in the farm would run all five applications.

There are several benefits to doing this. Users who access multiple applications only need to connect to one server. Greater economies of scale can be realized since every user can be crammed onto a few servers. Certain aspects of this environment could also make it easier to manage since all the servers would be configured the same.

Unfortunately, deploying each application to every server also has some downsides. The biggest issues are around application compatibility. The more applications you install on a single server, the greater the chance that you’ll have two applications that conflict with each other. This will also increase the amount of testing you have to do whenever there is an application update since you’ll have an increased chance of an incompatibility.

Speaking of incompatibilities, the more applications you install onto a single server, the more often you’ll have to update that server. For example, an average application is patched how often—twice a year maybe? If that application is the only application installed on a server, then you’ll only need to update that server twice a year (as far as the application is concerned, anyway). However, if you have ten applications installed on a single server that each get two updates per year, then you’ll have to deal with 20 updates to your server per year, which is roughly one update every 2.5 weeks!

Advantages of Putting All Applications on All Servers

  • Better economies of scale
  • All servers can be 100% identical
  • Applications can interact with each other

Disadvantages of Putting All Applications on All Servers

  • Complex application upgrades (more applications per server means more testing)
  • Frequent server servicing / constantly changing server environment
  • You need to install one application many times
  • Not realistic in large environments
  • All individual application owners will have to “touch” all of your MetaFrame servers

Option 2. Install a Few Related Applications on Each Server

The alternative to installing all of your applications on all of your servers is to instead install only a few related applications on each server (even if all the servers are members of the same farm). This will essentially create a server farm made up of multiple groups of load-balanced servers, each group containing a subset of the entire farm’s applications. These small groups of servers are called “silos.” (I personally used to call these things “farmlets,” but that term didn’t catch on. The de facto industry term is “silo.”)

If you decide to create multiple silos, the first thing you need to do is to take a look at your application list and figure out which applications make sense to group together into each silo. (I think it’s unrealistic for every single application to have its own silo, so instead I create silos for groups of applications.)

It’s usually easiest to make a list of your applications along with the number and types of users who use them. For example:

Application Users
Microsoft Office 1200
Microsoft Visio 600
Adobe Acrobat Reader 1200
Internet Explorer 500
SAP 200
Crystal Reports 200
Data warehouse 60
Production Line Manager 60
Research Application 120
HR Application 15
Payroll 20
Time Tracker 1000

One other thing to remember is that with Citrix’s published application architecture, a single user can simultaneously access published applications from multiple servers, so it’s no problem whatsoever to split applications that will need to be used by the same people.

Looking back at our example, I would probably group Microsoft Office, Visio, Acrobat, and possibly IE into one silo. I would then put SAP and Crystal Reports into a second silo and the data warehouse and production applications into a third silo. I can probably group the HR and payroll applications together and put them in their own silo, and then I might make a fifth silo for Time Tracker.

Taking a step back from this, I now see that I have five silos. The problem here is that for redundancy purposes, the N+1 redundancy now has to be done at the individual silo level. This means that because I have five silos, I have five redundant servers. Looking at my silo choices, I see that the decision to put the HR application (used by only 15 people) and the payroll application (used by 20 people) in their own silo was a bit extreme. There’s no way I need to full servers for these 35 people. Instead, I’ll probably throw these two applications into one of the other silos.

Silo Advantages

  • Fewer conflicts between applications
  • Simpler application upgrades. Application version compatibility tests are easier when there are fewer applications that could potentially interfere
  • Servers do not change too often

Silo Disadvantages

  • Higher cost since more servers are needed.
  • Potentially under-utilized servers.
  • Application issues. What if one application requires the use of another? In this case, you’ll have to install both on the same server.

Published Desktop versus Published Applications?

As I mentioned briefly, this application architecture question very closely tracks another key architectural question, namely, should you publish full desktops or individual applications?

Historically, installing all applications on all servers meant that you would publish the desktop, and breaking your environment into silos meant that you would publish individual applications.

However, it’s possible to get the advantages of silos while still offering published desktops to those users who need them. You can do this with a three-tier application architecture.

In creating a three-tier architecture, you’ll create a dedicated silo for your users who require published desktop access. Users will connect to a published desktop within that silo. Then, using ICA client software installed on the MetaFrame servers in the desktop silo, users will launch additional ICA sessions to published applications on the back-end application silos. This “double-hop” ICA architecture is what’s known as “ICA passthrough” (not to be confused with “passthrough authentication,” which is something completely different). ICA passthrough works great, and your users won’t even know that they’re using it. Most people will build this architecture by installing the Program Neighborhood Agent client on the MetaFrame servers in the desktop silo. Therefore, when users launch their remote desktop session there, shortcuts for published applications on the backend silo servers automatically appear based on their permissions.

So why create this additional published desktop tier? The biggest reason is for simplicity of application access. The beauty of this is that the individual application owners (the people who own Silos 1, 2, and 3) only have to make their applications available in one way—as published applications. Then, users who have fat clients that connect directly to the published applications can connect directly to their servers, and users who have thin clients and connect to those published applications via the desktop tier. This is much simpler than trying to deal with people coming into the same application in different ways.

A lot of people ask whether it’s okay to install any applications on the desktop silo, or whether you should put all your applications on backend servers. My view on this is that you can put applications on your desktop servers of those applications are only going to be used by people running remote desktop sessions on those servers. If you’d like those applications to be accessed as direct published applications, then they should be in one of the backend silos. In reality, the desktop tier ends up with applications like Acrobat, WinZip, and possibly Internet Explorer or Office.

How to Decide what to do in your Environment

Now that you’ve seen the various architectural options, you’ll need to decide which approach is best for you. As I mentioned previously, I personally like to make a list of applications and consider them one-by-one. I do this by asking the following questions about each application:

  • Who owns and maintains the application?
  • How often is the application updated (including new versions, service packs, and hotfixes)? How long does this take?
  • Can this application be grouped with others into a logical family (such as Microsoft Word and Excel)?
  • How much server power does the application require?
  • What is the total number of applications that you have?
  • What type of server hardware do you have?
  • What type of client devices do you have?

Application Ownership
If certain groups of applications are owned or maintained by the same groups of administrators, then it makes sense to keep all of their applications together on the same servers. That way, each department only has to deal with their own applications. However, if all of the applications are supported by one large group of administrators (i.e. you), then this is not a factor.

Application Complexity
Applications that are updated frequently should be kept away from applications that are almost never updated. For example, imagine that you have two applications each hosted by two servers. Application A is updated every other week, and Application B is updated quarterly. If you publish both applications to all four servers then you will need to touch and update all four servers every other week. However, if you limit each application to two servers then you will only need to update the two servers for Application A every other week.

Application Groups
If you have certain groups of applications that are used by the same groups of users, it might make sense to confine them to selected servers. Many companies keep all applications specific to a department on MetaFrame servers separate from those that host company-wide applications.

Server Resources Needed
If you have many applications that require significant server power, it may not be possible (or economical) to put them on the same server as other applications that also have high resource requirements.

Number of Applications
The more applications you have, the more likely it is that you will need to put specific applications on specific servers. If you only have three applications you can afford to put them all on each server. However, if you have one hundred applications there is no way that you would put them all on every MetaFrame server.

Server Hardware
The type of server hardware you have (or plan to have) will also help you decide whether you should put all applications on all servers or whether you should divide your farm in silos. Obviously if you have six quad-processor servers then your application installation options would be a bit different than if you had twenty single-processor servers.

Client Devices
Do your clients have the capability to run published applications, or will you also have to publish the desktop? This will determine whether you even need to make a desktop tier


As I mentioned previously, this issue is one of the bigger decisions that you’ll need to make when designing your server farm. I’ve tried to accurately capture all of the data you’ll need to make this decision, but please feel free to share your comments and opinions about what you like to do in your own environments.

Dig Deeper on Web browsers and applications