concurrent users is the issue here, besides if the app was a very simple one, then the ram required for 50 concurrent users as opposed to 50 concurrent users of a complex app would be very different.
I think its safe to agree that the technology used in awareim is scaleable and if the need arises, one can scale by adding more servers. The question is at what time do you scale out as opposed to scaling up.
My view is, start out with one really powerful machine that will let you scale up by adding more ram until a threshold of either ram limitation or processing power is reached that forces you to start scaling out to more machines/servers
In my mind the only way to establish the ram requirements is to monitor the ram usage and then adjust ram settings up or down based on the expected activity of the system providing you leave enough head room to start out with. If your app is behaving (because it's been optimised from a design perspective) then you should be able to see a level of ram usage consistency based on users activity.
The other ram requirement is, of course, the database. They say you should always set the ram size of the DB to the actual size of the database. So once you have awareim ram settings in place then allocate all available ram to the database (That's what we do and we find the ram requirements of the awareim servers drops down considerably- so this is another factor)
I think most of what I have said here you know already, the question you are really asking is just who is out their running serious production apps on the back of AwareiM - it would be very interesting to know about some of these apps because it gives you confidence on the platform you have chosen.
The one thing I can tell you, one particular app that we do is highly complex and runs many real-time processes in the organisation, so much so that if the server goes down the organisation cannot trade, its like the lights have gone out - Some of these processes interface with external devices on the client side, these processes are initiated by the app and results are fed back to the server via a routing mechanism we have developed. I can't tell you much more about the app other than to say that the server goes about its day with little downtime running smoothly in the background. We took a chance on the platform and its working very nicely for us - anything we throw it at from a design point of working works out in the end . So while we don't have hundreds of users on the system there are lots and lots of intense background processes happening(thanks to the rules engine) which gives us a high degree of confidence about scaling to many more users
