MMO server side help

I think you're going in the wrong direction designing a framework around percieved "needs". Without any knowledge of MMO server design, how could you possibly know what such a framework requires? You might think that service A is going to be using a lot of CPU time, so you decide to distribute it. During actual testing for an actual game it turns out that the main bottleneck was service B; distributing service A turned out to be a complete waste of time.

This case is, in my opinion, a perfect example of why you should write games, not engines. Learning by doing is a great idea - just don't go down the framework/engine road until you've got some experience making the kind of games that you would use your framework for.

EDIT: Adding to that, bear in mind that the Ryzom engine was written to satisfy needs specific to that game. The fact that Ryzom's server distrbutes load between machines in a particular way, and runs a particular set of services, doesn't mean that approach is suitable for a framework (which one can expect to adapt to many game types).

OK, I agree with what you are saying, and thank you for the link. I have read over and over on how people underestimate and rush the process, so I cannot stress how much I understand there are many wrong paths to take. I think I posed the wrong question, what I had intended to ask is if learning the design of Ryzom would be a good way to learn server side architecture of a framework, not necessarily designed for my needs. I could see how logging, admin, persistent storage etc is implemented for that particular example.

thank you for your patience

When projects don't have infrastructure to support the needs, projects suffer. This may often be blamed on "rushing the process" -- but, really, once you realize there is a need (and you should be looking for anything that impedes progress all the time), the right thing to do is to start dedicating resources on support frameworks.

Building a support framework without knowing what you want to support is not a good idea, because, best case, you'll end up writing a bunch of code that doesn't get used, and worst case, you'll make some fundamental assumptions that end up getting in the way of real deployments.

So, infrastructure is paramount, but you shouldn't write it until you have a clear need. And the good thing about the clear need is that the need will prove that you're solving the problem by being fulfilled!