We introduced Petabridge.Cmd in 2017 to make it easy for Akka.NET users to deploy, monitor, and manage their Akka.NET applications. We have now expanded the capabilities of Petabridge.Cmd by introducing two new command palettes to further simplify the way you monitor your Akka.NET applications. The new command palettes will allow you to monitor your system connections with Petabridge.Cmd.Remote and allow you to obtain sharding information using Petabridge.Cmd.Cluster.Sharding.

If you have not heard of Petabridge.Cmd yet, please take a look at our introduction YouTube video for Petabridge.Cmd

Video Highlights

• Description of Petabridge.Cmd.
• How Petabridge.Cmd works.
• How Petabridge.Cmd uses command palettes.
• Demo of setting up Petabridge.Cmd and the use of commands.

Petabridge.Cmd.Remote Commands

Let’s cover the 4 new commands that we have introduced with Petabridge.Cmd.Remote. These can be used with applications using Akka.Remote or Akka.Cluster:

1. remote stats - allows you to see the number of Association and Disassociation events seen by the node running your Petabridge.Cmd.Host;
2. remote connections - provides you with the number of active remote connections to the local host;
3. remote tail - writes all of the connections and disconnections events out to the console until stopped via Control + C and;
4. remote history - shows the connection events witnessed by the node. Can show up to 1,000 events.

We encourage you to give these commands a try in your application. Below you can see the output of some of the commands in our remote command palette. We ran the remote connections on a cluster and you can see the connection of our host node to all of the remote nodes. We also ran our remote history command with...

A while back I created a thread on Twitter to attempt to explain the difference between Akka.NET and some other popular message-distribution and queuing technologies, such as Apache Kafka and RabbitMQ.

Common question I get from users who are just starting to look at @AkkaDotNET : why use something like Akka .NET and not Kafka / RabbitMQ? What's the differences between these two pieces of technology? Can they be used together? Or are they competing technologies?

— Aaron Stannard (@Aaronontheweb) January 29, 2019

I’m going to cover that in some more detail in this post because it’s a common question asked by many developers who are just starting to look into Akka.NET.

Differences between Akka.NET, Kafka, RabbitMQ, and Other Messaging Systems

Message brokers, enterprise message buses, message queues, event hubs, and so on - for the sake of simplicity, which I’m certain will enrage developers in some corners of the Internet, I’m going to lump these technologies together into a single category: these are message distribution systems.

The manner in which they distribute messages varies and for our purposes those differences are totally immaterial (sorry, vendors.) The point is: producers write messages into these systems and the goal is, with varying degrees of reliability, concurrency, and asynchrony, to distribute these messages for processing to one or more downstream consumers.

Message distribution systems are transports - they aren’t involved in the act of creating or consuming messages. Only in delivering and routing these messages from their sources and to their destinations.

Where Akka.NET differs: Akka.NET actors are fundamentally message processing and message producing technologies.

Akka.NET actors are responsible for managing business state or executing commands, both of which occur when an actor receives a message.

Where the confusion occurs, however,...

In a previous post we introduced distributed tracing and how it solves some of the worst DevOps problems that arise with the use of microservices. In this post we’re going to introduce the OpenTracing standard and talk how what this project does and why you should pay attention to it if you’re a product owner, software architect, or developer.

Middleware, Frameworks, and Instrumentation

Petabridge is committed to delivering world-class tools for developers to build high-performance, large scale software applications in .NET; thus, developing middleware and application programming frameworks, Akka.NET most notably, is a core part of our mission.

All web and Internet-connected applications depend on frameworks and middleware of some kind, because the overwhelming majority of companies who build software don’t want to be in the business of creating and maintaining infrastructure. This is why we have nice tools like ASP.NET Core, SignalR, Akka.NET, gRPC, DotNetty, NServiceBus, RabbitMQ, and so on.

These frameworks provide us with convenient abstractions that:

• Significantly lower the cost of developing software in-house;
• Improve the productivity of individual software developers; and
• Allow for the formation and sharing of industry best practices and standardized designs.

In short, middleware makes the modern software economy possible.

How Asynchrony, Microservices, and Distributed Systems Changed the Economics

