Shared membership table, separate grain directories

[Timovzl]

Imagine a landscape of Orleans applications, maintained as separate solutions (perhaps even by separate teams).

Each solution could have its own storage-based grain directory, allowing its silos to track who is hosting which grain. However, the applications will want to communicate across solutions, too. Within a (.NET-based) organization, it seems to me that Orleans-based messaging is preferable over plain HTTPS. The various solutions could use NuGet packages to share their public grain interfaces with one another.

In order for silos to send messages to silos from other solutions, all silos would need to share a single, global membership table. Does this play nice with grain directories per solution?

In particular, I'm wondering about the following scenario. Application A hosts a grain of type GrainX, publically exposed as IGrainX. Application B wants to send a message to an instance of IGrainX. It certainly cannot instantiate one itself - it only knows the interface! But how does Application B know which silos do have the ability to instantiate such a grain? How does it know that it needs to contact a silo of Application A, specifically?

[JorgeCandeias]

Are you looking for the multi-clustering feature?

Note that in the context of separate ownership of each individual solution by a separate team, following this route will:

• Lock down those solutions to specific implementation technology;
• Expose each solution's internals to other solutions;

The above goes against the point of developing micro-services, if one cares about that.

[Timovzl]

Lock down those solutions to specific implementation technology

That is considered acceptable in my scenario.

Expose each solution's internals to other solutions

Please no. 😄 I propose only exposing grain interfaces that are considered public contracts, by means of NuGet packages.

Are you looking for the #7485 feature?

Reading the proposal, I would say that it is related but not the same. I'm having some difficulty in understanding its precise goal, though.

Let me try to phrase my question more clearly.

Is it possible to have each silo know all interfaces, but only some implementations? In other words, can we make it so that only specific silos can instantiate (i.e. know implementations of) certain grain types? This is like having different applications in a landscape, but they communicate via contracts. I'd prefer to avoid having to make them completely independent clusters that can only talk to each other via HTTP.

For example, we might have a Customers application and an Orders application. They all share their grain interfaces (via NuGet packages) and can talk to each other. Only silos of the Customers application know an implementation of ICustomerGrain, and only silos of the Orders application know an implementation of IOrderGrain. The two have separate remote grain directories. However, in order to be able to message each other, they use a shared, global membership table.

Does this work? Can this be made to work? The silos would have to somehow communicate to each other which grain types they are able to host. I have no idea if this is something that silos currently do.

[JorgeCandeias]

Is it possible to have each silo know all interfaces, but only some implementations? In other words, can we make it so that only specific silos can instantiate (i.e. know implementations of) certain grain types?

Yes, this is supported out of the box via having a heterogeneous cluster. A cluster becomes heterogeneous by having some silos reference some implementations and other silos reference other implementations. All silos still need to know about the interfaces.

Under the hood, silos in the cluster share a common "supported type" table, that tells which silos support which implementation. This table isn't persisted anywhere, it's propagated as needed, as silos join and leave the cluster.

Please no. 😄 I propose only exposing grain interfaces that are considered public contracts, by means of NuGet packages.

In the context of a common isolated micro-service, the grain interfaces are an implementation detail, as public communication tends to be handled via a versioned API layer. One reason is because while Orleans supports encrypted communication, it has no authentication and/or authorization features, so it cannot be secured for public exposure. Another reason is to have clear control of contract versioning with the service consumers. If you're looking to have the grain interfaces themselves as a public contract, while also having different team ownership of implementations, you may want to look at the interface versioning feature as well, otherwise you may be looking at things breaking often.

[Timovzl]

That is great news!

public communication tends to be handled via a versioned API layer

Ah, yes. I took this for granted but failed to mention it. I’m accustomed to using versioned contract interfaces in the context of remote procedure calls and the like.

I’ll definitely check out Orleans’ interface versioning.