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?

Porbeagle

I think you're comparing apples and oranges. Akka (never used it, but just read up on it) is an actor model framework. Service bus is for durable messaging and pub/sub. Also: There's no right answer to this, as you're comparing lots of things that are subjective or project-specific: feature set, pricing, etc. I see this as an opinion-soliciting question. – Mcswain

As per this link doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html AKKA provides durability of messages using a persistent store. To me, both are providing the same infrastructure benefits if we keep the business domain separate. In actor model, the domain can exist as actors and the infrastructure benefits is also built in. In the case of Azure SB, there is no business domain. – Porbeagle

My point is that you're comparing an actor model framework with a messaging infrastructure service. They are not interchangeable, as they offer different features, one is a service with SLA, etc. And you want to know if akka is a suitable framework for use, which is an off-topic question because it's an opinion-question. If it fits your app, use it. Also, Service Bus works in Windows Server. Should you use that? Again, up to you, app-specific. – Mcswain

I use AKKA.NET which runs on Windows and going to host on Azure. The persistence aspect is what I'm struggling on. – Porbeagle

Ah - that would be a different type of question then. :) And given that akka has file system persistence, and that Azure has durable attached-disk storage both SSD- and non-SSD-based, that one could easily be answered. – Mcswain

I thought in the line of using Azure Table storage. I will post a different question on that, keeping this open to weigh in the infrastructure benefits of service bus to what AKKA.NET actor model provides. – Porbeagle

Wow, What great comments: "Akka is an apple and Azure is an orange" -- "But what is an apple and what's an orange?" -- "Well you see, an apple is an apple and an orange is an orange. so you see Akka is better than Azure because I love mangos.". – Intellectuality

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,

Petitioner

We use MassTransit on top of RabbitMQ for a similar purpose and it is wonderful. Very performant and highly scalable. – Roxie