Migrating / integrating existing applications

[markusschaber]

We just stumbled across Akka.NET by chance, and it looks like it has well-designed solutions for some problems with concurrency and state machines we face in our software, so we're giving it a closer look.

Are there any guidelines or examples for (or success stories of) piece-by-piece migration of existing systems into Akka.NET, integrating with existing code and infrastrukture like:

1. ASP.NET / Kestrel web API
2. Dependency injection via Microsoft.Extensions.DependencyInjection
3. ASP.NET Core Webhost / hosted service model
4. EF Core / PostgreSQL for the database
5. existing WebSocket protocols spoken by clients and other external communication partners
6. Running in kubernetes (local and cloud)
7. etc?

We cannot completely rewrite all the software at once, but we're planning some architectural refactoring/restructuring anyways, and (if we decide to use Akka) we would like use salami tactics to first migrate the pieces with the highest strain, and then later replace other homegrown parts of infrastructure.

(I first asked this on the Akka.NET Gitter channel, where it was suggested I move this to a discussion here.)

[jason-field]

Hi Mark. A great set of questions.

As background I've been using Akka.Net for over 5 years in production settings, non-clustered deployments, but high throughput. E.g. For example, Digital inventory solutions, integration to WMS (Warehouse Management Systems) and SMS gateways for corporate clients. In most cases these were not greenfield implementations but needed to be integrated into existing code bases - it wasn't a big bang rewrite. These are some of the lessons I've learned along the way from an integration perspective:

Identify the parts of your application that will benefit the most from fault tolerance and/or throughput. These will normally be integration components that the business cannot afford to fail. This is where Akka.NET will shine - with its in built fault tolerance and routing topologies that it can be designed around.

Look to define how you will measure the benefit it will bring - i.e. if It lowers support costs, then you need a baseline to compare against. Once you've done one migration it becomes easier to then use the same approach with other parts of the application, with respect to getting senior stakeholder buy in. i.e. You proved it works, reliably and it had a bottom line positive impact to the business (whatever their measure is for success).

The key I've found in terms of migration is to identify clear boundaries for migration - identify a small subsystem to start with that provides significant benefits to the business in terms of operating cost, reliability, throughput, (what their metrics for success are).

Build a facade around those parts of the the application that keep the rest of the system using the traditional Request/request programming model. Within your facade, translate these RPC type calls to message based calls that you send to your actor subsystem. This works very well where you want to process data without needing immediate feedback to the calling application (or components). For example, I needed to push sales orders to one or more WMS systems. The data to be sent was already in a database but needed to be exported reliably, and could load balance itself when sales order volumes spiked (based on time of day, campaigns, etc).

Some of the integration use cases I've used:

1. Poll based querying off a digital inventory order database to identify sales orders that could be be exported to one or more WMS. I used EF to query against the database to build up messages of sales orders to be exported. These sales orders were exported using pools of load balanced HTTP clients for multiple WMS endpoints. The system was fault tolerant and would only update the underlying database record as sent, once an acknowledgement had been processed from the remote WMS systems that the sales order had been secured on their end. It could also throttle itself back if the HTPP clients encountered a significant number of errors in a short time. E.g. the remote WMS endpoint was changed without us being notified.
2. Sending thousands of SMS messages a minute to remote SMS gateways, in a reliable, fault tolerant manner. Load balanced and also throttled sending.

On a more technical integration perspective:
For Dependency injection. I've used Autofac, Microsoft DI, and DryIoC.

For parts of your actor hierarchy that must be as fast as possible, don't use DI. There is an overhead with using it. Generally I switched from Autofac to DryIoC in order to improve message processing throughput. Where I had to use DI, DryIoc allowed me to get a 10x performance improvement over Autofac. Even with DryIoC, I had to redesign the small number of actors that needed to be as fast as possible, to not have any DI dependency to get the throughput I was after.

With regards to EF, I follow a loader model for retrieving data, where the actor in question has the responsibility to load the records and transform them into a single aggregate message or into individual messages. It is triggered to load by an incoming command message and then Tells() an interested actor(s) of the discovered data using either a command or notification message. There is plenty of documentation around the patterns best used for this type of approach on the akka.net website.

I use Akka.Net with Azure Service Bus (Along with manual acknowledgement models) without any real issues. High throughout and reliable (at least once message delivery pattern).

Hope this helps.
Regards,
Jason.

[Aaronontheweb]

This is a great and thorough answer.

[Aaronontheweb]

For integrating with ASP.NET Core and DI, I put together some blog posts and YouTube videos on this earlier this year:

• Best Practices for Integrating Akka.NET with ASP.NET Core and SignalR
• How to Build Headless Akka.NET Services with IHostedService
• Akka.NET Dependency Injection Best Practices