🚀 go-pugleaf

jdd@db.toronto.edu (John DiMarco) writes:

>A centralized authority -- if it is responsive to the needs of its users --
>has the capability to offer better facilities and support at a lower price.

- I've one seen a bill for use of a VAX780 for one year with 10 people.
  It was about $500,000.- (1987). You could buy a faster Sun-3 AND hire
  an operator for less ($1,500,000.- in three years!)

>Just consider some of the relevant issues:

>	Resource duplication: 

In the case of VERY expensive systems you may have a point. Let us look at it:

- laser printers: low-volume high-quality laser printers cost about $30,000.-
  Paying someone to manage a central high-volume printer (more expensive,
  less reliable) costs a lot more, and you need to walk over there to get
  your output. A local printer is more convenient.

- Phototypesetters: either your organisation typesets a LOT, or you go to
  a service bureau to have your text typeset. You think you can beat their
  prices?

- Supercomputers: having your own mini-super (1/10th Cray) gives a
  better turnaround time than sharing a Cray with > 10 people. And it's
  more predictable.

>	Maximum single-point usage: 

- the problem with central 'mainframes' is that you can't predict the response
  time (turnaround time). If I know something is going to take 2 hours I can
  go off and do something useful. If it might take 1 to 5 hours I can't plan my
  day, or I must assume it takes 5.
  (User interface tip: give the user of your software an indication of the
  time a complex operation is going to take. Especially if he can get a cup
  of coffee in that time)

>	Expertise: 

- I've spent enough time explaining evening-shift operators what to do to
  know that only one or two people in the Computer Center really know what
  they are talking about, and they never do nightshifts. If I've offended
  someone, sorry, but that is usually the case.

>	Emergencies:

- Similar. What do YOU do when a SunOS kernel keeps 'panic'ing, and you don't
  have the sources. (Or VM/370 does something similar, and your user-program is
  at fault :-) ). 

>	Frequently the problem doesn't get fixed quickly. 
- If they're simple enough to fix I'll do it myself. If not, I call the 
  manufacturer.

>	Backups: They're a pain to do. Why not have a centralized authority
>		 do backups for everybody automatically, rather than have
>	everybody worry about their own backups?

- With 2Gbyte DAT tapes backing up is just starting the backup and going home.
  They're not even expensive, and an extra backup fits in your pocket
  so you can store it at home. (Assuming your data is not very sensitive.)

>	Complexity: Who's going to keep track of a big distributed network
>		    mishmash with no central authority? Who's going to answer
>	the question "How do I get there from here?" if getting there from
>	here involves passing through any number of un-cooperative little
>	domains. Who's going to track down the machine which throws bogus 
>	packets onto the network, fouling up all sorts of other machines? 
>	In a centralized environment, things are generally less complex, 
>	and those in charge have a much better understanding of the whole
>	shebang.

- I agree that a network backbone should be a 'central' service, just like
  the phone company. Someone must play FCC/ZZF/PTT and only let decent
  equipment on the net. If you mess up the net you get disconnected.

>	Downtime: Centralized computing authorities tend to do their
>		  best to keep their machines running all the time. And 
>	they generally do a good job at it, too. If a central machine goes
>	down, lots of good, qualified people jump into the fray to get the
>	machine up again. This doesn't usually happen in a distributed
>	environment. 

- A central maching going down stop all work in all departments. If my
  workstation quits I alone have a problem.

>	Maintenance: More things go wrong with many little machines than
>		     with few big ones, because there are so many more machines 
>	around to fail. Repair bills? Repair time? For example, I'd be 
>	surprised if the repair/maintenance cost for a set of 100 little SCSI 
>	drives on 100 different workstations is less than for half-a-dozen 
>	big SMD drives on one or two big machines, per year.

- It is. You throw them away and take a new one. This is the same repair
  that you'll get when you take a maintenance contract. If you have a
  100 workstations buy 3 extra and use them as exchange for broken ones.
  Paying for each repair is usually cheaper.
  SCSI disks have a MTBF of 5 years these days. You
  usually buy a new one before they fail, because your workstation gets
  obsolete. There is no such thing as maintenance for a small SCSI drive.
  (although a stuck Quantum 50 can sometimes be 'fixed' by hitting it.
  You trust such a beast? Quantum has fixed the problem now.)

>	Compatibility: If group A gets machine type X and group B gets machine
>		       type Y, and they subsequently decide to work together
>	in some way, who is going to get A's Xs and B's Ys talking together? 

- Know of one Killer Micro that does NOT run a brand of Unix with TCP/IP and
  NFS on it? (even Macintoshes and PCs support these protocols nowadays)

>These are some very good reasons to favour a centralized computing authority.

- Depends on the kind of user you have. If your organisation does 
  data/transaction processing there are very good reasons around.
  If >20% of your clients know as much as you do it's a losing game.
  A central facility can't adapt as easily to the wishes of their
  clients.


Ge' Weijers                                    Internet/UUCP: ge@cs.kun.nl
Faculty of Mathematics and Computer Science,   (uunet.uu.net!cs.kun.nl!ge)
University of Nijmegen, Toernooiveld 1         
6525 ED Nijmegen, the Netherlands              tel. +3180612483 (UTC-2)