Today it’s my pleasure to announce the production-ready release of Phobos, an enterprise DevOps suite for Akka.NET developers.

The initial release of Phobos is primarily aimed at solving the following problems:

1. Instrumenting and monitoring activity from actors inside large Akka.NET applications and exporting it to common, off-the-shelf monitoring tools used by .NET enterprises;
2. Implementing OpenTracing protocols behind the scenes and over the network stack of Akka.NET, so we can provide end-to-end distributed tracing for Akka.NET actors; and
3. Doing all of the above automatically without any instrumentation code or setup of any kind. Phobos can be installed into any existing Akka.NET application and capture all of this data with as little as 5 lines of HOCON configuration.

I’d encourage you to watch the “Introduction to Phobos: Enterprise DevOps for Akka.NET” video we put together which explains this in more detail. It’s only about 5 minutes long.

Integration with Third Party Monitoring and Tracing Services

Phobos is designed to act primarily as instrumentation for your Akka.NET applications; it ships all of the metrics and trace data it records to off-the-shelf monitoring and tracing products. This includes a variety of open source and proprietary tools chosen by our customers and users. We know how hard it can be to introduce new tools inside large enterprise environments, so our goal is to be able to support whatever you and your organization currently use.

And if you’ve never used something like Zipkin or StatsD, we’ve collected some docker-compose scripts you can use to test drive those technologies (with or without Phobos) here.

Trying and Using Phobos

Phobos has been in the works for about a year and we’ve...

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...

It’s our pleasure to announce that as of today, Akka.NET is officially part of the .NET Foundation! Akka.NET is joining an elite group of projects such as Roslyn, NuGet, .NET Core, ASP.NET Core, and others.

What Does This Mean for Akka.NET?

Open source foundations have been a mainstay of OSS projects across many different platforms for years; ultimately what they provide to OSS projects are legal support, marketing help, and general project guidance. This includes things like protecting the project’s copyrights, ensuring that its intellectual property is in good standing and is properly assigned, etc.

In general the goal of the .NET Foundation is to help ensure that all of its projects follow OSS best practices in order to increase adoption of OSS across the entire .NET ecosystem.

Akka.NET already has major users such as Bank of America, SNL Financial, Schneider Electric, Boeing, and others. And the rate at which Akka.NET is being installed and deployed into production is increasing all the time. We’re joining the .NET Foundation in order to help broaden the tent of Akka.NET users and send a signal to potential users everywhere that Akka.NET is in it for the long haul and that our project is enterprise-friendly.

The core development team behind Akka.NET will continue to do what they’ve been doing; our roadmap and our priorities are driven by achieving parity with our partners at Lightbend and the Scala implementation of Akka and by the demands of our users. Joining the .NET Foundation will enable us to focus on our code, samples, and documentation while it helps us keep the project’s IP and community standards in good hands.

Announcing the Akka.NET Contrib Organization and the 2017 .NET Foundation Summer Hackfest

One other big change we wish to...

Petabridge has been working with Akka.NET users since January, 2015 and one of the biggest gaps in the Akka.NET ecosystem thus far has been adequate tooling for deployment, monitoring, and management of Akka.NET applications. This has been especially true for users who are building sophisticated, high-performance distributed systems using Akka.Cluster.

Today we’re pleased to announce the release of the first one of our tools for this purpose: Petabridge.Cmd - a command-line interface for managing Akka.NET applications in production.

Petabridge.Cmd Features

So what can Petabridge.Cmd do? Out of the box, it supports the following:

1. Akka.Cluster management - view the status of the cluster, down nodes, trigger nodes to leave the cluster gracefully, and have new nodes join an existing cluster;
2. Akka.NET log management - perform a live tail of logs from a given node, view historical logs, manually append log messages, and more;
3. Akka.NET actor hierarchy visualization - perform a live trace of the current actor hierarchy, including ones on remote machines;
4. System information - view data about the uptime of the current node and etc;
5. Ability to define custom, application-specific management commands, which can be automatically downloaded from the Petabridge.Cmd.Host server to the pbm client with no code updates necessary; and
6. Tab-autocomplete, help information, command memorization, argument hints, and a two-line installation process.

Petabridge.Cmd provides an out of the box experience that is designed to give most Akka.NET users 80% of what they need right out of the gate.

Installation

Petabridge.Cmd ships as two component parts which work together:

1. The pbm client, which can be installed via Chocolatey - a package manager for Windows and
2. The Petabridge.Cmd.Host, which is installed to your...

Fresh off the release of Akka.NET 1.2 last month, we’ve been hard at work moving onto the next set of changes and developments for Akka.NET. So let’s get right into it.

Current State of Akka.NET

First, our previous Akka.NET roadmap from 2016. We accomplished most of what we wanted to achieve on that roadmap, but the exact releases and the dates are all over the place. So just to review what’s happened since this roadmap was written:

