4 ms·

I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka

I've written a high-availability service with Akka.NET and RabbitMQ and I remember when I was working with that infrastructure, my biggest question around Akka Cluster was "why would I use this when I already have a message queue infrastructure?" Maybe real Akka is better than Akka.NET when it comes to Akka Cluster?

29athrowaway 6y ago
Queues overlap with the messaging aspects of actors but not the supervision aspect of actors.
- killingtime74 6y ago
  For that we have cluster management like kubernetes
  - 29athrowaway 6y ago
    An actor can fail for reasons other than infrastructure issues. i.e.: unhandled exceptions. In fact, unhandled exceptions are encouraged (i.e.: "let it crash" approach to fault tolerance).
    - t-writescode 6y ago
      Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues
      - tunesmith 6y ago
        What if you have a message that is specifically for another actor that may or may not be on the same server?
        t-writescode 6y ago
        That doesn't exist in the models I've designed. Microservices still exist and they each do their requisite task, but different work is done by different actors in the actor cluster. Actors are still a fantastic way of handling concurrency, since they can each be treated as single-threaded tiny programs that only think about themselves, and so I've used them in that way. The actor just won't exist elsewhere, but another microservice that happens to use actors might exist. It would be sent a web request or a message in queue or similar.
      - halfmatthalfcat 6y ago
        With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.
        t-writescode 6y ago
        You can have that with a queueing system, too. As long as you don't ack the message before you're done processing it, the messages that are processing will be sent to the next available client on crash
        halfmatthalfcat 6y ago
        Sure but the point is it's built into Akka. If you're looking to replace an external queue system, Akka will replace most if not all of it's functionality.
valenterry 6y ago
Akka Cluster works in-memory, RabbitMQ doesn't. Say you want to have multiple actors (one per user / customer or whatever) and you get HTTP requests and want that exactly this actor handles them (to guarantee consistency), then you can't really do this with RabbitMQ. I mean, you can make the machine that receives the request push it to the queue and keep the http connection alive, have the machine that is responsible for the user read it from a queue and then somehow tell the first machine how to respond the http request... but then you pretty much re-implemented Akka Cluster in a worse way. Persistent queues and Akka Cluster solve different usecases.
- t-writescode 6y ago
  At that point, you're still operating on a single machine, though, and you don't need Akka Cluster for that.
  - valenterry 6y ago
    I don't understand what you mean. In my scenario, multiple machines are used and necessary for the same service (otherwise there is no point in using Akka Cluster). Example: online games. You have room/game being created on the fly and it is destroyed an hour later. There are many of these rooms and they are distributed over multiple machines. You can't really use rabbitMQ here, it's not performant enough. And even if you did, you would pretty much reimplement what Akka Cluster does for you: instance synchronization, different strategies for handling split brain scenarios, dead letter handling, direct message forwarding, persistence (if needed) and so on
    - vinay_ys 6y ago
      If you want to host a game state object in memory (vs serialized and saved to SSD) because you have lots of frequent write/reads happening to that object in a very short window of time such that the IO cost and CPU cost (ser/deserialisation) is higher and the incremental latency is a blocker, then this design of hosting a full-blown object in memory within your runtime makes sense (number of reads per game object per second must be high and must be sustained for a good number of seconds for this tradeoff math to be in this design's favor, given today's SSD costs vs memory costs). But I wonder if you will suffer from random GC pauses, inability to carefully isolate different behaviors into different resource clusters, resulting in uncontrolled blast radius etc. If you are anyway doing persistence (because you care to not lose game progress), and whenever a cluster node dies you need to resurrect game state from persistence, I wonder if you will get the game state restored within a bounded latency. If this happens frequently enough (to affect say 5% of your users – enough to kill your game experience), is the benefits of latency gain from in-memory object reads wiped out?

29athrowaway 6y ago

Queues overlap with the messaging aspects of actors but not the supervision aspect of actors.

killingtime74 6y ago
For that we have cluster management like kubernetes
- 29athrowaway 6y ago
  An actor can fail for reasons other than infrastructure issues. i.e.: unhandled exceptions. In fact, unhandled exceptions are encouraged (i.e.: "let it crash" approach to fault tolerance).
  - t-writescode 6y ago
    Sure, but that’s almost entirely local within a process, where regular Akka processes would work. So, in the system I worked with, individual applications were Akka powered and cross-process/cross-vm communication was done through queues
    - tunesmith 6y ago
      What if you have a message that is specifically for another actor that may or may not be on the same server?
      - t-writescode 6y ago
        That doesn't exist in the models I've designed. Microservices still exist and they each do their requisite task, but different work is done by different actors in the actor cluster. Actors are still a fantastic way of handling concurrency, since they can each be treated as single-threaded tiny programs that only think about themselves, and so I've used them in that way. The actor just won't exist elsewhere, but another microservice that happens to use actors might exist. It would be sent a web request or a message in queue or similar.
    - halfmatthalfcat 6y ago
      With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.
      - t-writescode 6y ago
        You can have that with a queueing system, too. As long as you don't ack the message before you're done processing it, the messages that are processing will be sent to the next available client on crash
        halfmatthalfcat 6y ago
        Sure but the point is it's built into Akka. If you're looking to replace an external queue system, Akka will replace most if not all of it's functionality.

valenterry 6y ago

Akka Cluster works in-memory, RabbitMQ doesn't. Say you want to have multiple actors (one per user / customer or whatever) and you get HTTP requests and want that exactly this actor handles them (to guarantee consistency), then you can't really do this with RabbitMQ. I mean, you can make the machine that receives the request push it to the queue and keep the http connection alive, have the machine that is responsible for the user read it from a queue and then somehow tell the first machine how to respond the http request... but then you pretty much re-implemented Akka Cluster in a worse way. Persistent queues and Akka Cluster solve different usecases.

t-writescode 6y ago
At that point, you're still operating on a single machine, though, and you don't need Akka Cluster for that.
- valenterry 6y ago
  I don't understand what you mean. In my scenario, multiple machines are used and necessary for the same service (otherwise there is no point in using Akka Cluster). Example: online games. You have room/game being created on the fly and it is destroyed an hour later. There are many of these rooms and they are distributed over multiple machines. You can't really use rabbitMQ here, it's not performant enough. And even if you did, you would pretty much reimplement what Akka Cluster does for you: instance synchronization, different strategies for handling split brain scenarios, dead letter handling, direct message forwarding, persistence (if needed) and so on
  - vinay_ys 6y ago
    If you want to host a game state object in memory (vs serialized and saved to SSD) because you have lots of frequent write/reads happening to that object in a very short window of time such that the IO cost and CPU cost (ser/deserialisation) is higher and the incremental latency is a blocker, then this design of hosting a full-blown object in memory within your runtime makes sense (number of reads per game object per second must be high and must be sustained for a good number of seconds for this tradeoff math to be in this design's favor, given today's SSD costs vs memory costs). But I wonder if you will suffer from random GC pauses, inability to carefully isolate different behaviors into different resource clusters, resulting in uncontrolled blast radius etc. If you are anyway doing persistence (because you care to not lose game progress), and whenever a cluster node dies you need to resurrect game state from persistence, I wonder if you will get the game state restored within a bounded latency. If this happens frequently enough (to affect say 5% of your users – enough to kill your game experience), is the benefits of latency gain from in-memory object reads wiped out?