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

Summary

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.

Join the conversation

25 comments

Send me notifications when other members comment.

Please create a username to comment.

This message was originally posted by Ron Oglesby on November 23, 2004
Just fine if you use Citrix. The passthrough client on the server handles this. I have a number of clients that do this. There is a slight increase in load on the desktop server but its small and can be handled.
Cancel
This message was originally posted by Tim on November 23, 2004
We are currently evaluating SoftGrid to solve the silo problem. Today we have basically 1 app per server. I would like to hear more thoughts on Softgrid. Everything I have heard so far is positive.
Cancel
This message was originally posted by Pierre on November 23, 2004
I am waiting impatiently to read your article about SoftGrid. I have been working with SoftGrid for about a year now and I am really happy with the product. It would be nice if you not only wrote about how to deploy SoftGrid in a terminal server environment and your thoughts about it but also how to serve and manage application that is executed on the users local PC:s within SoftGrid.
Maybe write something about how to publish the .OSD xml files on your Nfuse portal to enable the users to stream and execute the application to the local workstation and at the same time start a published application that executes on the Citrix server but within SoftGrid.


Best Regards

Pierre
Cancel
This message was originally posted by Antherus on November 22, 2004
What about the Softgrid approach? Or the promise of Application Isolation Environments...

Siloing=Bad.
Cancel
This message was originally posted by Brian Madden on November 22, 2004
Good point about these options. I'm still working on my AIE / Softgrid article, and I'll have more soon. However, with this article I wanted to focus on what was available today that didn't cost extra.
Cancel
This message was originally posted by Mike Burke on November 22, 2004
How you integrate Group Policies will also effect these decisions. A GPO in place for a specific application might conflict with what is required for another application. For example, we control our environment very carefully through GPO, to the point that we need to move Citrix servers to a specific OU just to install applications or updates. However, once we move that server into that OU, it loses it's affinity with the policies that make the environment work as advertised, such as running scripts, environment settings, etc.
Cancel
This message was originally posted by SJ on November 23, 2004
In the 3 tier scenario you describe, how is client drive mapping and client printer mapping affected? Wouldn't your session from the desktop silo to the backend silo, map the drives and printers from the desktop silo session? If that's not the case how does it work?
Cancel
This message was originally posted by an anonymous visitor on November 23, 2004
The problem with siloing is that medium to large businesses do not tend to have applications that can exist in isolation, e.g. many applications integrate with Office, IE, Acrobat, Oracle, SQL Client etc. So on paper siloing looks great but in practice it is unrealistic for all but the smallest/simplest of organisations. They also often have multiple versions of applications that cannot co-exist with one another, and rationalising these is often not an option in the short term. The only people I know of who address the coexistance issue are Propero, whose technology allows you to run multiple versions of the same application, and to co-exist conflicting apps. They do all this on Terminal Servers and Citrix farms.
Cancel
This message was originally posted by Benjamin on November 23, 2004
you have an application that doesn´t need to interact with others and/or is a resource-hog. (and therefore needs to be seperated from the other applications)
Cancel
This message was originally posted by Sergei on November 24, 2004
I do agree with Ron that siloing is an realistic fact in enterprise Citrix environments. The virtualization of Apps with softricity or AIE (if it really works fine) is a way to install some apps that do not run in coexistance. A farm design with app silos is in fact nessesary when you publish many applications (e.g. 80 or more) that require many updates (SAP, Office,...) together with some Java Apps and somehow instable software (internal developments, Banking or 16 Bit Apps). From my point the management is dramatically reduced in comparison to virtualization in that case.
Cancel
This message was originally posted by Ron Oglesby on November 23, 2004
This souds like someone selling a product. I have worked on a ton of enterprise environments (enterprise as in 200+ Citrix servers with hundreds of apps) and this sentence "So on paper siloing looks great but in practice it is unrealistic for all but the smallest/simplest of organisations.: is not true. Its realistic. Is it perfect? no. Do hundreds and hundreds of clients do it? yes. Is a solution like application virtualization with softgrid (or possibly another product) better? Possibly, depending on your apps and needs. Silos are not the end of the world and in almost every large Citrix environment a reality. I love salesy types always saying you cant do this or its unrealistic without X, Y or Z product
Cancel
This message was originally posted by James Cabe on November 30, 2004
Silos are great for provisioning and identifying needs for a business group within a large corporation. But subdividing the whole into stacks is the best way to go. Softricity is unproven and more than a few platinums say to buy it .. but hold off on large rollouts. So I use Silos for budgeting and buying for business groups and "stacks" and VMware for all else.
Cancel
This message was originally posted by eurodude on November 30, 2004
I disagree that siloing is necessary in a Citrixfarm. I’ve been working with Softgrid in a Citrix environment(40 servers,50+ apps) for about a year now and have managed to reduce the number of server silos to 0.More or less all our applications is virtualized with softgrid which makes it able for all apps to coexist on all servers.
Cancel
This message was originally posted by Ron Oglesby on November 30, 2004
Ok, I'm wrong your right, your way is the only way, you have a massive farm with 50 apps and 40 servers and mroe knowledge than anyone else... Can you tell I am trying to be annoying. Let me let you in on a little secret, softricity doesnt work for every app... And a lot of organizations with HUGE farms were managing them and running a REALISTIC environment long before softricity. was there pain? Sure. Did they find tools and processes to work out that pain and still manage the environment? Sure. Hell I ahve seen 4 guys manage a farm with 300 servers and 35000 named users.. Tell me its not realisitic. While I am a HUGE fan of Softgrid and my company has done a bunch of it (hell I even manage the site Softgridguru.com) I also know that a lot of companies are not going to bite off on it. Of course I have a server farm in the hundreds and hundreds of server going to softgrid. I also have several enterprise sites (read hundreds of servers and hundreds of apps) that are not going to softgrid. Now tell me Siloing isn't realistic. Just because you can do something doesn't make everything else unbearable.
Cancel
This message was originally posted by Huntre on December 1, 2004
Hi Ron - I agree with you all the way. It sounded like you almost described us except that we basically have 1 person trying to manage 2 globally dispersed farms of 250+ servers with over 1000 published applications. (many of the apps are the same .exe, but published with diff parameters)
As you can guess it's not the most optimal environment.
I am very intersted any any product that might allow us to virtualize the application environment and reduce the number of servers. I have tried to get my company to look into SoftGrid but was basically told almost 2 years ago that 1) it wasn't ready for 'prime-time' yet, still had some major issues and 2) that it dealt with end-user applications and out of scope of the server teams area (bangs head on desk) - so, as a result, we have many application silos - and it works. I don't have to worry about the SAP team doing an upgrade that would affect the Siebel teams apps and vice-versa, for many apps.
The downside, with N+1 is that we have a large number of under-utilized servers. I have high hopes for Citrix's AIE, which would not require such a complex packaging/deployment architecture and in theory would not be near as expensive. This would also get me past those who are against me dealing with end-user applications in my company, as it's just a few small additional steps when publishing the app. Keeping fingers crossed !
Cancel
This message was originally posted by Andy Smith on December 3, 2004
To me, I like the benefits I get with siloing from a user profile perspective. My Oracle/SAP/whatever servers get a fast-loading mandatory profile, and my Office servers get a slower but more user-functional roaming profile. Roaming profiles tend to get corrupted and I like to have that potential isolated to a subset of my servers.

