Orleans for a single node on-premise "IoT" application

[swimmesberger]

I'm currently evaluating Orleans for a on-premise "IoT" application that will be single node most of the time but could be clustered (on-premise in LAN) for larger customers. The grain concept would be perfect for our use-case. It would be very easy for us to model the use-case in terms of grains in code (think as: Digital Twins of real hardware).
Because Orleans was primarily developed for the cloud I see following obstacles:

• What is the performance of grains in the same silo? How big is the orleans tax in such a scenario?
• Can clustering be disabled completely? Disabling clustering could enable some optimizations?
• Activation Garbage Collection - In the single node scenario we do not really have a use for grain garbage collection. I would prefer to keep most grains simply in memory and disabling grain collection in the single node scenario. Is this possible?
  • We do not have a every growing number of devices. We have a fixed number of devices that is known in advance for most scenarios. Although some device grains are spawned lazily on-demand but we do not have a need for despawning them

I'm also evaluating Akka.net, it seems to be a better fit for the single node on-premise scenario but it is also a more low-level actor system that would work but I very much prefer the high-level approach Orleans is taking.

I'm happy for all kind of input regarding this topic 😊

[Nacho-Neko]

How to handle “IoT” application that do not have a public IP address and cannot use service discovery or be actively invoked by nodes?

[jeremylcarter]

This is an old question, but I have used Orleans for large-scale on-premise IoT projects. From my experience when reasoning about the features required for Digital Twins, the most important things are state storage, pubsub, and timers/reminders. Orleans has these features (and more).

For any future readers, I wouldn't be concerned about performance or clustering right now but rather get the developer ergonomics right for writing and structuring your Digital Twin grains. What I mean is to focus on modeling clarity: how you define grain identity, state boundaries, lifecycle, and invariants, and how naturally your domain maps to grain interactions.