Slashdot Mirror
To Citrix or Not to Citrix?
Saqib Ali asks: "These days, it seems almost any application can be served on a Citrix Farm . However, not all application are best fit for a Citrix environment, and I am sure most IT admins are faced with the tough decision of whether to host an application on Citrix or not. What questions should an IT administrator ask before deciding whether to serve an application over Citrix or just plainly install the application on each desktop? I am NOT looking for the benefits of using Citrix, as I'm very well aware of them. What I want to know is, what criteria should be used in determining whether to use Citrix for an application or not. I just don't want to use technology for the sake of using technology. There should be a methodical way (like a checklist or questionnaire) for determining the feasibility (NOT PROs and CONs) of serving an (any) application on Citrix. Here is a Checklist/Questionnaire that I have come up with. Any more suggestions to add to the checklist?"
When frustration peaked, they installed a real Windows box besides our HP360, so we ended up with 2 systems; it is cumbersome, but it works.
In my view, all this could be replaced with a single Linux box, OpenOffice added, plus any additional application you might require on top.
> Any more suggestions to add to the checklist?
Lots of good suggestions so far. As a long-time Citrix admin, I would add a couple questions to the fairly good ones you already have.
Will the app vendor still support the app if it is deployed via Citrix? In my experience, this is a really good question to ask up front before deploying the app!
Are your apps mission critical? Do you need high availability for them? Citrix really reduces the cost of deploying and supporting mission critical applications, but at a price, as another poster in this thread rightly pointed out. If you don't have the numbers to get the bulk discount rate, Citrix may not save you all that much.
Finally, one that probably doesn't need to go on a checklist, but one that you should ask yourself anyway. Are you willing to work with Metaframe, with your users, and with the app vendors to make it work? We have a nice stable Citrix environment here at the rocket ranch, but we worked with our vendors, and with Metaframe to make it that way. It didn't happen overnight, and I had to take several Citrix training courses before I got really comfortable with Citrix. It was worth it, but that is just my environment -- ymmv.
Your first question looks wrong off the bat. If you have a web-based client, why are you needing Citrix at all? If the software is already server-based with a web interface, it doesn't need a terminal. Unless that's your point, you don't explain what you would do with the checklist answers.
Unless Citrix has some quirks I'm unaware of, the first question is immaterial. The second question is much more important. Applications that are network bound are much better to run with a terminal, ie; I always verify our main database's schema using a copy of the client running on the server. However, the last two major upgrades we done have been specifically designed to reduce the network traffic that it generates, while at the same time we're starting to sniff around gigabit ethernet. Since most applications are not run on Citrix-esq installations, any new version is suddenly likely to change the balance of network traffic to server and client load.
Here I'm assuming you're talking about non-network apps (Like Word) and a user's connection to the Citrix server. Obviously, high latency to the Citrix server will make any app that would otherwise be installed locally look crappy over Citrix. That's so obvious that I think I might have missed your point on this one.
Here I have to again assume you mean that staff might be rocking up with a floppy or CD with files that need to be transferred up to the application on the server so they can work on them. Yes, I would imagine that applications with large amounts of local data are best handled locally.
Do you mean "Does the program need a server anyway"? Ultimately that only matters for laptops and server downtime. I question the value of laptops in lots of situations. Where I work, apart from a couple of people that develop stuff at home those of us that use laptops only ever use them plugged into a LAN. They're just a familiar environment that can be moved from one office to another, and occasionally used to check email remotely (except we have webmail now, so any PC will do). As for server downtime, many companies have a key network database application that staff use all the time. Without it they're stuff anyway, what does it matter if a few other lightweight apps are down too.
You're referring to CPU load on the server? This is where I tend to think that Citrix is the wrong solution. Desktop PCs are so cheap and powerful, why are we killing ourselves to build a monster terminal server? But you don't want to talk about that. Or maybe you mean that if the numbers are too low, it's not worth centralising? I guess the sweet spot depends on the price of the application (if it's licenced differently for Citrix vs desktops) vs its processing requirements.
That looks like your WAN question above.
Not sure how this would differ application-to-application. This would much likely differ from department to department.
Okay, I've tried to stick to your rules, now here's my real answer. Centralised Citrix-like systems for Windows applications are not the answer. Thin
Test the apps you will need. The company I work for sets up and install application servers as our base business model and you have no idea how many programmers just assume they are the only application on the machine, and only one user is running it. Even some large scall stuff.
A lot of low power apps, ones that don't need much/any horsepower are idealy suited for app servers, but just don't work, so try them first, then buy.
Anyway... someone probably said all this already...
On Arrakis: early worm gets the bird. Magister mundi sum!
1. Some applications conflict with other applications, requiring us to install them on separate Citrix servers ("server siloing", doubling the hardware and administration costs).
2. Performance over a slow link degrades to the point that fast typists could enter an entire line before seeing the first character appear.
3. The "thin client" model assumes that the client has little to no intelligence and just sends keystrokes/mouse movements up, and screen updates down. It doesn't use any of the local processor, RAM, or hard drive (like the old "green screens").
Since most companies (ours included) aren't purchasing "thin clients" because they end up costing about as much as a full-blown computer, we just bought computers for our employees. Running Citrix does not use the resources in our company to the fullest; most of the time those machines just sit there, idle.
We have found a great solution from a relatively small new company called Softricity.
Their product, SoftGrid, streams the application to the client. Your IT department will have to "sequence" the application (basically, install it in a monitored environment so it can determine what files, Registry entries, INI files, etc. to package up), and it creates a single file which contains everything. It also determines what pieces of that file are used when running the application, and streams that to the client initially (generally about 10-20% of the full package). When a client uses features that weren't in the initial section, the client will request them from the server.
As to the issues I mentioned above above:
1. This has completely solved our application conflicts; we can run any application next to any other application, on the same client machine. We also have some applications set up in a "three-tier" method, where the applications are streamed from the SoftGrid server to a Terminal Server, and then the clients connect to the Terminal Server and run their applications from there. With this model, anything Citrix would add to it is superfluous--we just use the basic TS functionality that Microsoft provides.
2. The link speed does not slow performance down, once the application has been loaded into the client's cache. And the user can load the entire app if desired, which helps with our laptop users--they load the application and can then run it disconnected from the network.
3. The software doesn't have to run on the server, since it uses local resources (RAM, disk, processor). This means our SoftGrid server can serve thousands of users (not that we have that many), whereas our Citrix server starts to slow down when we have more than 25 or so users on it.
Managing the environment is also made much easier with the Management Console, and being able to specify Registry entries in the startup file which will override the entries in the package, so for instance each user can have their own startup file which specifies their username, department, extension, etc. And if there's ever a problem with an application that requires, for instance, a reinstall, it's basically a 30-second operation to have the user bring up the Control Panel application, remove the application from cache, and then run the application again which starts it back at the same state it was at when it was initially packaged.
I've been very happy with their solution, and although it's not cheap it's cost-similar to Citrix, and gives us more benefits and more flexibility (our traveling salespeople love it, since they don't have to connect in order to run applications).
I feel fantastic, and I'm still alive.