Reliable servers (was Re: assignment to __class__)

[Aahz Maruch]

In article <9l9d4k02opd at enews4.newsguy.com>,
Alex Martelli <aleaxit at yahoo.com> wrote:
>
>Yes, but, when servers DO have to stay up, fixing them on the fly,
>albeit indeed fragile, is a specified constraint.  I guess in some cases
>one could devise alternate strategies: putting up a new fixed server
>process on a different machine, port-redirecting all new requests to
>the new machine, and finally pulling down the old buggy server when
>the conversations for the requests it was serving at fix-time are gone.
>
>But that constrains your deployment possibilities enormously, and it
>has its own huge fragilities (e.g., the server must be architected so
>that multiple instances, old and new, can update the same database
>without tripping on each other's feet -- just for starters).

After spending 1.5 years on a medium-sized project (roughly 50K lines of
mostly Python code), I've come to the conclusion that if your server
architecture is designed for only one server instance, there's something
wrong with the architecture.  That goes triple or quadruple if 100%
uptime is a stated goal.  We got bit several times because we violated
that in our initial design, and most of our 2.0 work was fixing that.

Fortunately, the one truly uptime-critical part of our application *was*
initially designed to have multiple servers, and for precisely that
reason.

Patching running code is just so ... so ... mainframe.  ;-)
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Hugs and backrubs -- I break Rule 6                 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista   

Internet $tartup$: Arbeit ueber alles