Clustering

[ncthbrt]

One of the major benefits of actor systems is location transparency; being able to communicate with remote actors in the same way as local actors is an important feature of this

This feature could be as basic as having some means to allow actors to communicate when IP addresses are explicitly provided, or it could also include scheduling (deciding where actors should be put) and clustering.

Another important question is how to ensure that this architecture is flexible enough to support different kinds of transports, while selecting some sane, easy to setup defaults.

[adieuadieu]

Hi There. I'm new to nact and the actor model in general, and so please pardon the naivety in my thinking: While I don't really have any particular problem I'm trying to solve with the actor model, and have only recently stumbled on to nact, I'm a fan of "event-based" computing with services like AWS Lambda, or Google Cloud Functions. Latency would be somewhat poor, but could you imagine an interesting use case where each remote actor is an AWS Lambda function?

[ncthbrt]

@adieuadieu: That is a possibility. One of the important ideas behind actors is that communication is location transparent. This means that it shouldn't matter whether the actor is located on a dedicated server, a cloud hosted VM or even on a lamda function: all communication uses the same interface. Obviously there is a lot of work need still to get to that point, but in theory you could have a HTTP transport which could trigger a lambda function.

That being said (keeping in mind that this is the personal opinion of someone who hasn't used them in production, so feel to correct me), while I like the idea of lamda functions, I do have a few problems with them, especially when considering them as the computational strata for an actor system:

• They don't seem to provide a mechanism for encapsulation.
• How does one perform composition?
• As you mentioned Lamdas would likely experience latency problems due to cold starts. Especially if you use the persistence framework which has to replay the events which were saved since the last snapshot.
• Statelessness is at once both lamda's strength and weakness. There are a lot of interesting things you can do if you start to exploit the advantages afforded by stateful computation (think fine grained caching, in-memory DBs, distributed worker pools, etc). nact attempts to provide an abstraction layer which makes using state both a safe and reasonable option.
• I've been experimenting with how clustering/remoting would look like. Based on these experiments, I suspect that lamda functions will probably be a little redundant once that feature is completed. Compute is already thinly sliced when using the framework, and clustering with dynamic membership would enable the use of auto-scaling, so the cost and elasticity advantages of lamdas would become less compelling.

More broadly, I've been thinking quite a bit about what it would to take to offer actors as a service. In theory it should be possible and would be a more general computing framework than lamda is. That would be a very long term goal; perhaps then it'd make sense to use lamdas, but not sure.

[ncthbrt]

Just a general update, I've started experimenting with the clustering interface, and I've come up with this (for reasonml), the js version should look fairly similar:

module Cluster: {
  type keySelector('msg) = 'msg => int;
  type routingStrategy('msg) =
    | Sharded(keySelector('msg));
  let createCluster: (~name: string, routingStrategy('msg)) => (actorRef('msg), clusterRef('msg));
  let join: (clusterRef('msg), actorRef('msg)) => unit;
  let leave: (clusterRef('msg), actorRef('msg)) => unit;
  module Operators: {
    let (+@): (clusterRef('msg), actorRef('msg)) => unit;
    let (-@): (clusterRef('msg), actorRef('msg)) => unit;
  };
};