Using Orleans with DB-per-client architecture

[lee-alexander]

We currently evaluating Orleans as a way to supplement our existing 3-tier web architecture to improve throughput and reduce the need for always reading from the database by taking advantage of in-memory grain state.

A brief overview of our existing 3-tier SOA architecture:

• Separate SQL Server database per client (on the order of hundreds of clients, each with hundreds of users)
• Middle tier consists of ~50 stateless services (ASP.NET MVC), each with 1-5 live instances at any moment
• Web front end with session state

Each service has an in-memory cache for immutable or rarely-changed data, but given that much of our data is very mutable this has limited use and is local to that particular instance of the service.

We would like to introduce Orleans in between our existing services and the database. However, the main question we need to answer is, how can we make sure each grain knows the appropriate database to talk to? In our existing services, this is accomplished through the current session information passed along with the request. Some ideas we've thought of:

• Make Client ID part of grain identifiers, and build infrastructure to make this work transparently
• Separate Orelans Silo per DB

We wanted to ask the community for thoughts and to see what the recommended approach might be, as we are still new to Orleans. Thanks!

One quick edit: We will likely not use the built in persistence functionality, instead opting for something like Entity Framework / raw SQL to work with our large existing DB schemas.

[gabikliot]

Unless you need a strong isolation between clients for security, there is no need to use silo per client.
Using client ID as part of grain ID is the better approach.

No problem with your own persistence layer. A lot of Orleans users use their own persistence layer, as it gives them more flexibility.

[veikkoeeva]

@lee-alexander Indeed, currently your choice to is to differentiate betweeen connection string (either to a different database or something like APP_NAME) or by ID. I don't think getting a hold of the silo instantiated providers is currently possible, but if it were, you could then use something like CONTEXT_INFO or other means to achieve this. The provider has internally a few interceptors that are used to pick (de)serializer, deciding whether to stream or not etc. This is the new provider that is in 1.3.0.

And indeed, as @gabikliot pointed out, it's a perfectly valid option to use application specific logic. The new provider that comes in 1.3.0 tries to be an efficient "blob storage" where on can pick between binary, JSON and XML serialization and accordingly a slot in the DB and also storage-side processing is supported. There is more in the documentation, in the SQL Server script itself and then some more design-time rationale at #1682 (comment).

[lee-alexander]

Thanks for the feedback everyone. We ended up building infrastructure to transparently attach and remove the databaseID to the grain identifier, which has been working well so far.

[sergeybykov]

@lee-alexander Can you share what you are solving with Orleans? Is it at the point that it could be added to http://dotnet.github.io/orleans/Community/Who-Is-Using-Orleans.html?