Akka.NET vs. Kafka, RabbitMQ, and Other Messaging Systems

What's the difference between Akka.NET, Kafka, RabbitMQ, and other message-driven technologies? Can they work together?

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.

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

Why You Should be Paying Attention to OpenTracing

How the Vendor-Neutral Tracing Standard Will Affect Frameworks and Application Development.

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

Phobos logo

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