31–40 of 287 posts
Earlier quoted context omitted.
the actor model isn't erlangs, it's actually a surprisingly old idea ( 1973 ). The virtual actor model is an interesting spin on the idea that simplifies a few things. Orleans itself is quite nice, I've used it a few times on some smallish things. Looking at using it in anger for a large distributed backend system in the nearish future.
"Looking at using it in anger..." Orleans DDoS?
Earlier quoted context omitted.
the actor model isn't erlangs, it's actually a surprisingly old idea ( 1973 ). The virtual actor model is an interesting spin on the idea that simplifies a few things. Orleans itself is quite nice, I've used it a few times on some smallish things. Looking at using it in anger for a large distributed backend system in the nearish future.
"Looking at using it in anger..." Orleans DDoS?
I'm a core developer on Orleans. Feel free to ask any questions here, or on gitter: https://gitter.im/dotnet/orleans I gave a talk recently on how we use it at Microsoft: https://www.youtube.com/watch?v=KhgYlvGLv9c - the talk is very short and so it does not go into many details, but it gives an overview of some internal use cases.
I really enjoyed the simplistic development model of Orleans compared to SF, and I want to give streams a second chance on a personal project, but I'm concerned that both Orleans and SF RA will be superseded by SF Mesh - do you have any thoughts on this?
I'm a core developer on Orleans. Feel free to ask any questions here, or on gitter: https://gitter.im/dotnet/orleans I gave a talk recently on how we use it at Microsoft: https://www.youtube.com/watch?v=KhgYlvGLv9c - the talk is very short and so it does not go into many details, but it gives an overview of some internal use cases.
I spent a fair amount of time doing a POC on Orleans but ultimately went with SF Reliable Actors due to some issues I couldn't resolve with a custom Streams implementation (Kafka subscriber/publisher). I really enjoyed the simplistic development model of Orleans compared to SF, and I want to give streams a second chance on a personal project, but I'm concerned that both Orleans and SF RA will be superseded by SF Mesh…
How does it compare to Akka?
With Akka you manage objects actively, much like memory in C, with Orleans your objects behave much like normal Dotnet/Java objects, they are just distributed and must use async methods. Orleans adds a layer of management, where it will tear down and re-instantiate objects as required, distributes them in the cluster, etc. As a programmer you don't have to worry about it, it's all managed by the runtime.
Earlier quoted context omitted.
That sounds similar in concept, yeah. The brilliance of Orleans was doing it without introducing a new way of coding.
Yeah, same with Cadence/Temporal. The one caveat is that you have to move all observable effects into activities so that they can be cached. Under the hood, the engine replays functions to rehydrate them, if necessary.
> It was created by Microsoft Research and introduced the Virtual Actor Model as a novel approach to building a new generation of distributed systems for the Cloud era. Okay, sounds like an academic, Microsofty take on Erlang's Actors? But from docs, sounds like it's at least used in practice at MSFT: > Since 2011, it has been used extensively in the cloud and on premises by several Microsoft product groups, most not…
Major differences:
- Normal actors are pretty flexible, can work in local or remote contexts. Orleans is probably best described as Sharded Actors, It's a 'guided' implementation of Actors compared to Erlang or Akka where you are given a toolkit and have to build out what you intend to do.
- Orleans doesn't have any ordering guarantees. While this is not a firm requirement of the Actor model itself, both Erlang and Akka guarantee ordering between a given Sender-receiver pair (i.e. messages sent from A to C will be sent in order)
- Akka and Erlang have the concept of Supervision. i.e. An actor may have a child, and if that child crashes, the (parent) is notified and may choose how to react (restart child, don't restart child, crash itself)
- Orleans may allow more than one activation of the same grain at the same time. A stable and properly configured Akka Shard cluster will never have more than one of the same entity actor alive at a time.
- Orleans can magically scale out with the cloud (If you're running them on Azure.) Erlang/Akka you'll have to deploy your new nodes.
So it was quite an eye opener to read about how Orleans introduced Virtual Actors, activations and placements of actors and how these are exactly the things I've thought about over the years. I've read about e.g. the classic Erlang actors, but the concept of virtual actors in Orleans really fit my model.
I'll be sticking with Python, but starting with the Orleans paper has lead me to quite a few similar systems: https://www.researchgate.net/publication/233416056_Orleans_C... that reference it.
Earlier quoted context omitted.
Distributed applications
There are a couple of types of distributed applications though, right? There's the traditional client/server scenario where you distribute the load horizontally across many servers. If most of the server computation is stateless, and all the state is stored in the database, then you can use either the FaaS or the actor model. Then there's the client/server scenario where the server computation is stateful, in which c…