[THIN] Re: Here's a biggie. Why is thin computing the future.

  • From: "Braebaum, Neil" <neil.braebaum@xxxxxxxxxxxxxxxxxxxxxxxx>
  • To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
  • Date: Thu, 18 Jul 2002 13:48:24 +0100


-----Original Message-----
From: Shannon Wyatt [mailto:swyatt@xxxxxxx] 
Sent: 18 July 2002 13:11
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Here's a biggie. Why is thin computing the future.

This would be true if you didn't factor in the real cost of Thin Clients. I
often hear numbers batted around on the "real" costs of owing a PC versus
the cost of a thin client. But if a thin client envioronment is managed the
same way as a fat client environment then the actual cost of running a thin
client envronment would be pretty high as well. But after one of your
servers gets trashed from the end users the administrators start clamping

I have never *once* in over four years of doing this, had an end-user, cause
me a server problem.
Help-desk have always been able to shadow, for usability issues. Desktop
environments are very restrictive, and mandatory profiles, so users can't do
anything to the servers, and nothing to damage their environment.
I've done two changes in server OS, since implementing the thin clients.
Numerous changes to apps, not had to upgrade the WBTs - can't see a need to
for the foreseeable future, either - but there are other constraints (I'll
mention later).

  But lets compare the actual costs of a thin client per user to run
Microsoft Office.
Thin Client $400
Portion of hardware on server for each user $200 (Assumes a $10k server
supporting 50 users)
Metaframe and TS License $350
So the actual cost of a thin client is much higher then the purchase price.
If a thin client doesn't have a host to connect to it is not much more then
a boat anchor. 

There would still be server costs for fat clients - both if you're
implementing thin client apps, or merely for back-end usage.
The point being, that notational purchase price for the WBT, compared with
the cost of a PC, has not needed to be revisited in four years. Nor can I
foresee any obvious needs to change it. Despite possibility of future new
versions of OS and / or apps. This would hardly be the case, were it a PC.
But as I said, initial, capital costs were never where it was at. Logical
administration of the environment that the *users* use, is radically
different, and less costly, than it would be with countless PCs, and the
products needed to administer the PCs. I say this, because as a company we
do use PCs, and software to manage them, so I have direct, like-for-like

Sure, I have to upgrade PCs every few years, but I've also had a few clients
that had to replace their thin clients as well. 

I haven't - beyond hardware failures covered by maintenance contracts - nor
can I see an upcoming need to either.

  If you purchased your thin clients in 98 then odds are pretty high that
they only support ICA, so no RDP. And odds are that a client made a year
later performed much better. 

Largely irrelevant for the constraints that my main implementation covers.
ICA is pretty much a must - bandwidth to each location is largely 64k.
This is more likely to be the constraining factor.
The devices perform adequately for the users needs. I can't foresee an
obvious reason why they shouldn't continue to do so, for years to come,
despite future upgrades to OS and apps.

Using available tools I can manage a users desktop pretty darn effectively. 

You can - but there's generally more to do.

My argument was basically that thin fits a niche, and fits it quite nicely. 

Indeed it does.

 But it isn't a good fit everywhere.  

I don't believe anybody advocated it was.
Merely that if the apps are *all* thinly-delivered, there's the potential to
trivialise that box at the end of the line. Not having to physically change
it for four years, with the ongoing likelihood that nothing on the horizon
is going to alter that, is quite a boon.
I, nor anybody else that I can see, advocated this being the choice where
all thin-apps are used - merely that there are scenarios where they have a
very valid place, and for very good reasons.

 When you look at small environments with Terminal Services your costs are
actually higher, since to be safe you are going to have to purchase extra
hardware and software to ensure that in the case of a bad stick of RAM you
don't take down your entire network. At least if everyone has a real pc and
the server is down you can still do something. Now if I need to run a crappy
app a low bandwidth pipe then I'm all over Terminal Services and Metaframe.

Ah, but there your talking about best fit for an environment - that's higher
up the food chain of good design.
Where thin-client computing came in for me, and this was late 97, early 98,
was low-bandwidth scenarios, users who had need for applications, as opposed
to full-blown desktops, and a likely method of managing it all. Simple use
of apps, and large numbers of users, are great candidates for thin-client
computing. As are bandwidth challenged scenarios.
Things more leading to hybrid, mix-and-match scenarios are more due to more
complex desktop requirements, power-user type needs, developers etc...
issues where server resources are going to be hard to manage and secure, and
*guarantee* reasonable performance - and scenarios where apps aren't truly
suited to serving the graphics over the network (be it LAN or WAN).

This e-mail and its attachments are intended for the above named 
recipient(s) only and are confidential and may be privileged.
If they have come to you in error you must take no action based 
on them, nor must you copy or disclose them or any part of 
their contents to any person or organisation; please notify the 
sender immediately and delete this e-mail and its attachments from 
your computer system.

Please note that Internet communications are not necessarily secure 
and may be changed, intercepted or corrupted. We advise that 
you understand and observe this lack of security when e-mailing us 
and we will not accept any liability for any such changes, 
interceptions or corruptions. 

Although we have taken steps to ensure that this e-mail and its 
attachments are free from any virus, we advise that in keeping 
with good computing practice the recipient should ensure they 
are actually virus free.

Copyright in this e-mail and attachments created by us belongs 
to Littlewoods. 

Littlewoods takes steps to prohibit the transmission of offensive, 
obscene or discriminatory material.  If this message contains 
inappropriate material please forward the e-mail intact to 
postmaster@xxxxxxxxxxxxxxxxx and it will be investigated. 
Statements and opinions contained in this e-mail may not 
necessarily represent those of Littlewoods.

Please note that e-mail communication may be monitored.

Registered office: 
Littlewoods Retail Limited, 
Sir John Moores Building, 
100 Old Hall Street, 
L70 1AB 
Registered no: 421258 


Other related posts: