Why we use MassTransit

A couple of months ago we were challenged to refactor one of our domains. I won't discuss all the reasons we had to refactor this, but the main reason might have been the degree of high coupling. Fortunately there are pretty solid solutions available to easily evolve to loose coupled systems. To achieve loose coupling we wanted to introduce a MessageBus and a PubSub architecture. Well defined events would be published and any service interested would subscribe to those events. That's just a brief summary of what happens, but I don't want to bore anyone.

In the beginning there was NServiceBus

Because I am familiar with NServiceBus, we created a first POC using NServiceBus 4. We had a basic setup in no time. That is what NServiceBus promises and they didn't fail to deliver there. After some initial demos and finetuning some processes we had the feeling we were on the right track and this would eventually go into production. Going into production means you have to respect licenses. This was the first time NServiceBus let me down. The licensing calculation is not sufficiently transparent (that's an absolute personal opinion; as is everything else on the blog) and repeatedly contacting NServiceBus didn't really provide a solution for us. We needed a go-live license, but for the initial release, we rather didn't spend any money until the entire setup proved itself worthy. Note: I respect Udi Dahan's (NServiceBus) position.

During this entire period I was aware of the existence of MassTransit. In the past I had already told myself to look into it and give it a fair chance. It just didn't happen, but now I was triggered.

So why end up with MassTransit?

I rewrote this paragraph a couple of times. It seems I always start explaining what we did to solve the technical issues we experienced introducing MassTransit. I'll blog about this later (that's a promise). SPOILER ALERT: all issues where gracefully resolved and more.

Turned out we have multiple reasons to remove all NServiceBus logic and switch to MassTransit,

Was it all about money?

No, it was not. However it is fair to say that since MassTransit is free to use, it's absolutely a very good reason to make the switch. We would all be lying if we say we don't care about the dollars. You could discuss there is also the cost of ownership which would be lower using NServiceBus. That might be true, but MassTransit isn't an untested MessageBus by far.

Great, fast feedback, reactive and proactive

What I mean is that whenever we were stuck, we had multiple ways to get unblocked very fast. First of all there is the documentation. True, it requires some additions and lacks a well documented example. Using the Google group and Twitter we always got our answers in no time. It's amazing to what 160 characters worth of text might lead. We got into contact with Chris Patterson (MassTransit) who obviously was of great help and if you shoot a tweet to #mtproj, you will be helped.

Potential, potential, potential

Looking at the MassTransit codebase I see a clean codebase. Easy to understand, easy to extend. There might not be a reason to extend a lot, but to give you another heads up: we added direct messaging to MassTransit through configuration. Those familiar with NServiceBus, will relate to this as the UnicastBus.

To sum it all up, we are using a professional grade MessageBus and we feel backed by a great community. The fact that it is free to use only adds up to the pleasure of using MassTransit.
Stay tuned for a more technical blogpost. I am sure you'll get something out of it.