Is AKKA trying to do in memory the same as Azure Service Bus Queue does on disk?

Question

There are many benefits that an actor model like AKKA.net bring to the table like scalability, reactiveness, in memory-caching etc... When I tried to compare AKKA with Azure Service Bus Queues, I see pretty much the same primary benefits in Azure Service Bus except the benefit of in-memory caching.

In a production environment, AKKA requires multiple VMs with more memory, processing power to handle millions of actors in memory. In the case of Azure Service Bus Queues, powerful hosts are not needed. Even if we use actor model, there is no need of doing supervision or creating the actor system to manage millions of actors. The scalability is automatic with Azure Service Bus.

In a long run, I think Azure Service Bus Queues is cost effective. There is no IT admin required to manage it as the load increases. There is no need of powerful systems too with multiple cores.

Is AKKA actor model suitable for on-premises data centers that have systems with multi-cores and not suitable for apps that can use Azure services when thinking in terms of cost-effectiveness?

Answer 1

I would say that the mailbox component of Akka.net does a job that is similar to the one that Azure Service Bus Queues (or MSMQ for that fact) is perhaps similar in principle. Where a Service Bus Queue (or MSMQ) will persist (or in the case of MSMQ, a persistent queue - not a memory queue) the messages to storage and Akka's mailbox out of the box will not.

But that is where the similarities end... Service Bus has no concept of Actors, processors, distribution - it is only a messaging solution.

If you are looking to implement actors where perhaps persistent (and transactional "actors") are the goal then I would suggest that you not use Akka.net but instead either MassTransit or nServiceBus. Both are very capable products and while their performance won't equal Akka.net (MT and nSB serialize and persists to disk, Akka.net doesn't) they are very capable and sturdy and will recover transparently when an Actor/Node crashes as the whole work item will be in a transaction which will cause the message to be reinserted/reprocessed as a default behavior.

I have long looked at Azure Table Storage as a good Event Store, but I would use a service bus (MassTransit, nServiceBus) instead if you wish to keep a record of commands as for me this feels like you have needs that are more "transactional" as "near-realtime" and "multiprocessor" in nature.

My personal opinion,