I started writing this after a series of discussions with one of the smarter people I work with, we disagreed a fair bit, but it got me to thinking, we disagreed a fair bit, but it got me to thinking, so here they are (my thoughts)..
No, I am not talking about pizza, though I am sure I could start up a great debate on that topic here in Chicago.
I am talking about hardware and software. Two separate yet related issues, which I think unfortunately are far often considered one issue.
That is a natural accident as they tend to get intertwined technically and the debates of both tend to devolve into the same basic issue of flexibility vs. control. One side sees the need of users to have control of their own systems and data.
Coming back to the separation of the thick vs. thin questions for hardware and software, consistency is not required. You can have thin hardware client yet still have a thick software client. To understand this you should understand where the hardware-software separation is in this context. It is not at the interface of machine code and CPU’s, as you might be apt to first assume.
The question of whether a hardware device is a thick or thin client occurs at the operating system level, and the question of whether software is thick or thin occurs anywhere above that. I think the best way to categorize if a hardware client is thick or thin is on the basis of whether it has “free-will” or not.
The best way to describe what I mean by free-will is that a client system without free-will when directed to a specific server will perform exactly the same as every other possible valid client system. In order to be purely thin, a client system must always do exactly what the server directs it to do.
Like most theoretical things this separation actually occurs as a sliding scale, but at least so far, thick and thin hardware clients have clustered fairly close to the two poles of this scale. The PC, at one pole, does not even assume the existence of a server and thus has more or less complete autonomy. Devices that range from text terminals to more advanced graphics terminals (also known as remote desktop) occupy the other pole. These terminal type devices generally have few if any difference in behavior given the same server and user activity.
Browser devices are a slight deviation from this design. These devices provide only one function, a web browser. The word device is important here because a browser is usually part of the software layer. Nevertheless, here the browser device is close to a hardware thin client because it restricts the interface method to the server.
I say it is close to a hardware thin client because as anyone who has used more one browser can attest, different browsers do not always produce the same result. Browsers have varying degrees of standards support, differences in interpretations. Even when implementing standards they have a degree of flexibility in rendering and interaction behavior. For example, the user interface outside of the web page is entirely defined by the browser (menus, back/forward, history, etc.). So two different browser devices may not perform exactly the same even given the same server, yet still provide connectivity. Still the browser device is far closer to the thin end of our scale than thick, as it intends to provide consistency, even if this is not absolute.
Unlike hardware thick/thin clients that are polarized, the software layer is distributed over a sliding scale. There are software solutions that emulate the remote desktop and browser device models. There are fully autonomous client applications. There are client applications that send commands to server and receive back workflow commands or scripts that they execute locally, and thus end up near the center of our scale. Between all of these types of clients are others that mix the different methodologies to greater or less degrees.
Therefore, software has a very broad range of implementations yet still maintains the basic measurement of thinness or thickness as the degree of free-will. Does the client obey the server, cooperate with the server, take suggestions from the server or act unilaterally?
Thinking this way, the terms thick and thin are somewhat unfortunate, as they describe what was observed as a common characteristic of the two designs rather than describing the actual design itself. Thin clients were observed to generally require fewer resources, but this is not an inherent characteristic, just a common one.
As a counter example, it is possible to create thick clients that require far fewer resources than a web browser to perform a specific function like ordering pens from Office Max. It would not be able to perform all the other operations a browser does, but it would be “thinner” in terms of resource usage, and still not fit the common concept of a thin client.
The assumption that thin clients use fewer resources does generally hold true, however some other assumptions about thin clients are far more conditional.
One common assumption is security. The reasoning is that by centrally administering the data and application logic, administrators will do a better job of insuring proper security management.
There are two flaws with this assumption however. Statistical evidence and common sense tells us that administrators will do a better job that the majority of users, but not all users. The original assumption does not qualify the fact that a portion of the users will do a better job than their administrators do. Also forgotten is that the administrators themselves are an added risk, except in corporate environments where they already have unfettered access.
Therefore, while centralized administration is appropriate in some scenarios, I think most would agree that it must have limits, since the purist end-game for centralized administration is a single authority with full access to all the world’s computers, and I am pretty sure no one wants that.
The other flaw is that thin clients do not have a monopoly on centralized administration. Many thick clients provide the ability for a great deal of centralized administration. At first, this appears be a “thinning” of the thick client by relinquishment of free-will. However, the design for central administration of thick clients allows not only for central control, but also allows central control to return free-will back to the client.
Thin clients “platforms” in converse have methods to conditionally return some free-will to the client. I say platform to highlight a nuance of how this is achieved. Often in thin client platforms the server acts as a client host. This is not a rule, web servers are not client hosts, but self-contained server applications, except for some rare exceptions. However, remote desktop servers are essentially client hosts, as they provide the equivalent of an operating system session. Depending upon the design this session may be the emulation of thick client hardware.
In such a case, centralized administration is barely more inherent in thin client hardware, then within thick client hardware. An extreme (though common) example would be a VMWare host that provides a user with an emulated X86 machine. Since the user can install the operating system, applications and configure them, he essentially has unfettered ability to muck up his entire virtual machine. In theory, the user has the ability to attack other virtual sessions on the same box if VMWare has any exploitable security flaws. At the very least, if the virtual sessions are not segmented into different virtual networks, then an infected virtual machine is as dangerous as any hardware thick client.
The only advantage that administrators would have in the above example is the ability to force shut down the infected virtual machine. However, through remote administration, a hardware thick client usually can usually be shut down. If that fails, modern switches could drop the machine from the network. Of course, there is also always the final recourse of a manual power off. There is a difference, but it is rather minor in the grand scheme of things.
Above the hardware level, thin clients can gain all the free-will of thick clients through emulation but cannot do so without also gaining the accompanying problems. Thick clients can also through centralized administration relinquish their free-will in small chunks to resolve those same problems. Also thick clients can run thin clients. Because of all of this, neither thick or thin hardware clients have any inherent advantage or binding to thick or thin software clients, so we can consider the two issues separately.
On the software side, thick vs. thin is a decision best left to the individual applications, as some are better suited to one design or the other. On the hardware side, the question is simplified down to one of physical realities. Thick hardware clients will generally require more resources, but will require fewer server resources to support, will cause less network traffic, and provide better graphics quality and input latency.
Depending upon the state of technology at any given point the quantitative value of more, fewer, less and better can vary from very small to very large.
Thin hardware clients allow central management of more of the hardware, but in today’s computer environment the vast majority of support and management time deals with software issues, not hardware.
Thick hardware clients provide limited insulation from network or other central outages and can support portability to locations where the network is unavailable.
Both sides have significant advantages, and depending upon what type of work you do, and in what environment what is best for you will vary.
Personal use currently clearly favors the thick hardware client. Since there is no trusted authority that already has access to user information, this would require a large relinquishment of privacy by users. In addition personal use is currently more likely to require high quality graphics and input latency, and less likely to have the necessary network bandwidth (and reliability) to support it. Personal users also require portability, but probably no more than organizational users.
For organizations, the question is far less clear. Most business applications do not make heavy use of graphics, although input latency can still be a very important factor. Network bandwidth and reliability is also generally greater when on-site. However, many users still require portability, and until high speed and high reliability wireless is ubiquitous this will remain an issue.
By using tools like VMWare organizations could save some money by moving users to thin client hardware, while still maintaining nearly the same user experience and capabilities. However, many users simply cannot now, and this complicates the issue. The best strategy is probably to start building the VMWare farms for secondary purposes like QA departments and experimental deployments. Primary machines should be handled on a case-by-case basis for the time being, or simply wait until ubiquitous wireless service allows the less technically demanding and savvy groups to accept a change.
This may sound like an endorsement of thin clients, but to generalize it that way would be a mistake. Thin client hardware still has no solution for a vast portion of the user base. I also feel it is important to keep things like user interfaces common between the two worlds and that is why I would recommend solutions like VMWare, which emulate thick clients. This notably does little to address most of the management issues, but I am of the opinion that giving thick client operating systems better centralized management support is a better way to addresses those issues.
Also on the issue of centralized management, I am of the opinion that it is far better to design management into software, rather than to design free-will out of a system. The difference is that in one case, you can release flexibility to users on a conditional basis through configuration, and in the other, you need an application rewrite. To me it is somewhat like the difference between having a door you can open and close or filling your doorway with bricks.
The overemphasis of draconian management is what has driven me away from thin client hardware for quite some time. Worse yet was that many systems provided no method by which individual users could step outside the box.
Recent Comments