Part 3 of 4
Messaging frameworks allow for the creation of loosely coupled, highly resilient, and highly scalable systems. The challenges faced by modern applications are complex, and our solutions are likewise sophisticated. Applying patterns help us to design modern applications while reducing complexity. Messaging is a reliable and proven pattern to address these needs.
This blog series exists to survey messaging frameworks and comparable technologies built on the .NET stack. While there are quite a few options in this space when working with .NET, this series narrows its scope to the following: NServiceBus (https://particular.net/nservicebus), Microsoft Azure Service Bus (https://azure.microsoft.com/en-us/services/service-bus/), and Akka.NET (http://getakka.net).
- The Intro to this series can be found here.
- Part 2 of this series – Azure Service Bus – can be found here
- Part 4 of this series – NServiceBus – can be found here.
Of the messaging frameworks in this document, Akka.NET is the newest (in the .NET ecosystem). Akka.NET is an open-source port of Akka for the JVM. Akka and Akka.NET use the actor model to form a hierarchy of actors, each capable of acting atomically to receive, process, and send messages to other actors. This differs from an enterprise service bus in that there is no single pipeline responsible for routing messages throughout the system; rather, each actor is capable of sending and receiving messages from any other actor.
Akka.NET favors speed over infrastructure, leaving the implementer to decide on which tradeoffs are acceptable when designing a system.
Akka.NET implements the concept of supervision, meaning that each higher-level actor manages its subordinate actors. In the case of failure, supervisors self-heal the system by informing their children how best to recover.
Also, actors can be stateful; as messages are passed to an actor its state can be persisted to a data store and in the event of failure, the actor can be restarted and its state restored.
Akka.NET actors can be embedded into your applications wherever they are needed, or created as standalone windows services. As such, deploying actor systems would follow whatever your normal deployment process follows.
There is one caveat, and that comes when dealing with clustering and high availability. When deploying to clustered actor systems you need to be careful with your architecture such that you can release as blue green deployments, and thus lose no messages that may be awaiting processing.
Because Akka.NET makes the least assumptions on your architecture, it also has the smallest footprint of these messaging systems. This, along with baked-in clustering and load-balancing, leads to the highest throughput as well. With the default configuration in place, message processing can reach into the millions of messages per second per machine.
Akka.NET probably has the highest learning curve of these frameworks, due to its philosophy of being the most hands-off in terms of making architectural decisions for you. Actors start with the bare minimum of intelligence needed to handle at-most once message delivery guarantees and then rely on the developer to add extra guarantee levels, message retry mechanisms, or any persistence strategies they need.
Due to Akka.NET’s relatively recent emergence into the .NET ecosystem, tooling and monitoring are still being built out. New releases of the framework are released rapidly, however, and robust tooling is high on its roadmap.
Currently, choices are limited to log parsing or using third-party tools such as StatsD or Microsoft AppInsight.
Akka.NET is open-source, and free to use commercially.
Commercial support for Akka.NET is offered through Petabridge, the company responsible for porting Akka to Akka.NET. Costs for support can be found through inquiry on Petabridge’s website.
In the next part of this series we’ll dive into NServiceBus, covering its strengths and weaknesses. Stay tuned!