• July 2016. Akka.NET 1.1 - Stable Akka.Cluster; Akka.IO release; Akka.Streams Beta. Helios 2.0 transport and Akka.Remote performance improvements.
• September 2016. Akka.NET 1.1.2 - Stable Mono support; Downing providers for Akka.Cluster, and lots of other features and fixes.
• January 2017. Akka.NET 1.1.3 - Akka.DistributedData beta; introduction of Hyperion serializer.
• April 2017. Akka.NET 1.2 - DotNetty transport with TLS support for Akka.Remote; Akka.Streams RTM; Akka.Cluster.Tools RTM; CoordinatedShutdown; and more.

You can view the full release notes for each of the Akka.NET releases from our Github repository here.

You’ll notice that many of the things we promised in Akka.NET 1.5, such as TLS support did not happen in that order and some proposed changes, such as a new default serializer, have not happened yet.

Without getting too deep into the details, the release of .NET Core in the summer of 2016 had to be factored into our roadmap and we wanted to add support for .NET Standard in 1.5. As we later discovered, adding .NET Standard support that early turned out to be a bit premature: the .NET Standard / .NET Core + tooling rodeo was an unmanageable mess in 2016.

Now that Visual Studio 2017 is out and many of the other libraries we depend on all support .NET Standard / .NET Core, it’s a much easier proposition for...

A ton of work has gone into Akka.NET thus far in 2017, and the biggest release we’ve done since last year’s Akka.NET 1.1 release just hit NuGet: Akka.NET v1.2.

Akka.NET v1.2 is the culmination of months of work on many different fronts at once, and you can read the official Akka.NET 1.2 release notes here. In this post we’re going to explain the significance of the 1.2 release and what it means for the end-users of Akka.NET.

Akka.Streams and Akka.Cluster.Tools Released from Beta

The most notable part of the release is what’s coming out of beta: Akka.Streams and Akka.Cluster.Tools. Both of these modules now have stable APIs and are considered to be sufficiently well-tested and well-used (measured by adoption and usage during its beta period) to be considered full production-ready modules.

Akka.Streams is a subject we intend to cover at length as it’s an amazing, higher-level abstraction built on top of Akka.NET actors that allows end-users to express powerful flows in just a few lines of code. Petabridge has been using Akka.Streams in a number of our consulting projects for months now and both we and our customers are impressed with its conciseness and power.

Akka.Cluster.Tools is built on top of Akka.Cluster and introduces three additional capabilities:

• Distributed Publish and Subscribe, which we’ve written about recently on the Petabridge blog. In essence this module can be used to create a decentralized message broker that allows Akka.NET actors to subscribe and publish to various user-defined “topics” across the cluster. This can be done transparently without needing to know which subscribers and which publishers are on each node.
• Cluster Singleton, which is used to help create reliable singleton actors inside a cluster. I.E. you can guarantee that only a single actor of...

Today we’ll talk about one of the most common communication patterns, which is publish/subscribe, and how to perform it in a distributed environments using Akka.NET. In case if you want to save yourself some time implementing it, its already available as part of a bigger package called Akka.Cluster.Tools. To install it, you can simply get the latest prerelease version from NuGet:

install-package Akka.Cluster.Tools -pre

Below, we’ll cover the abilities and limitations that come with the Akka.Cluster.Tools.DistributedPubSub implementation.

When EventStream isn’t enough

An idea of distributed publish subscribe came from slightly different design choices than those of the default Akka pub/sub model (EventStream).

EventStream has been invented to work with actor systems from the ground up, even in systems that are not inherently distributed. It’s extremely simple, lightweight, and fast. Dead letters - a place where every undeliverable message lands by default - is implemented on top of it.

However, EventStream comes with some limitations. It works only locally in the scope of the current actor system. This means that you cannot publish/subscribe actors from other nodes and publish messages in a global address space without worrying on which node they live. These limitations were motivation for a separate, cluster-specific publish-subscribe feature.

We have an updated guide to Akka.Cluster.Sharding that incorporates newer APIs and practices. Please see “Distributing State Reliably with Akka.Cluster.Sharding” instead.

In our previous post about using Akka.Cluster.Sharding we looked at the module from an end-user’s perspective. Today we’ll provide a little more insights into how this plugin works internally.

Cluster sharding depends on several types of actors:

• Coordinator - one per entity type for an entire cluster.
• Shard region - one per entity type per each cluster node, where sharding should be enabled.
• Shard - there can be many on each shard region, and they can move between shard regions located on different nodes.
• Entity - actors defined by the end-user. There can be many on each shard, but they are always bound to a specific shard.

All of them can be visualized using diagram below:

If you look at actor paths of the entities you’ve created you’ll see that they reflect the structure of that hierarchy. They follow the pattern /user/sharding/<typeName>/<shardId>/<entityId>. Given that, it’s easy to infer that /user/sharding/<typeName> is path to a shard region while subsequent path segments are responsible for shard actor and entity actor.