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.
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.