What is the future of NSB with the rise of Dapr
2 Likes
Could you please clarify what specifically are you looking for when it come to NServiceBus and dapr?
I have the same interrogation.
For nservicebus, i’m look for features like saga, outbox, abstraction of transporter, monitoring of the bus (not distributed tracing).
For dapr, I’m looking for an abstraction of principle for microservice and easily do a service from multiple language.
With dapr, for me, when we want to talk between service using a broker (pattern pu/sub), in reality we call an dapr abstraction by a rest call and dapr will do the job.
If dapr integrate the feature like saga, outbox, etc, and provide an abstraction of these features, we will have a nservicebus but multi-platform.
For me, it seems an idea to look forward.
anyone given a try to dapr. i’m currently working on a project that uses dapr pubsub component and is cool
Udi Dahan just did a webinar, an Ask Me Anything, that you can watch here.
It contained a question about Dapr as well. It’s around the 33 minute mark.
His answer included examples where low-latency is key, like chat applications, online ads, where there’s lots of request/response, data is kept in-memory and low-latency is important. He compared it more to Akka.NET, Orleans, etc.
NServiceBus on the other hand is more interested in business events and processing them in the backend. Events like that an order was submitted, a customer was billed, etc. In the back-end where you want high degree of reliability, fault tolerance, etc. and you’re willing to sacrifice latency for that. Back-end transactional processing is the sweet spot, if you will, for what NServiceBus is trying to do.
According to Udi, Dapr is more about relatively lightweight “notifications”. About a person that is currently typing, moving around on a map in a game, those type of things. It’s a broad, overarching type of statement. And of course, every one of those technologies can be banged to fit and has all sorts of additional features.
One thing he mentioned explicitly with Dapr though, where to be careful with, is transactionality. It’s mentioned somewhere in the documentation that they support cross-entity transactions, but that’s essentially the bad form of distributed transactions from back in the day. Actors that are enlisting in larger, distributed transactions. You’re trying to do a workflow thing, but transactional. That’s not a good thing to do with actors. You’re then essentially creating almost the worst form of a distributed monolith at that point.
1 Like
I hear you but dapr is much more than that.
Dapr is the way to go. Dapr is part of Cloud Native Computing Foundation
more dapr removes a licensing issue. for dev you can use redis etc and product use ASB
It would be interesting to hear more detail on how dapr is much more than what Udi describes.
I have recently started at a new company which uses dapr and I have used NServiceBus in the past and would be keen to hear more from someone who has an idea of both, seemingly almost 3 years since the question was first asked.
Thanks!
Until it’s not. At which point, the next technology is the way to go.
Unfortunately, there’s never one way to go. There is no default solution, there are only trade-offs.
The original question is good.
Here is the thing.
Since nservicebus is an abstraction in messaging, workflows etc and since dapr also has that abstraction as part of their side car features.
What does nservicebus plan to do, if anything to be a part of the dapr ecosystem. For example, a pub sub connector?
Also, Likely there are going to be also situations where dapr and nservicebus may coexist so what guides are there for integration/marshalling between the two?
Our company is exploring azure container apps with dapr built in. Also we use application insights for observability.
So in the same vein I’m curious what would be the value add if I can get messaging, events, and observation from dapr?