The truth about thin clients

I could not agree more with Chris Dawson that, given the choice between cobbling together parts from a bunch of lame PCs and buying new thin clients, that buying new thin clients is the proper choice to make (see Why you should actually pay for thin clients) but before you actually invest in thin client technology, you should think long and hard about how you intend to use these thin clients. 

First, let me touch on why (assuming that you have determined that thin clients will meet your needs) Chris is correct: 

The answer is because in the twenty-first century, the human costs -- in terms of time, salary and benefits, and in overall productivity, are by far your school's greatest expense.  Time lost fussing around with temperamental hardware with tens of thousands of hours of operation on it is time wasted because it is not spent educating students.  And doubly-so because it is also time during which students do not have access to the resources they need to learn on their own.

But what about the decision to use thin clients in the first place?

The premise behind thin clients is that by centralizing computing resources, economies of scale can reduce the overall cost of computing.  This can, of course, be extended to the arguments of our self-proclaimed "tree-hugging" friends, like Chris, who point out that running a thin client consumes less electricity than a PC in similar service. 

Aye, there's the rub!

"In similar service" is the key.  In a traditional enterprise setting, you purchase the tools you need to fulfill a specific task but you don't purchase tools which do more that you need them to do.  In such a setting, where 'bang for the buck' is king, specific jobs need specific tools, the thin client can indeed be cost-effective.  Even then, however, thin clients are relegated to repetitive tasks using a limited number applications on an irregular basis throughout the day.  On a shop floor?  Sure!  On a executive secretary's desk? Probably not!  Identifying appropriate use of thin clients is even more critical in education -- where demand is unpredictable and academic needs change on an almost daily basis.

So where are thin clients appropriate in education?

While I'm tempted to say "Nowhere!" such a flip response misses the point.  By their very nature, thin clients can be appropriate and cost-effective in any low-demand setting -- but what do I mean by low-demand? 

As I have discussed at length in this forum, the greater the number of students using your computer labs during the day, the higher your return on investment.  That's why I do not support initiatives which utilize public money to give laptops to individual students who use them for only a few hours per day when the same money could buy more desktop computers which could be used throughout the day by a larger number of students. 

The question is whether or not thin clients could further extend your investment.  If demand for access to a specific suite of applications is truly limited, then yes.  For instance, a device dedicated to accessing a library card catalog (or a security-sensitive SIS system) can (and should) be a thin client.  Can this logic be extended to a device which is dedicated to accessing web services?  Yes, as long as the thin client can do its own processing (without an intermediate server). 

How about to a word processor or a spreadsheet -- delivered from a server?  Perhaps -- if the demand remains low throughout the day.  For instance, it could be argued that given sufficient bandwidth, one "workstation class" computer server could easily deliver services to 10 thin clients if they were used only ten percent of the time during the day.  A server equipped to support 5 concurrent thin clients could support 50 such thin clients -- not unusual for a typical computer lab -- if the bandwidth were sufficient and if those thin clients were used only 10% of the time.  But what if those 50 thin clients needed to be used concurrently?  (Also typical for a class using a computing lab.)  Even if used only 10% of the time, the computing resources of the server to support those 50 thin clients concurrently would have to be proportionately larger.  This does not even address the overhead issues of managing concurrency on the server and on the network. 

The thin client makes bandwidth demands on the network without adding computing cycles to that network.  Those cycles must be delivered by a server.  As long as that server does not have to deliver those cycles to all thin clients concurrently, the opportunity to realize economies of scale is there but as soon as large number of thin clients must be provided network services concurrently, economies of scale can quickly be lost to network and server overhead.  Network bandwidth becomes your bottleneck and your server becomes a single point of failure.   

This goes to the 'utility' nature of the network.  Like the electric company and the water company, the network must have the capacity to serve PEAK demand for resources -- not just average demand.  This same principle applies to the network server.  So, if you have fifty students all computing at once, whether they are using fifty PCs or 50 thin clients, they need fifty times the computing cycles to get their work done.  But, the thin clients consume more cycles thanks to server overhead and the thin clients have greater demand for network bandwidth. 

If you have the server cycles and bandwidth to spare, unlike a PC a thin client model can provide efficient delivery of computing cycles to where they are needed most but, unless your life-cycle funding keeps you ahead of the growth curve, as soon as you start approaching the capacity of your network, or of your servers, the thin client model fails miserably. 

The thin client model also locks you into a limited set of capabilities.  For instance, assuming you have network capacity to support the thin client model for personal productivity applications, you are still hamstrung when it comes to truly high-end graphics intensive applications which make extraordinary bandwidth demands on your network.  And what about streaming audio and video?  The thin client you buy today may be able to meet your needs today but what about three years from now?  Adding capabilities to a PC a year from now may be more straightforward than adding those same capabilities to a thin client with its embedded OS a limited upgrade-ability (which is what keeps its cost low.)

My advice?  If you want to look at thin clients, you should do so but do not expect thin clients to replace PCs in all settings.  Keep in mind that there are network bandwidth issues associated with thin clients and with concurrent use of thin clients comes reduced server efficiency -- reducing those economies of scale thin clients are intended to address.