home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / admin / 6845 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!welchgate.welch.jhu.edu!johnj
  3. From: johnj@welchgate.welch.jhu.edu (John A. Johnston)
  4. Subject: Keeping up with HW and SW technology? Possible?
  5. Message-ID: <1992Dec31.170925.7351@welchgate.welch.jhu.edu>
  6. Organization: Johns Hopkins Univ. Welch Medical Library
  7. Distribution: usa
  8. Date: Thu, 31 Dec 1992 17:09:25 GMT
  9. Lines: 48
  10.  
  11.  
  12. A dilemma we're constantly facing, and looking for the *real* answer to it,
  13. or at least pointers to a potential resolution.
  14.  
  15. Basic information:
  16.  - We provide a database using Sybase (the server and front end interface)
  17.  - The database development and maintenance is done on Sun hardware
  18.  
  19. The three ingredients involved in this environment; Solaris (SunOS),
  20. Sun Hardware,  Sybase Are horribly intertwined.
  21.  
  22. Eg.  To upgrade a dozen workstations coming of age this year, the Sun
  23. LX fills our hardware performance needs.  The LX *requires* an
  24. immediate migration to Solaris 2.1, Sybase does not work with Solaris
  25. 2.1, and won't for a few months at least, then we need to verify our
  26. apps are ported ok to the revised Sybase, and Solaris, which in turn
  27. takes attention away from the next generation of our product, and time.
  28.  
  29. This leaves us the "option" of not following our best interest hardware
  30. wise, possibly to spend much more than we need with the Sun10, or buy
  31. yestertech and go with the SunSparc2, or reamin status quo.
  32.  
  33. If we remain status-quo, and hold off on our hardware migration, we
  34. basically would lose up to 1/2 year of the actual useful life of the LX
  35. workstation (where buying a workstation near the beginning of it's
  36. product life increases by that much, how far down the road it will be
  37. "state of the art") and lose more of any useful re-sale value of the
  38. Sparc 1's, as they grow further behind.
  39.  
  40. The basic solution seems apparent, just slow down the migration path,
  41. and expect to be 1/2 to 1 full year behind the state-of-the art as the
  42. various major and minor releases of Solaris and Sybase dictate.  This
  43. will cost something in hardware value to us, but we are happy.
  44.  
  45. The resluting problem is a customer...  They want what we have our
  46. product, but are not at all happy buying the last generation of
  47. hardware, when the latest out is the better price/performer.
  48.  
  49. There is no clear win-win scenario.  Software schedules from Sun,
  50. Sybase and even ourselves are usually not right on any schedule.
  51.  
  52. What do *BIG* and *Medium* developers do to plan/prepare/combat this
  53. hw/sw interconnection?  I'd classify us as tiny, but facing the same
  54. problems as the biggies, but on a smaller $ budget..
  55.  
  56. Any and all input appreiciated, and to be summarized.
  57. -johnj
  58.  
  59.