BEWARE upgrading Horde System

Ted Mittelstaedt tedm at toybox.placo.com
Sun Apr 9 23:33:21 UTC 2006



>-----Original Message-----
>From: Nikolas Britton [mailto:nikolas.britton at gmail.com]
>Sent: Sunday, April 09, 2006 7:57 AM
>To: Ted Mittelstaedt
>Cc: Marc G. Fournier; thierry at freebsd.org; fbsdq
>Subject: Re: BEWARE upgrading Horde System
>
>
>On 4/9/06, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
>>
>[snipped]
>>
>> I have never understood the demand for being able to do an inplace
>> upgrade of applications or of the operating system, and I've seen
>> enormous trouble with servers that people do this with, under Windows
>> as well as FreeBSD.
>>
>> Furthermore, by the time the software on the server is old,
>the hardware
>> is ready to be retired in favor of shiny new hardware that is a lot
>> faster.  This is also very true of Windows servers too.
>>
>> This gets back to what I was saying with professional-vs-amateur
>> approach.  A professional approach to a server is to plan for it
>> to live a certain life then you scrap it, or at the least nuke and
>> repave it for something less demanding.  The car-rental companies
>> have been doing this with cars for years, and all the used car buyers
>> can never understand why a car rental companies sell perfectly
>> good cars with a lot of years of life left in them.
>>
>> The amateur approach is to build the server then wring every last
>> day of life out of it.  Patch and patch it over and over and over
>> and upgrade it over and over and over, until it just won't
>work anymore.
>> Hell, people were complaining that FreeBSD 6.0 wouldn't run on a
>> 80386!!!!  That's a total amateur approach.
>>
>
>I think your mixing up the professional approach with the I'm not
>paying the bills approach, that "shiny new hardware that is a lot
>faster" comes with a price tag attached to it and the price attached
>to that tag in relation to other factors determines the route to be
>taken. You do have, at the very least, a basic fiduciary
>responsibility to your employer, and in the context of business it's
>money.
>

No, it's not.  In the context of business it's competition.  While your
wringing the last drabs out of your older hardware, your customers are
looking at your competitors products that are fielded on NEW hardware
they bought last week, not 3 year old hardware they bought 3 years ago.

You need to get some sales education, big time.  For the total cost of
getting 3 new customers you could pay for that new server.  If you elect
to not get that new server, assuming that by doing so your savng your
employer money, it is as they say penny-wise and pound-foolish.  It
is common thinking that system admins who pay the bills have, they
often lose sight of the forest for the trees.  Rather than thinking
"how can I use FreeBSD to save my employer money" your employer would
be far better off with you thinking "How can I use FreeBSD to provide
even more features to my customers than the competition, so that our
competitor's customers come over to us"

And let's say even if that server your looking at upgrading is only a
year
old, and still within acceptable speed, well then what are you doing
about
sparing?  If your running a datacenter and selling access to apps you are
fielding on your servers, your customers are paying you to be available
either 24x7 or during business hours.  If your server motherboard takes a
dump at 11:00am in the morning, you should be able to move the disk pack
to your spare box and get going within 20 minutes.  You can only do that
if
you maintain a hardware spare.  And so for mid-term upgrades, you build
it on
the spare server then swap the spare with the production server in the
dead of night.

I'll tell you what - you seem to be promoting the amateur approach of
no sparing, and doing inplace upgrades until the server hardware dies -
so why not give some specific examples of how this saves money over
the professional approach of maintaining sparing and a set hardware
lifespan that I'm advocating.  I think I've spent a lot of paragraphs
outlining the approach I'm advocating and why it saves money for the
organization, while you've only done some hand-waving about "fiduciary
responsibility" and some vague assumptions about how doing it the
amateur way is better.

Ted



More information about the freebsd-questions mailing list