Thanks for this question as I'm curious as well. I came upon this article from IBM https://developer.ibm.com/technologies/messaging/articles/difference-between-events-and-messages but it still does not answer how it will be with Orleans since Orleans can do streams and messages.

In an ESB solution, I'm able to throttle the number of processors/components depending on the client quite naturally. I suppose this can be accomplished by creating a dispatcher grain which then can limit the number of processor grains (e.g. GrainFactory<Processor>(0...9) to limit up to 10 simultaneous processors). But I'm curious as to how this should be correctly done in Orleans. The dispatcher ->processor grains seem to add complexity just to accommodate this throttling scenario.

Since there is broad interest in the question, I copy and paste a brief exchange that took place on gitter, it helps progress the discussion in the spirit of @drakeforte5 's message, however it doesn't really answer the question so hopefully a member of the core team can shim in to provide us an authoritative answer.

Gitter discussion

@oising Look at it from the other direction: What are the purposes of an enterprise service bus? One of the benefits is to allow you to swap out/re-route participants on the bus without disturbing the other participants, right? If you had all the grains for the entire company in a big project, running on a single cluster -- that isn't possible anymore, right? You've just create a single point of failure. If the cluster falls over, none of your company's systems work. With an ESB, One app dying doesn't affect the rest; and even if the ESB itself dies, in theory the other apps will run offline from it. Different scenarios.

@nkosi23 Thanks a lot for your insights @oising , you make great points that I probably hadn't considered enough. My thinking is: when looking at the various failure modes in detail, is a separate ESB truly superior:

• Orleans is quite sophisticated to handle routing and grain placement dynamically and automatically - even stream subscriptions can be modified at runtime
• Since we are talking about applications that would rely on Orleans for their core business logic, if the Orleans cluster fails the app would not work anyway
• With Orleans if one app dies, the others are not impacted if Streams are used (but the programmer may intentionally decide to couple two applications by directly referencing and calling a Grain from another app - for example to implement a distributed transaction on a critical path where it makes business sense)
• This last point makes me think that Orleans could actually be a sort of augmented ESB enabling developers to opt into richer features where needed (at the cost of coupling systems)
• In light of what you have said, I feel the only place where using Orleans would actually introduce a new failure mode compared to a traditional ESB, is if an application developer does something dumb in a grain (like a long-running blocking operation) and the performance of the whole cluster is degraded because of that. This is comparatively much more difficult to achieve with an ESB since all one can do is pass dumb messages to it.
• But one may also put this last point in the "benefits" column, since Orleans comes with powerful monitoring tools, so this would remove the need to deploy additional monitoring tools.

I am only talking about the scenario where one is interconnecting independent applications being each it fully developed using .NET and Orleans for their core business logic

For me the question is what you mean with "independent products". If independent means:

1. Independent teams.
2. Independent deployments.
3. Independent technology stacks.
4. Independent scalability requirements.
5. Independent infrastructure.

Then I would use another solution.

Orleans is great for low level messaging and distribution of work, but for typical high level messages / events I would something like kafka or RabbitMQ to establish a communication between independent services.

From what I'm digesting at this point is use Grains in a bounded context. Bounded context might mean an app. Once data/events get out of this bounded context and shared across apps (enterprise level at this point) then Streams would be ideal solution since the producer/consumer are decoupled (provided that consumers are also in Orleans). Am I on point? Thanks.

@SebastianStehle Thanks for your input, in my case I am talking about:

• independent teams (except that teams do communicate and can coordinate for example to use an in-house development methodology/framework)
• independent deployments
• independent scalability requirements
• independent infrastructure to a certain extent (hosted on the same data centers using the same environments and strategy)

@drakeforte5 This exactly the question i was writing as you posted! I am wondering what makes @SebastianStehle consider that Orleans Streams wouldn't be suited for cross-bounded context scenarios (especially since Orleans allows to plug in external stream providers like Kafka and RabbitMQ where needed).

