Honestly, I don't understand why do companies buy licenses for using NServiceBus while there's a such juggernaut library like MassTransit available for free...
Pitty that MassTransit uses huge amount of threads while app starts up and also slows down dramaticaly :( The same quantity of subsciption on EasyNetQ starts immediately.
The only project I worked with and was paying for NServiceBus was a project started long time ago when MassTransit was no competition to NServiceBus. Switching would be too expensive
I don't disagree but at the same time I find masstransit is lacking in good documentation. It's powerful but the features aren't as discoverable. Maybe users are used to learning about it via UA-cam instead of written docs, but not everyone has time for that. Not a statement relative to nservicebus, which I have never even attempted to use.
One of the hardest parts of messaging applications is that you almost always have a local database that you are interacting with, so suddenly it becomes important to consider how database transactions interact with the message queue. If you are processing messages from an outside system, you need to make sure that the message handler is Idempotent. Understanding what to do when a handling or sending a message fails is super important. If you are using your local database as the message transport, then you can include the handling and sending of the message in your database transaction, and that means you can really simplify things a lot, however using the database for the transport is really only a good idea for a system that talks to itself, or services that share a common database.
As for the question of which Message bus do I use? In the workplace, NServiceBus, but in my personal projects I wrote my own (with an admittedly much smaller feature set) but the price can't be beaten (PeachTreeBus). Its SQL Transport only.
@@jacobstamm Yes. The Message queues are just tables in your application's database. This means that the library can start a DB transaction, read one message, invoke the handlers, insert new messages, delete the old message and commit the DB transaction. This lets allows you to assume in your error handling that the whole message processed successfully exactly once or the transaction was rolled back. The downside to SQL transport is that its really only good for a system that talks to itself or systems that trust each other with DB access. If you need to exchange messages with an outside system then I use what I have been calling a message gateway, where a service reads and writes between the internal SQL queue, and the external queue. This lets me put all my de-duplication concerns in one place.
@@jacobstamm yes, effectively the queues are just tables in your database. There is some magic here because the operation becomes Start DB Transaction, Read Message, Invoke Handlers, Insert new messages, delete current message, commit DB Transaction. This means that processing of a message becomes an exactly once operation, and the handlers complete successfully as a whole or the transaction is rolled back. This can greatly simplify concerns about Idempotency, de-duplication, and error handling. The trade off is this is really only good for a system talking to itself. If you are communicating with other systems that you don't want connecting to your database, you'll need something else to act as gateway.
@@tunawithmayo We recently made this choice between using rabbit or using the db as a queue. Since we had to keep the state (as an append only table) anyway, it seemed like the much simpler choice. Having the transaction on the write side and the simplicity of consuming side means none of the issues that come with having 2 dependencies. Like updating the state but rabbit being down, so nothing gets on the queue. However, this was implemented without any library and uses polling on the consuming side. Still not sure if this was the right choice, other teams seem to default to using a real queue, and so we sometimes get people being surprised about why this is implemented this way.
Like most paid tools, I would caution against using nservicebus unless you need everything abstracted for you. Much of the resilience is now already built into the buses themselves or the standard sdk, particularly in azure. While Nservicebus maybe good if you want to throw money at the problem, the juice might not be worth the squeeze for many. In terms of its value: How often do you change message buses? Given that most major buses are based on amqp the cost of changes would likely be smaller if it were needed.. but with the code patterns remaining mostly the same. Also as a solutions architect who spent the past decade or two working my way up as a developer( I've seen some stuff).. don't use your messagebus for request /response it only ends in tears as you scale.. instead step back and look at your workflow.
You're not mentioning service control together with ServiceInsight and ServicePulse which gives you plenty of tooling to monitor what's happening throughout your applications and retrying messages with ease. I'm using those tools basically every day. I don't think you get those tools out of the box for any other libraries, but maybe I'm wrong.
Yeah, these tools were the main selling point for my work to use NSB instead of Mass Transit several years ago. Those tools are invaluable for us right now.
Very nice. I'm curious about 2 things: 1. The difference between multiple handlers for Commands vs Events. I assume a Command would be handled by ONE handler, whereas an event handled by each? Are there any special configurations to tell it how to route Commands vs Events? 2. I'd love to see what they have built in to NServiceBus for the outbox pattern.
I'm new to learning about event driven development and have been looking into DDD since my company uses it. Watching this video, everything always looks the same to me when it comes to these libraries: there's some event or message, then you build a handler to retrieve it. Why are there so many libraries that look like they do the same thing? Why can't MediatR be used in this case to publish to a service bus or something like that? Is it strictly because it's only a "local" messaging library? If so, can NServiceBus (or even Mass Transit) just be used the same way that MediatR is used (for publishing events or sending messages)?
I believe abstraction over queues and topics is not the reason anyone will buy NSB, even MassTransit has much simpler alternatives for that The fun part of those more complex tools comes starts with sagas
Something to consider, especially in todays environment. With the comment on the history "The project grew out of a codebase Udi used with his clients since 2003 to build distributed systems for the aerospace industry where you could say it was "battle hardened" from day one." is particularly disturbing.
@@seanfeldman . Better to boast that you started in a basement than to boast your software is "battle hardened" by a regime that indiscriminately kills civilians by their thousands.
@@seanfeldman . Boasting that one managed to build a company from a basement or garage is very different from saying your software is "battle hardened" by a regime that indiscriminately attacks innocent civilians by the thousands.
Boasting that one managed to build a company from a basement or garage is very different from saying your software is "battle hardened" by a regime hell bent on destroying people.
Honestly, I don't understand why do companies buy licenses for using NServiceBus while there's a such juggernaut library like MassTransit available for free...
Pitty that MassTransit uses huge amount of threads while app starts up and also slows down dramaticaly :(
The same quantity of subsciption on EasyNetQ starts immediately.
Exactly
The only project I worked with and was paying for NServiceBus was a project started long time ago when MassTransit was no competition to NServiceBus. Switching would be too expensive
I do question the longevity of mass transit. Chris had been doing this for years and it's mainly his baby
I don't disagree but at the same time I find masstransit is lacking in good documentation. It's powerful but the features aren't as discoverable. Maybe users are used to learning about it via UA-cam instead of written docs, but not everyone has time for that.
Not a statement relative to nservicebus, which I have never even attempted to use.
One of the hardest parts of messaging applications is that you almost always have a local database that you are interacting with, so suddenly it becomes important to consider how database transactions interact with the message queue. If you are processing messages from an outside system, you need to make sure that the message handler is Idempotent. Understanding what to do when a handling or sending a message fails is super important. If you are using your local database as the message transport, then you can include the handling and sending of the message in your database transaction, and that means you can really simplify things a lot, however using the database for the transport is really only a good idea for a system that talks to itself, or services that share a common database.
As for the question of which Message bus do I use? In the workplace, NServiceBus, but in my personal projects I wrote my own (with an admittedly much smaller feature set) but the price can't be beaten (PeachTreeBus). Its SQL Transport only.
@@tunawithmayoSQL transport, meaning the queue itself lives in SQL? I like that idea. Seems simpler than some of the distributed alternatives.
@@jacobstamm Yes. The Message queues are just tables in your application's database. This means that the library can start a DB transaction, read one message, invoke the handlers, insert new messages, delete the old message and commit the DB transaction. This lets allows you to assume in your error handling that the whole message processed successfully exactly once or the transaction was rolled back. The downside to SQL transport is that its really only good for a system that talks to itself or systems that trust each other with DB access. If you need to exchange messages with an outside system then I use what I have been calling a message gateway, where a service reads and writes between the internal SQL queue, and the external queue. This lets me put all my de-duplication concerns in one place.
@@jacobstamm yes, effectively the queues are just tables in your database. There is some magic here because the operation becomes Start DB Transaction, Read Message, Invoke Handlers, Insert new messages, delete current message, commit DB Transaction. This means that processing of a message becomes an exactly once operation, and the handlers complete successfully as a whole or the transaction is rolled back. This can greatly simplify concerns about Idempotency, de-duplication, and error handling. The trade off is this is really only good for a system talking to itself. If you are communicating with other systems that you don't want connecting to your database, you'll need something else to act as gateway.
@@tunawithmayo We recently made this choice between using rabbit or using the db as a queue. Since we had to keep the state (as an append only table) anyway, it seemed like the much simpler choice. Having the transaction on the write side and the simplicity of consuming side means none of the issues that come with having 2 dependencies. Like updating the state but rabbit being down, so nothing gets on the queue. However, this was implemented without any library and uses polling on the consuming side.
Still not sure if this was the right choice, other teams seem to default to using a real queue, and so we sometimes get people being surprised about why this is implemented this way.
Like most paid tools, I would caution against using nservicebus unless you need everything abstracted for you.
Much of the resilience is now already built into the buses themselves or the standard sdk, particularly in azure.
While Nservicebus maybe good if you want to throw money at the problem, the juice might not be worth the squeeze for many.
In terms of its value: How often do you change message buses? Given that most major buses are based on amqp the cost of changes would likely be smaller if it were needed.. but with the code patterns remaining mostly the same.
Also as a solutions architect who spent the past decade or two working my way up as a developer( I've seen some stuff).. don't use your messagebus for request /response it only ends in tears as you scale.. instead step back and look at your workflow.
"don't use your messagebus for request / response it only ends in tears as you scale"
What do you mean by that? What part doesn't scale?
Honestly I simply want to use HTTP for request / response to keep things simple. It's just that everyone wants everything on a message bus.
You're not mentioning service control together with ServiceInsight and ServicePulse which gives you plenty of tooling to monitor what's happening throughout your applications and retrying messages with ease. I'm using those tools basically every day. I don't think you get those tools out of the box for any other libraries, but maybe I'm wrong.
Yeah, these tools were the main selling point for my work to use NSB instead of Mass Transit several years ago. Those tools are invaluable for us right now.
Very nice. I'm curious about 2 things:
1. The difference between multiple handlers for Commands vs Events. I assume a Command would be handled by ONE handler, whereas an event handled by each? Are there any special configurations to tell it how to route Commands vs Events?
2. I'd love to see what they have built in to NServiceBus for the outbox pattern.
I'm new to learning about event driven development and have been looking into DDD since my company uses it. Watching this video, everything always looks the same to me when it comes to these libraries: there's some event or message, then you build a handler to retrieve it. Why are there so many libraries that look like they do the same thing? Why can't MediatR be used in this case to publish to a service bus or something like that? Is it strictly because it's only a "local" messaging library? If so, can NServiceBus (or even Mass Transit) just be used the same way that MediatR is used (for publishing events or sending messages)?
Not sure about NServiceBus, but MassTransit does also support the mediator pattern.
Thank you for the video @Nick, Could you please also consider making video related to NServiceBus Sagas ?
I think the IDoSomething naming pattern is cute.
uWu programming
Why not Azure service Bus ?
MassTransit, usually with RMQ
I believe abstraction over queues and topics is not the reason anyone will buy NSB, even MassTransit has much simpler alternatives for that
The fun part of those more complex tools comes starts with sagas
I would rather use Mass Transit.
@Nick Temporal next please.
lesgoooo
Anyone using Wolverine?
NServiceBus headquarters is in isreal
Something to consider, especially in todays environment.
With the comment on the history "The project grew out of a codebase Udi used with his clients since 2003 to build distributed systems for the aerospace industry where you could say it was "battle hardened" from day one." is particularly disturbing.
@@John.Oliver, right. It isn't reassuring to know that Amazon and Apple started in a basement and garage.
@@seanfeldman . Better to boast that you started in a basement than to boast your software is "battle hardened" by a regime that indiscriminately kills civilians by their thousands.
@@seanfeldman . Boasting that one managed to build a company from a basement or garage is very different from saying your software is "battle hardened" by a regime that indiscriminately attacks innocent civilians by the thousands.
Boasting that one managed to build a company from a basement or garage is very different from saying your software is "battle hardened" by a regime hell bent on destroying people.
NickServiceBus tm