Evaluating thin clients from a position of strength

All too often our schools (and even our colleges and universities) turn to thin-clients as a 'last resort' to address severe budgetary constraints without regard for other alternatives which can also reduce costs without sacrificing needed computing resources.  Many view thin-clients as a one-stop solution which fixes easy-to-identify problems within an existing infrastructure.  Often these problems can be summed up easily as: 

Ancient hardware, too few IT staff, and too little money.

Rather than looking at thin-clients in terms of service enhancement, education IT often looks at thin-client solutions as nothing more than a "quick-fix" to save money.  These short-term savings only put off the inevitable realization that low-cost personal productivity solutions are insufficient for meeting the full scope of the academic needs of your students and the instructional needs of your faculty.

If instead, your starting-point is a life-cycle funded environment and a well run IT operation, the introduction of thin-clients can enhance your services dramatically -- not by reducing your dependence upon robust workstations but by freeing up those workstations for those truly demanding applications. 

Case in point?  Chris Dawson's computing environment: 

Chris has placed thin-clients in appropriate settings in a newly life-cycle-funded environment while maintaining "fat clients" in those settings which best leverage the powerful nature of these workstation. 

Conversely, rather than using thin-clients to deliver a basic personal-productivity suite to student labs, thin-clients can be targeted to deliver specialized, high-cost, but low-bandwidth, applications to student-owned computers located remotely.  This approach can be especially successful in a higher education setting -- not as a replacement for fat workstations but as an enhancement to such full-function facilities. 

In education IT (especially higher-education), meeting even 90 percent of your user's needs is simply not sufficient.  Sure, give your students and faculty access to a browser, a word processor, and a spreadsheet, on a reliable and responsive platform, and your users will be ecstatic most of the time, but that will not address all of the instructional needs of your faculty -- nor will it meet the needs of many disciplines. No matter what, you still need full-blown workstations to meet many academic needs.  Even if you require your students to own their own computers, often students cannot afford to buy their own copies of the instructional software your faculty wish to use -- and can that you can buy through your institution at dramatically lower cost. 

To adequately evaluate the suitability of thin-clients in a traditional computing lab setting, one must not only consider the savings realized in the lower acquisition costs of thin-clients, one must also look at the back-end costs of acquiring servers to support those thin clients.  The rule of thumb is that in a client-server setting, one server can provide a desktop image to between 10 and 20 concurrently-running thin-clients.  To do this, however, the server must be much more robust than your typical file server or web server.

In many instances, the cost of a thin-client (plus a monitor and keyboard) is only marginally lower than the cost of a mid-range workstation while the cost of a robust mission-critical server may run ten to twenty times the cost of a single mid-range workstation.  (And please don't tell me you can use those old monitors and keyboards -- they are already part of the problem.)  In the end, considering hardware costs alone, the acquisition costs or a thin-client lab may be quite similar to the costs of a lab full of workstations. 

From another perspective, the savings of the thin-client approach is derived, at least in part, by the assumption that fewer machine cycles are wasted by a server connected to say-fifteen clients than those wasted by fifteen fully functional workstations.  While not an unreasonable assumption it is not necessarily a forgone conclusion.  (And it is very difficult to measure.) 

Whether you are building a lab full of thin-clients connected to a server or two, or a lab full of workstations, one has to build that lab to support a maximum number of users running your most robust classroom-oriented applications, not just the typical application.

And what about your bandwidth needs?  By shifting your computing cycles away from the client and toward the server, you may reduce the occurrence of idle cycles but, at the same time, you've increased the  demand for bandwidth between your machine room and your student lab.  If you've got the bandwidth, that's fine -- but if you do not, this added cost must be factored in as well. 

In a research environment, thin-clients are not the only way to reduce idle cycles.  Today's research environments have the capability to leverage idle cycles found anywhere on their network through the use of small, low-bandwidth, applications which can run in the background in those traditional labs but which simply cannot leverage thin-clients. 

By viewing your computing resources as a whole, one can leverage many techniques to reduce your cost-per-seat for student computing.  And after all, isn't that the goal?

It is time for education IT to start thinking in terms of providing better service for the same money, not the same service for less money!