views:

221

answers:

2

I would like to design very high availability(never take server down, roll out features without restart etc) application with both client(probably C# gui) and server components(Java,C++,Perl).

I got some advice from (minimize-code-maximize-data.html and Yegge), and I would like to make most logic dynamically readable from database so that all configuration(including all GUI configurations, text translations etc, business rules as well as data) would reside on the server in a database rather than in a code that requires restart to be read into executable memory.

I would like to be able to customize any aspect of the application without restarting either client or server and have application reflect changes with as short lag as possible(dynamic class loading etc).

What are the performance and other limitations of designing such a "never kill" system? Has anybody managed to create such an application? What were the main lesson learned? When is this not cost effective and more traditional build, release, qa, couple hrs downtime approaches are required?

+3  A: 

I worked on a MUD game server that did dynamic compilation of scripts, such that almost anything in the game was changeable and recompileable at runtime without having to disconnect any users.

Perhaps the biggest lesson I learned from that project was that when you write code so flexible such that it can do anything, it effectively does nothing.

Ultimately, users of the system were no longer entering data -- they were writing a cryptic sort of code language that was unique to my system.

Be wary of flexibility -- adding flexibility to code is like adding elbows in an arm. It's good to have a couple of joints to get where you want to be, but if you have too many elbows, it becomes weak and hard to direct.

HanClinto
Regarding "users of the system were no longer entering data -- they were writing a cryptic sort of code language".This application would not the users do the editing of program logic or look and feel, this would still be done by me or other technical staff. Idea would be to eliminate heavy roll-out
Ville M
Good point -- I guess I counted admins as "users" too.Essentially, I realized that I had introduced a layer of abstraction that was too flexible. I think that this always-up server was a good idea, but the main problem in my instance was that it was too generic. Do one thing, and do it well.
HanClinto
+1  A: 

Something not all too different to consider is using a heavily static and small code base around a script interpreter, like Rhino:

http://www.mozilla.org/rhino/ScriptingJava.html

That way all the logic and data can be put into reloadable scripts and the only core part of the program is the script runner and shell-like part.

This is definitely bad for performance, I think that is a given.

If I remember correctly, Yegge posted something similar once in his blog, so if you get to talk to him again, might ask him about that.

Josh