Softgrid is interesting and unique technology. I'm sure it works, but I haven't seen the need just yet.
Cancel
This message was originally posted by an anonymous visitor on December 7, 2004
Hi Andy,
to me the user profile perspective is main issue, too. We have different profiles too, but all roaming. How do you attach the different profile types (romaing & mandatory) to the user accounts?
Cancel
This message was originally posted by Andy Smith on December 7, 2004
You can do multiple profile types by setting each user's profile to an environment variable. The environment variable can be set separately on each citrix server. That way you've got completely separate profiles, potentially for each server or for each server silo. If you want to use mandatory profiles, you can just copy the .man file into each user's profile folder location.

If you are lucky enough to have Windows Server 2003, you can use group policies to specify server-specific profile locations as well.
Cancel
This message was originally posted by an anonymous visitor on December 6, 2004
Have just read this article and totally agree. Our small 25 server 200 app farm is using all of the above including ICA pass through. The only down side is some time under used servers. Have even found the need to put IE on a seperate sever which is in an OU with special permissions to allow IE link apps requiring certificates etc for special users. The desktop IE is really locked down but desktop links to the IE app server (different icon) on per users group basis
Cancel
We use Softricity. It far from being "unproven". WIth Softricity you don't need ANY silos. I will never deploy apps again without SoftGrid. To be honest we are leaning at getting rid of Metaframe altogether and going with the next version of TS and SoftGrid. It's the perfect combination.
Cancel
ORIGINAL: Guest

This message was originally posted by Ron Oglesby on November 30, 2004
Ok, I'm wrong your right, your way is the only way, you have a massive farm with 50 apps and 40 servers and mroe knowledge than anyone else... Can you tell I am trying to be annoying. Let me let you in on a little secret, softricity doesnt work for every app... And a lot of organizations with HUGE farms were managing them and running a REALISTIC environment long before softricity3dd3d3dfdf42e hundreds of server going to softgrid. I also have several enterprise sites (read hundreds of servers and hundreds of apps) that are not going to softgrid. Now tell me Siloing isn't realistic. Just because you can do something doesn't make everything else unbearable.

 
strange
Cancel
What about the extra licenses needed when installing all apps on all servers?  I'm looking for definitive answers from several manufacturers - but Microsoft indicates that because their applications are licensed by 'device' not by user, that every install in the server in the farm would need a license on top of all the license we already own for each thin client that will access the software.  If we have a 100 servers in the farm, that's a pretty good extra chunk of money for more Project, Visio, Office licenses.  That would be an argument for doing siloed environment I guess.. but it seems ridiculous that the server installs of desktop apps would require additional licenses in this sort of environment. I can see 1 additional license to cover the "farm".  We're not changing the number of devices or people that are actually using the software, so why have to bend over for so much more licensing?   Does anyone have any information that would contradict the impression I'm getting from MS Website and sales reps on this issue?     
Cancel
The better question that begs to be asked is how is the licensing interpreted if using a Softricity environment since the app is not technically "installed" on the server.  LOL

Shawn

Cancel
Cancel

Hi, I know this thread is old but I am looking at a similar scenario and the question for me is does this sort of two tier published desktop with a pnagent to access published applications use up two licenses for a user? ie a user launches a desktop then access a published application like word? thereby creating two sessions which use two licenses? If so how can the cost be justified?


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close