Orleans: Orleans and MicroServices

[sxam]

Hi,
I have a general architecture question concerning combination of Orleans and MicroServices architecture principles.
We are going for the both of them and I am not sure whether they can combined better that we currently do.
In short, our way is the following:
We have some amount of Services (around 20 or so for now). Each of them is an independent Orleans cluster (sometimes those Services share a machine but they don't know about it, their Silos are not connected). In order to communicate between those Services we use our own HTTP listeners that take the calls with REST API and pass it into the Orleans Cluster with Grain Client.
For example Service A and Service B. Service A is deployed on two machines (each one a Silo) and Service B on one machine (one Silo)

Silo 1 Silo 2 Silo 1
A A A A A - - - - - - - > B B
A A A A A B B

The main reason for that architecture is enabling independent deployment of services. That is if I want to upgrade the version of Service B, I can do that without even touching machines Service A runs on.

Silo 1 Silo 2 Silo 1 Version X
B B
B B
Silo 1 Version X + 1
A A A A A - - - - - - - > B1 B1
A A A A A B1 B1

Still, I have a feeling that we might be missing something and that Orleans should give some micro services integration on a better level, without ours HTTP listeners transferring calls from service to service (from cluster to cluster).

Is there a way to embed micro services into a single cluster and allow its independent version upgrade without shutting down the cluster, perhaps?

[sergeybykov]

@sxam This is as good as one can get today. For example, that's how Halo services are organized.

@richorama experimented with hosting REST APIs within silos via a bootstrap provider "hack" - https://github.com/OrleansContrib/OrleansHttp.

We have plans to add support for versioning and in-place upgrades with partial compatibilities between versions, which should help with upgrades, but I expect the question of service isolation and deployment will still be there - the tradeoff between isolation and efficiency/simplicity.

[geofflamrock]

@sergeybykov Would the changes discussed in #467 assist with this in the future? Allowing for cross-cluster calls to use the normal GrainClient rather than having to go over HTTP?

A REST API would probably also have it's advantages for exposing microservices outside of cross-cluster calls I imagine too, but just wondering if the non-static GrainClient would also fit into this scenario.

[sergeybykov]

@geofflamrock Non-static GrainClient could potentially fit into this picture, although we primarily considered it from the "a frontend talking to multiple clusters" perspective, not from the grain-to-grain calls between clusters one.

[rore]

@sxam we're building microservices with Orleans and using the same concept. Microservices interact via HTTP, and Orleans is basically an implementation detail of a microservice. Microservices are there for isolation on development and deployment level - so for us it doesn't make sense to host them in a single Orleans cluster. If you're going for microservices I presume you want to achieve the same goals (scaling the organization). If all you need is application level scaling, then maybe a single cluster and modeling with Actors instead of microservices is a better path.

[FenrisWolfAtMiddleEarth]

We are in a very similar situation as described by sxam.
Are there any plans to make the GrainClient non-static?

[sergeybykov]

We have https://github.com/dotnet/orleans/issues/467 for that.