As the Internet has grown, there has been a tremendous amount of pressure on server-side software developers to build systems that are available 24/7/365, capable of working across a larger range of devices (desktop, mobile, embedded, etc…,) able to capture and utilize ever-increasing amounts of data, and capable of responding faster and faster to end-user requests. This pressure is what’s driven the adoption of technologies like the actor model, pushed frameworks like .NET to prioritize the development of asynchronous programming constructs such as the TPL, and driven...

We released Phobos, our enterprise DevOps suite for Akka.NET only just last month and we’ve already had major Akka.NET users put it through its paces in development and production environments. Based on our users’ feedback and suggestions, we’ve developed Phobos v0.6.0 and made it available for immediate release to all of our evaluation and production users.

If you missed our Phobos announcement here’s the gist of what Phobos does for Akka.NET users:

Phobos instrurments, monitors, and traces all activity from actors inside large Akka.NET applications and exports it to common, off-the-shelf monitoring tools used by .NET enterprises; it works over Akka.Remote and Akka.Cluster; and it can do all of this without any explicit instrumentation code at all. Phobos can be entirely driven through configuration and works automatically behind the scenes.

If you’d like more background information about Phobos, we highly recommend that you visit the Phobos homepage.

Here’s what’s in the newest version of Phobos:

Expanded Tracing and Monitoring Integrations

The biggest addition to Phobos in v0.6.0 is the expanded set of Phobos drivers for working with various monitoring and tracing systems. Here’s what is included in Phobos v0.6.0:

• Tracing: Jaeger - we’ve added first party support for the popular open source Jaeger tracing engine, which is now available via the Phobos.Tracing.Jaeger NuGet package.
• Tracing: Microsoft Application Insights - we’ve added OpenTracing-compatible tracing support for Microsoft Azure’s managed Application Insights service via the Phobos.Tracing.ApplicationInsights package.
• Monitoring: Microsoft Application Insights - in addition to adding tracing support for Application Insights, we’ve also added corresponding monitoring support via the Phobos.Monitoring.ApplicationInsights NuGet package.

If you’re already using the Microsoft Azure platform, we think you’ll find Phobos’ Application Insights integration...

One of the most powerful features of Akka.NET actors is their built-in fault tolerance. Actors are an extremely effective tool at isolating failures and preventing them from having side effects on other parts of your application.

However, one of the most frequently asked questions we hear when training .NET developers on the fundamentals of Akka.NET is: “what happens to my data when an actor restarts? Do I lose messages? State?”

We address those questions in this tutorial.

This video covers:

• How Akka.NET actors are supervised and restarted by their parents when they crash;
• The internals of how individual actors are constructed and the role these parts play during restarts;
• How restarts are made transparent to other actors via IActorRef; and
• Why these properties can ultimately help build more resilient and effective .NET applications.

If you like this video please share it and subscribe to Petabridge’s YouTube channel!

Historically most web applications were developed as monolithic architectures. The entire application shipped as a single process implemented on a single runtime. Ultimately this architectural choice makes scaling software development extremely painstaking and tedious, because 100% of code changes submitted by members of any development team target a single code base. Under monolithic designs deployments are executed as “all or nothing” affairs - either you deploy all parts of your application at once or you deploy none of them.

It’s for painful reasons like this that the industry is moving away from monoliths and towards distributed architectures such as microservices. What microservices provide isn’t product scalability; they provide people scalability - the ability to easily partition your software development organization along the same lines as you partition your application with service boundaries.

DevOps Implications of Microservices

Microservices provide enormous agility and flexibility to software development organizations. By partitioning our large applications into interdependent services which communicate via explicit network communication contracts, each team encapsulates their implementation from the others. This makes it possible, in theory, for each team to choose the best tools for the job - if Service 1’s requirements are best satisfied using Node.JS and Redis but Service 2’s are better handled with .NET and SQL Server, both of these teams can make those choices and develop / deploy their services independently of each other.

In practice, microservices are really a trade off for one set of organizational and technical problems for others. While the benefits of microservices amount to greater independence; clearer organizational boundaries and division of labor; and greater agility those benefits come with some distinct costs:

1. Loss of coherence - now that the work to fulfill a single end-user request is now broken...

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