Messaging Framework Comparisons - Intro

Part 1 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).

    • Part 2 of this series – Azure Service Bus – can be found here
    • Part 3 of this series – Akka.NET – can be found here.
    • Part 4 of this series – NServiceBus – can be found here.

DEFINITION OF TERMS

First up we need to define some terms:

Service Orientated Architecture (SOA) - A software architecture where areas of functionality are broken down into services. These services are then joined via messaging to create products and applications. Allows for individual services to be managed and scaled independently within the system.

Enterprise Service Bus (ESB) - A system that manages the passing of messages between systems, defining a standard interface through which SOA can be implemented.

Message Queue/Transport - Is a persistent store for storing serialized data; these messages can stay in a queue until processed.

Reactive Systems – A responsive, elastic, resilient, message-driven system that uses microservices.

THE PROBLEM

Software development has changed greatly in the last ten years; our applications are no longer siloed, but depend upon being interconnected. The expectations of users and businesses have changed as well.

As processes become more and more asynchronous, we must design software that is capable of retaining requests even if a service should fail. We do not have perfect, zero latency networks. We need to ensure that no request is lost due to network connectivity. We also need the ability to scale individual services. There are a multitude of frameworks that aim to help you implement a service-oriented architecture, as well as mitigate the many common pitfalls.

Of the messaging frameworks compared in this series, the following areas will be explored:

Resiliency - the ability for an application to withstand failures in other systems, as well as recover from internal failures as quickly as possible. High availability (HA), automatic failover, and disaster recovery (DR) are typical concerns in this space.

Maintainability/Deployment - the ability make changes in response to bug fixes or changing requirements; also refers to the ability to push new bits while minimizing downtime.

Scalability/Throughput - the ability to increase processing resources in response to pressure put on the system. This includes decreasing resources when demand subsides. Another common term for this process is elasticity.

Learning Curve - the ease in which a framework can be adopted by development staff, thus reducing time to market.

Tooling - describes the built-in monitoring, telemetry and metrics-reporting capability of the framework.

Costs - this section outlines the fees or other costs associated with licensing or implementing the framework.

Commercial Support - some environments, especially at the enterprise level, require fast support from the developers of any third-party systems. This section details what support options are available as well as their costs.

UP NEXT

In the next part of this series we’ll dive into Azure Service Bus, covering its strengths and weaknesses.

Lancelot Dunnehoo

Lancelot Dunnehoo

Lance Dunnehoo is AI‘s Chief Architect and Principal Cat Herder. His 17 years in software consulting has led to a broad depth of knowledge in many technical and business domains, but his primary passion lies in distributed architecture and systems integration. When he‘s not working he can typically be found..working.