AKKA.NET in ASP.NET or in console app?

Question

I'm trying to integrate AKKA in a IoT application built using ASP.NET Core on framework net46. I'm trying to find the best approach and would appreciate any comments on this question, although it is a bit long. Both comments based on experience with AKKA in Java and AKKA.NET will be relevant.

In short, I need AKKA.NET to receive IoT-messages from remote devices and perform fairly complex processing logic.

For the IoT-communication we use the Azure IoT-hub. The IoT-messages are consumed by a multithreaded console-application following the guidelines from Microsoft here:

https://azure.microsoft.com/da-dk/documentation/articles/iot-hub-csharp-csharp-process-d2c/

At the same time we are running a standard ASP.NET Core (framework net46) application using dependency injection and all the latest best practices.

I need AKKA.NET to take over part of the processing going on inside the IOT consumer application and also part of the processing going on inside the ASP.NET application.

I see the following three solutions and I'm curious which would be recommended by more experienced AKKA-developers. My own guts feeling is that solution 1 is the preferred, see below for my own arguments:

• Solution 1: Create a new Console application based on AKKA.NET and use AKKA.Remoting to communicate with the ASP.NET application and the IoT consumer application. This means that all the actor logic will be encapsulated within an isolated console application. Of course AKKA.NET will also be referenced and utilized within the ASP.NET application and the IoT consumer application, but only for sending remote messages.

• Solution 2: Use AKKA.NET directly within the ASP.NET application and use AKKA.Remoting to communicate with the Iot consumer application. This means that the ASP.NET application will be extended with Actor logic side-by-side with existing traditional ASP.NET logic based on controllers, await/asynch etc.

• Solution 3: The opposite of solution 2, that is, use AKKA.NET directly within the IoT consumer application and use AKKA.Remoting to communicate with the ASP.NET application.

There might be more variations such as integrating AKKA.NET logic inside both the ASP.NET and the IoT consumer application but I don't like the idea of having actors running in different applications, at least not in this early phase where I'm trying to establish a clean new actor-based implementation.

Here are my arguments for solution 1:

• I have been told that AKKA.NET is able to utilize all cores in the best possible manner without context switches if configured correctly. To be able to analyze and optimize the configuration, I prefer to have the simplest possible runtime environment for the AKKA.NET application logic. Having the AKKA.NET running inside a web-container or inside a console application already utilizing threads and locks, doesn't seem very simple as compared to a raw console application running nothing else than my AKKA.NET actors.

• As the actor based logic in C# is fundamentally differently (and slightly more convoluted) than ordinary procedural/functional programming, I like to encapsulate it in a seperate project using existing application projects as dependencies. In this way I hope the code will be easier to understand later on.

• I plan to run scheduled actors to take over cron-based processing. Doing this inside my ASP.NET application seems fragile as the application might be taken to sleep by the infrastructure.

• If at some point I want to scale up the actor-based processing it seems easier and more transparent to scale up using a pure console application that only runs actors than scaling up either ASP.NET application nodes or scaling up my IoT consumer application (which might not even be possible without introducing subtle errors).

Answer 1

My preference is always for something like option 1 - keep the actor systems running inside ASP.NET razor-thin so the web application is still mostly "just" a web application. Let your real actors run in a Topshelf service that receives input via Akka.Remote from the ASP.NET application.

I've used this setup in production at significant scale with great success for a mobile analytics and marketing automation SaaS application: http://www.aaronstannard.com/markedup-akkadotnet/

Reason why I like this? I can deploy changes to either service independently of each other and I can tailor my Topshelf service to handle things like Chron jobs without coupling it to ASP.NET deployments. It's a great way to loosely couple things.