The idea is not to advocate for Orleans at all cost but to learn more about best practices, and intended usage, and how far we can push Orleans and rely on it to build our enterprise infrastructure.

Orleans is a framework to create scalable distributed applications based on actor-model programing. In my opinion it not only don't provide any independency for your teams but also it could tight couple your teams since they have to share some part of source codes like Interfaces with each other.
If all 5 independent product gonna scale their services base on actor-model then using Orleans and it's streams for message-based communication could be good choice but if actor-model is not part of your products then I think there are better tools for a loosely-coupled messaging-base communication like MassTransit

Thanks for your input @zeinali0, and for the reference to MassTransit. As previously highlighted this thread is specifically about the case where each independent product is already heavily using Orleans because it is a good fit for the application (and generally speaking, the company builds all their product with Orleans).

Like others in this thread you are essentially saying "pick the right tool for the right job", but the point of this topic is precisely to determine if and how Orleans could turn out to be an excellent tool under the aforementioned scenario.

To avoid going circle, I feel what we really need at this stage of the discussion is to have a member of the core team or someone who did something similar with Orleans to shim in and comment on best practices, and intended usage, and how far we can push Orleans and rely on it to build our enterprise infrastructure in light of the scenario described in the previous posts.

I am not advocating against Orleans. It is a great tool. But when I would be the enterprise architect I would just think about the services as boxes and would not care about the implementation details.

Then the question is for me: How can I establish a communication between these 5 services and be prepared that I might have 10 more services in 3 other programming languages in the future.

Then I have questions like:

1. What kind of messages do we have?
2. Can we group the messages into categories and how to build streams and topics?
3. What is an well established message format that is understood by everybody? Json? Avro? Protobuf?
4. How can I format my message with backwards compatibility and versioning in mind?
5. Is the enterprise bus capable of storing messages and how long do we need them to be persisted?
6. Do we need an extra service to backup the messages?
7. How can we document the different messages? Json schema? Avro? Protobuf file? Xml schema? Plain text?

If you can connect streams to your enterprise bus it is a great solution, but you should not drive architectural decisions from the tools you have available at the moment and you would use at the moment.

I have experienced it many times that a big shifts were made in the implementation. From C# to Java or the other way. Especially in micro service architecture and when some frameworks are only available for one framework. Therefore it is very important to be as independent as possible.

If you use streams with kafka, then streams is just like a kafka client and there is no need that your five products are in the same cluster, because you only communicate over kafka. The question whether you use Orleans or not is then irrelevant.

@SebastianStehle just to clarify one minor point, I didn't imply that you advocated against Orleans. This remark wasn't targeting you, it was actually targeting myself 😄 . Since I am insisting on having a discussion going on the specifics of Orleans for this use case, I just wanted to clarify that my goal is not to advocate for Orleans at all cost, I am just trying to keep the discussion on track. Anyway, thanks a lot for these very helpful and relevant insights, I totally agree with you.

What I am trying to do here is think about the many companies (including ours) who in practice develop all their products using .NET. I am trying to assess how far the Orleans idea can be taken to simplify the enterprise architecture of companies being exclusively invested in .NET in an innovative manner.

This is in the spirit of: is there really a point in using an abstract repository pattern allowing you to swap the underlying data store you use, if you perfectly know that you are only ever going to use a SQL database, and that you never modify the kind of data store used by your applications in practice. Say we were having this discussion in the context of EntityFramework, then the topic of this thread would have been: considering the many features of EF (both providing an ORM, and allowing to call stored procedures directly and to have fine grained performance tuning strategies for different kind of queries), would it be viable to directly reference the DbContext API instead of building an additional repository abstraction on top of it, both to simplify architecture, and to keep the powerful features of EF in hand where needed.

In this kind of discussions, while general architectural insights are relevant, and needed and truly add to the discussion, I am trying to keep the discussion mainly focused on the possibilities enabled by the specific characteristics of EF (here Orleans) for companies having a specific scenario/use case.