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.

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.

In this post, we’ll discuss one of the Akka.NET plugins, Akka.Cluster.Sharding and how it gives us easier, higher level abstractions to work with actors (in this case also referred to as entities). Cluster.Sharding gives us:

• By using a logical keys (in form of ShardId/EntityId pairs) it’s able to route our messages to the right entity without need to explicitly determine on which node in the cluster it lives.
• It automatically manages the process of actor creation, so you don’t have to do it explicitly. When a message is addressed to an entity that didn’t exist, an actor for that entity will be created automatically.
• It’s able to rebalance actors across cluster as it grows or shrinks, to ensure its optimal usage.

Given all of those traits, let’s see how to utilize cluster sharding in a standard Akka.NET application.

In the first post in this series, we discussed how the correct place to begin thinking about an Akka.NET application is actually with your data flows and organizing those into reusable “protocols”. Once that’s done, then it’s time to start slotting actors into some of the interaction points inside the protocol.

But what happens when certain types of interactions are complicated and can’t easily be expressed inside one actor? Or what happens if you need to accumulate state for each individual instance of the protocol?

Think of a protocol like a class. A protocol is a logical unit of encapsulation that expresses some defined behaviors, inputs, and outputs. And just like classes, protocols can be composed - one class can have members that are of another type of class. Small protocols can be combined with other protocols to build large, system-defining behaviors. This is generally how stream processing architectures are actually designed at scale.

An instance of a class is called an object in OOP. In protocol-driven design a “protocol instance” is an instance of a protocol, just like how a class is instance of an object.

Actor Hierarchies and Protocols

A protocol consists of multiple different interactions and can have totally different flows depending on the state of each particular protocol instance. Your Akka.NET actor system can theoretically run hundreds of thousands of concurrent protocol instances at the same time. It’s the goal of a well-designed actor hierarchy to make it performant and easy to manage.

So the first rule of thumb when it comes to designing an actor hierarchy is once again: separate your concerns.

It’s pointless to attempt to design an entire end-to-end actor system before you’ve written any code, because you don’t know what you don’t know yet....

On Monday, September 26th at 8:00am PDT Petabridge will be hosting a free webinar entitled “Introduction to Distributed Systems with Akka.NET with Akka.Cluster“ - the goal of which is to help educate developers, architects, and technology executives on how these technologies can be used to build highly available, distributed systems.

We’ve never hosted a live webinar on the subject before and it’s a regularly requested topic - and if this one is popular we’ll definitely do another in the future on Akka.Cluster and other areas such as Akka.Persistence, Akka.NET DevOps, and so forth.

What We’ll Cover

This presentation is 90 minutes long and will be focused on the architectural concepts and possibilities that Akka.Cluster creates. Specifically:

• Why businesses are adopting Akka.Cluster and why this technology is desperately needed;
• How distributed systems are designed using Akka.NET actors and message-based systems;
• What Akka.Cluster does to make this easy; and
• How Akka.Cluster synergizes with modern deployment environments, such as Windows Azure Resource Manager, Azure Service Fabric, * Kubernetes, Apache Mesos, and so forth.

Seating is limited. We still have some room available, so please register now: click here to register.

We’ll be taking questions from the audience at the end of the presentation too!

N.B. the material we’re presenting in this webinar does have some overlap with our Akka.Cluster training, but is mostly new material. If you’ve attended our Akka.Cluster training in the past you will still get value out of this talk.

In Case You Can’t Attend

If you aren’t able to attend due to timezones or conflicts, go ahead and register anyway - we’ll send you a recording later the same day.

If you have any questions or comments, please leave them...

Our last customer case study “Akka.NET Goes to Wall Street” remains as one of the most popular articles on Petabridge, and today I’m pleased to share with you a new case study written by Kim-Lisa Gad and the DigiOutsource team from sunny Cape Town, South Africa.

The DigiOutsource team, lead by Jean-Pierré Vermeulen, developed an extremely high-speed complex event processing system real-time customer analysis system on top of Akka.NET from conception to production within 5 months, and that system has gone on to increase overall revenue by 35%.

What follows is their story!

Since releasing Akka.NET 1.1 I’ve been spending more time sharpening the saw here at Petabridge. Combing over the ways we spend our time and money and quantifying the returns that provides to us and to our customers. As it turns out, quantifying this is rather difficult for reasons that are all-too-common in the business world: data silos.

Our “business output” is measured and recorded in a number of disparate, disconnected, off-the-shelf systems. For example: We record our sales through Stripe and Quickbooks Online, but we never correlate them with the end-user interactions with Akka.NET Bootcamp, our YouTube videos, or our blog.

We want a complete picture of what really lead to a sale or to a successful deployment of Akka.NET, because that helps tell us what were good investments of our resources. So in order to do this I started designing a business intelligence application called “Brute” designed to perpetually stream information from all of these sources into a consolidated view. The first version of it is extremely simple but we have plans to expand what it does and the number of systems it can connect to.

Designing an Akka.NET Application

I decided that “Brute” presented a good opportunity for Petabridge to dogfood Akka.NET, especially some of the new modules such as Akka.Streams and Akka.Cluster.Sharding. Thus I’ve spent the past few weeks in the design process writing specifications, models, and documentation.

Protocol-Driven Design

Here’s the catch with designing an Akka.NET application, or really, any actor-based application: your actors aren’t the correct place to begin the design.

Instead, you always want to start the design of any Akka.NET application with the flow of events and information that go through it.