We’re kicking off 2025 with a fresh look at Akka.NET and what we have planned for our next big release: Akka.NET v1.6!

Akka.NET v1.6: a Performance-Focused Release

As it says in our promo image here - Akka.NET v1.6 is a performance-focused release. To that end, we’re addressing the following three major changes:

Ahead-of-Time (AOT) Compilation Support

One of the major advantages of Akka.NET over something like Orleans, NServiceBus, and most of the other messaging / actors / concurrency solutions in the .NET space is its ability to scale down to support “edge” workloads on local devices like phones, tablets, PCs, or even embedded systems.

However, in order to fully thrive in these spaces we need to support AOT compilation, because in many of these cases it’s preferable to distribute .NET applications without having to include the .NET platform.

We’ve already broken ground on this feature in the v1.6 branch of Akka.NET and are making steady progress on getting our “AOT Canary” to pass for the core Akka.NET library.

You can track our progress on AOT for Akka.NET here: “Epic: Full AOT Support for Akka.NET”

Code-Generated Serialization

There are two major performance issues that affect Akka.NET’s network latency:

1. Using a single TCP socket in remoting - which leads of head-of-line blocking and other performance issues;
2. Using 2013-15 style serialization: working with byte[], allowing every serializer to have its own idea on how to allocate memory, reflection, and lots of redundant copying for envelope types.

We aim to address both of these issues in Akka.NET v1.6.

Let’s start with serialization - the best practices for high performance serialization in Akka.NET today involve writing your own Google Protobuf schemas for messages, mapping them onto your own C# or F# types, and then writing a custom SerializerWithStringManifest class in Akka.NET.

This process is extremely tedious even though it’s more performant / secure / versionable than the alternative: using reflection-based polymorphic serialization ala JSON or Hyperion.

So we’re going to strike a compromise in v1.6: source-generated serialization. This approach is already used in applications like ASP.NET Core AOT compilation and has support from the Roslyn Compiler Platform for .NET.

This feature set will be opt-in - so you don’t have to use it if you don’t want to. It will also be backwards-compatible with existing Akka.NET serialization today so previously persisted data in Akka.Persistence is still fully retreivable and accessible.

You can track our progress on this issue for Akka.NET here: “Epic: Source-Generated Serialization”

Remoting V2 via QUIC

We made a video last year about head-of-line blocking and explained why the industry is moving away from TCP and towards QUIC as the underlying protocol for HTTP/3:

The long and the short of it is that in order to really get maximum throughput out of Akka.Remote, we have to support multi-plexing over the connection - something that TCP can’t really do, but QUIC can!

Enter MsQuic - Microsoft’s implementation of the Quic protocol, which is available in the .NET runtime as a stable feature since .NET 9.

If you want the full scope of work that’s going to go into Remoting V2, please see “Epic: Akka.Remote Quic-based Transport (Artery)” - but here’s the highlights:

1. Multi-plexing - this is where all of the significant performance gains come from. In Quic these are “streams” and you can see an example of me working with them here: https://github.com/Aaronontheweb/QuicFun
2. Security - TLS v1.3 is required as part of QUIC.
3. Automatic chunking of large messages - all “big” messages get handled in their own dedicated stream and are automatically chunked. No more need for tools like https://github.com/petabridge/Akka.Cluster.Chunking/.
4. Dedicated channel for exchanging system messages even while quarantined - this should make things like our Split Brain Resolvers work a lot better in partially connected scenarios, which can happen in large clusters.
5. Akka.Streams-based backpressure support - to stop the transports from getting flooded when the buffers are full and can take advantage of idle I/O cycles to perform other work, such as serialization.

Target Release Date for v1.6

We will have some alpha / beta releases of Akka.NET v1.6 up on nuget.org by the end of Q1 2025 - mostly focused on AOT support. Our target to get the entire project done is early Q1 2026.

How Can You Support V1.6?

There are three ways you can contribute to the Akka.NET v1.6 effort:

• Contributions: get involved in the Akka.NET Discord and ask in the #contributors channel how you can help. We’re still finalizing specifications for serialization / remoting but the work around AOT is pretty clear-cut.
• Promotion: follow Petabridge on YouTube, share our mailing list, and spread the word about Akka.NET to your friends and colleagues. Word of mouth always helps!
• Buy Our Products and Services: this is the best way you can contribute to Akka.NET and Petabridge because it directly finances our team of developers who work on it full-time. Check out Phobos our an Akka.NET Support Plan.

If you want to learn more about our plans for v1.6 and the development effort, please join us for our 1-15-2025 Akka.NET Community Standup on YouTube:

Akka.NET v1.5 Maintenance

Akka.NET v1.5’s big focus was on Developer Experience (DX) issues, hence the introduction of popular new features such a Akka.Hosting, Akka.Management, Akka.Persistence.Sql, and most recently: Akka.Analyzers.

Since Akka.NET v1.5 was released to market in March, 2023 we’ve seen a huge influx in Akka.Cluster and Akka.Cluster.Sharding adoption. This comes as no surprise to us since Akka.Hosting has made features like these much more accessible and easy to use than before.

However, the downside for us at Petabridge has been that we’ve been kept very busy fixing newly discovered bugs inside these distributed systems and these can be quite expensive to fix, as we showed in “The Worst .NET Bug I’ve Ever Fixed.” A good of our 2023-2024 was taken up by fixing all manner of plumbing issues like these.

Our plan, going forward, is to continue maintaining Akka.NET v1.5 in parallel with v1.6 and we’ll announce some more specifics once we get closer to a stable release candidate for v1.6

If you have any questions, leave us a comment or find us in the Akka.NET Discord! Thank you for all of your support!

If you liked this post, you can share it with your followers or follow us on Twitter!