Akka.Cluster is one of the most popular and useful parts of the Akka.NET ecosystem as a whole, but it’s also one of the most concept-heavy areas. We have a lot of literature on both the official Akka.NET documentation and elsewhere on our blog about concepts such as distributing state in Akka.Cluster, sharding data across cluster nodes using Akka.Cluster.Sharding, publishing messages across a cluster, and so on; however, that barely scratches the surface on the possibilities and uses of Akka.Cluster.

So my goal with this post is to provide a bit of an FAQ on some of the most important and central concepts needed to build and operate effective Akka.NET clusters.

Node Reachability vs. Membership

In Akka.Cluster there are two important, similar-looking concepts that every end-user should be able to distinguish:

1. Node reachability - is this node available right now? Can I connect to it?
2. Node membership - is this node a current member of the cluster? Is this node leaving? Joining? Removed?

When many users start working with Akka.Cluster, they operate from the assumption that these two concepts are the same. “If I kill a process that is part of an Akka.NET cluster, that process will no longer be part of the cluster.”

This assumption is incorrect and there’s an important distributed computing concept at work behind this distinction: partition tolerance.

In terms of the CAP theorem, Akka.Cluster provides an AP experience out of the box; Akka.Cluster developers typically trade away some of the cluster’s default availability and partition tolerance (A & P) in exchange for consistency in areas where their domains demand it.

Akka.Cluster’s partition tolerance abilities come from this “reachability” feature; in order to tolerate partitions you have to know where they are and what resources are affected by them...

Since the recent Akka.NET v1.3.0 release we’ve been working furiously to upgrade all of our plugins and other tools that are heavily used by the Akka.NET community in order to ensure that you can get everything you need to go into production with confidence.

Today we’re putting out a quick update to make everyone aware of the following updates:

1. Petabridge.Cmd v0.3.0 and v0.3.1 have been released and now fully supports Akka.NET v1.3.1 as well as .NET Core. As per Petabridge.Cmd’s v0.3.0 release notes, we’ve broken wire compatibility between all previous versions of pbm and Petabridge.Cmd.Host prior to v0.3.0. We did this in order to guarantee that a single pbm client could communicate seamlessly with both .NET Core and .NET 4.* applications. Please make sure you upgrade your pbm clients along with your hosts when you upgrade.
2. Akka.Monitoring v0.7.0, our open source monitoring extension for Akka.NET applications, is now available and supports Akka.NET v1.3.1. At the moment, however, it does not support .NET Standard - largely due to its dependence on PerformanceCounters and other drivers that do not yet support .NET Standard.

Over the next few months we’re going to be reworking the monitoring story around Akka.NET and Akka.Cluster in order to provide detailed, easy-to-use actor and cluster monitoring instrumentation that works on both .NET Core and .NET 4.5. This is our current top priority and we’ll be providing users on our mailing list with updates once we have something ready to show.

Please let us know in the comments if you have any questions or concerns!

In addition to Akka.NET joining the .NET Foundation and announcing our participation in the .NET Foundation Summer Hackfest, we had two more major Akka.NET developments to announce on Friday:

• Akka.NET v1.3, which adds .NET Standard support to Akka.NET, is released and now available on NuGet and
• The official Akka.NET website has been totally redone in DocFx in order to make it more readable, user-friendly, and well-organized.

Akka.NET v1.3 has been a work in progress since .NET Core was first released last year and is the culmination of hundreds of commits by dozens of contributors. You can read the official Akka.NET v1.3 release notes here, but what follows are my notes on some of the changes end-users can expect when adopting v1.3 and upgrading from earlier versions of Akka.NET.

.NET Standard 1.6 Support for Akka.NET

The most-requested feature for Akka.NET over the past year has been .NET Standard / .NET Core support.

In case you’re not sure what the difference is between .NET Standard and .NET Core: .NET Standard is a compilation target shared by both the full .NET framework (4.6.*) and .NET Core. Any library that targets .NET Standard 1.6, for instance, can be used inside .NET 4.6.1 AND .NET Core 1.1 applications. You can read more about .NET Standard and the various versions of it here at Microsoft’s official documentation.

Akka.NET’s NuGet packages now target both .NET 4.5 (which we always have, historically) and .NET Standard 1.6. NuGet will automatically install the .NET Standard 1.6 version of the NuGet package if you’re targeting .NET 4.6.1 or .NET Core.

We’ve already been using the Akka.NET v1.3 nightly builds in a new production-facing project and the results have been excellent thus far and we look forward...