3 ms·
Oh! Actors is one of my favorite paradigms of lately. I have been reading plenty about Akka as well. When I start looking into the subject further, I start fal
by Nican 6y ago
Oh! Actors is one of my favorite paradigms of lately. I have been reading plenty about Akka as well.
When I start looking into the subject further, I start falling into a rabbit hole of how Actors are sometimes treated as a database, that is hard to query, and provides no transaction-ability across actors. There is some argument that Actors could be reimplemented using Postgres' "SELECT ... FOR UPDATE", since you can lock the row for the duration of the transaction.
Anyone else have experience managing large amounts of data inside of Actors have a say about this?
- halfmatthalfcat 6y agoI use Akka extensively and have not heard (and would never) use Actors in that capacity.
- dmux 6y agoYou have to walk a fine line with Akka IMHO. Having inherited and supported an Akka Cluster for 4+ years, I'd strongly recommend that you evaluate whether you really need an Actor based system or if a plain-old set of services talking to each other via a message-broker would suffice. The particular system my team inherited gave us nothing but issues: cluster coordination issues, so quorum wasn't met and things wouldn't start cleanly, network partitioning issues so nodes would randomly be considered dead, actors "becoming" (the term used IIRC) other types of actors based on messages received... the whole thing was just.. too ephemeral and organic for our tastes. I used to get excited thinking about systems like that, but I've since grown more conservative in my technology / architectural preferences (i.e. choose boring technology). We actually ended up replacing it with exactly what I suggested: a plain-old set of services talking via a message-broker. It's stupid simple and we've all slept better. Edit: I will say that the use of actors constrained to a single service to handle concurrency is probably way more supportable than in a clustered mode.
- fearthetelomere 6y agoWith something like Elixir/Erlang, the distributed system is quite robust and reliable from my experience. A bit rigid and somewhat difficult to configure for custom topologies, but dependable overall. >a plain-old set of services talking via a message-broker That said, I think you're absolutely right with distributed Akka. I'm very hesitant to fully embrace it, and we use simple service-level APIs to communicate between nodes. I understand the developers have made a lot of progress on the functionality of remote Akka over the years, but it's just not as tried and true as I would like. Using Aeron for message transport for example, is something that may be the best tool available, but is really hard to sell to my org when simple services are more approachable and maintainable. >actors "becoming" (the term used IIRC) other types of actors based on messages received Yeah... I didn't understand why my org was using the Classic Akka instead of the new and improved Typed Akka for a long time. But cool-looking things like this just aren't worth it sometimes. Especially when Classic Akka "just works".
- kag0 6y agoI don't have experience with managing large amounts of data with actors. But I can say from the actor experience I do have that you can't think about it in the mindset of "how can I replace my relational database with actors". Actors can be a near-sliver bullet for some things, but you have to think about solutions differently. I always though a bank was a good example. One actor per-account, how do you think about money in flight and such? Probably in a fundamentally different way than you would in postgres. > hard to query That one is easy though, CQRS