Very Reliable Web Server for NT?

Joe Armstrong joe@REDACTED
Wed Sep 20 09:59:52 CEST 2000


On Tue, 19 Sep 2000, Al Christians wrote:

> I've developed some applications for NT (using Delphi) and now
> my marketing partner is finding markets that seem to need  
> some kind of application service provider setup rather
> than to run the software standalone on their own machines.  They
> are very small and not very computer literate operations, and 
> they need to make the same data available for viewing and updating
> from multiple locations.  
> 
> So, now, almost as an afterthought, we are thinking of converting
> these applications to be web-accessible, setting up a server, and
> renting the apps out via a standard web browser interface.  Delphi 
> includes features that are supposed to be able to turn my apps into
> web servers, but I don't trust then to stay up 24x7.  Since this is
> an afterthought almost, we don't want to devote any significant
> effort to keeping the server up, as in perpetually.  The load won't
> be great -- I doubt that we'd ever have more than 10 users at a
> time.  Erlang being promoted for very high reliability, I have ...
> 
> Questions for this list:
> 
> 1. Is there any ways that using an Erlang web server as the front end
> for Delphi apps would be a good way to improve the overall reliability 
> and availability of the server?  We would want some way for the Windows 
> apps to crash (as Windows apps sometimes do) without bringing down the
> server, and with the server to able to continue serving other users and 
> to keep serving up new instances of the crashed apps.    
> 

    Yes and no :-)

    If you want to make  highly reliable applications you will have to
start thinking architecturally.

    You  will need at  least two  machines -  for obvious  reasons you
cannot make reliable  systems with one machine. With  two machines you
at least have a chance - provided both don't crash simultaneously!

    Three machines  is even  better. Once to  act as a  front-end. The
other two to service the requests.

    If  you want  24x7  you also  have  to consider  (in detail)  what
happens  as you  upgraded you  applications. i.e.  how do  you  do "in
service upgrade without loss of service".

    All of the  above *is* pretty difficult - and  in the general case
virtually impossible  - If you make certain  limiting assumptions (for
example  that all  transactions occur  in  bounded time)  - then  the
problem  becomes  tractable. So,  for  example,  making reliable  HTTP
sessions is "easy" (actually it's  not that easy) because the sessions
are short -  but making a reliable server for  streaming media is much
more difficult.

    I don't want  to be pessimistic but your  opening words "almost as
an afterthought" don't give me good vibes.

    You  *can* make  highly  reliable  24x7 apps.  and  hot swap  code
etc. BUT you have to design them to do this from the very beginning.

    There  is  no magic  dust  that you  can  sprinkle  over a  faulty
architecture that will suddenly make it work reliably.

    In the circumstances the best you can do is run your windows apps.
on  physically separated  boxes  and "ping"  them  to see  if they  are
working -  if they fail you must  arrange to take them  out of service
and/or  restart  them. How  you  do depends  upon  the  nature of  the
applications.

    This is what "eddie" did (sort of).

    You can download eddie from http://www.eddieware.org/

> Would turning the Delphi apps into Com components and accessing them
> with Comet be any more robust than simply turning the Delphi apps into 
> http servers?  Does Comet protect the client from a crash in a Com
> component? 
> 
> 3. Any other better ways to get what we want, ie, a server that will
> allow access to Windows applications without stop or significant human
> intervention for weeks or months at a run?

   Dream on. 

   If you want reliability you will have to design it in from the start.

   You should aim at very simple "obviously correct" solutions and you should
isolate the components so that failure of one component will not effect the
rest of the system.

  /Joe 

--
Joe Armstrong,                       
Bluetail AB,                           tel:  +46 8-545 550 00
S:t Eriksgatan 44,                     fax:  +46 8-545 550 50
SE-112 32 Stockholm, Sweden            info: www.bluetail.com




More information about the erlang-questions mailing list