I've been on a bit of an Azure Functions kick over the last little while. I've blogged a bunch on Durable Functions and deployed a bunch more. When you're as old as me then you tend to draw comparisons between new technologies and existing ones. For instance I'm constantly telling people about how web pages are a lot like the cave paintings I use to do in my youth.

The Twitter Exchange

The technology that draws the closest comparison I've seen to Durable Functions are NServiceBus Sagas. A few weeks ago I tweeted out wondering if any body had done a comparison. The good folks at Particular stepped up and answered.

Recently @stimms asked about comparisons between Azure Durable Functions and NServiceBus sagas. https://t.co/7sB5t9KMtH

— Particular Software (@ParticularSW) January 15, 2019

I'll reproduce the thread here so you don't have to click through and I'll add some comments.

This isn't entirely accurate. You can trigger durable function continuations using external events https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-external-events but the mechanism is certainly less seamless than with NSB. You have to define a message handler and then raise the event. There is no nice way to find the running function like NSB does with Saga finding. https://docs.particular.net/nservicebus/sagas/saga-finding

Yeah this is certainly something to be aware of. You need to be careful about how long orchestrations run for. There is a concept of eternal orchestrations but basically they throw away all the history and start over again. If you have a complex orchestration then you can break it up into sub-orchestrations. But again, this isn't as nice as NSB.

One thing it does afford is the ability to rewind an orchestration and play it again.

This seems like another place where sub-orchestrations could come into play. Probably a better approach is to have a Durable Function simply drop messages on a queue which will trigger other functions which may or may not be durable. This provides the logical separation similar to what you'd get with a series of sagas in NSB.

This is a limitation I've called out on twitter and in my durable functions talks. There are a few hacks you can use like leaning on nameof but they're not satisfactory. I've been working on a Roslyn Analyzer which will detect incorrect names, wrong parameters and broken return types. This is an addon nuget package, though, and not something that comes out of the box (unless I can convince the team to include it in the template). You can find it at https://www.nuget.org/packages/DurableFunctionsAnalyzer and eventually I'll get around to blogging the details.

There is some really quite good unit testing advice at [https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-unit-testing](https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-unit-testing) for Durable Functions but it certainly isn't as elegant as NSB's implementations. For complex orchestrations I think the tests would be quite hacky.

This I can't argue with. I've reprocessed thousands of messages in NSB and the ability to do so has saved the companies for whom I've worked thousands of dollars and avoided angry customer.

You can rewind durable orchestrations after correcting the problem. However the lack of an error queue is really tricky. The restful APIs to list orchestrations and their status and potentially rewind them aren't scalable or generally usable. There is a serious lack of tooling here (start up idea, alert!).

I am pretty confident that you could build the equivalent of Service Pulse and Service Control on top of durable functions. If you were building a serious production system on top of Durable Functions I think you'd have to build some tooling in this space. That should be a cost consideration when you do your analysis of technologies to use.

This is totally accurate. I first used NSB in something like 2008 and even then it was a pretty mature product. Particular have built up a first class organization around NSB and you won't get better support anywhere.

Other Aspects

No brief tweet thread can't quite capture the entirety of the comparison. Let me go through a few other thoughts I had about the comparison.

Platform Independence

Durable Functions are highly coupled with Azure. This can be a good thing or a bad thing depending on your point of view. It speeds up development to have a lot of the decisions made for you already. Using existing Azure services together takes away from concerns about scalability and maintenance. However, if you ever need to migrate off Azure it would be a significant engineering effort.

NSB on the other hand is an embarrassment of configuration options. You can use SQL transport, MSMQ, SQS, Service Bus and so on and so forth. You can host on windows hardware, on VMs, docker images on K8S on Linux or Windows. No matter your environment be it cloud or infrastructure based there is an NSB configuration which will work for you. There is an added burden of figuring out what the right solution is for your application.

Support

I don't think the support aspect of NSB should be ignored either. Certainly there is a support system in place for Functions but it isn't going to be as good as the support you'll get from Particular. On multiple occasions I've been able to chat with the actual developers of a feature of NSB at some length. I think that's something that any users of NSB could get. I've had some discussions with the Functions team but I think that that is really through the benefit of being an MVP and being kind of vocal about Functions.

Cost is a factor too. I'm hesitant to bring this up because any cost comparison between free (which is Functions) and a paid product is bound to be one sided. You're going to have to pay for running your code one way or another. There isn't likely to be a huge price difference between running 10k messages through a cloud hosted NSB and Durable Functions. If you're a startup then there is free licensing available from Particular for NSB. I could certainly see an advantage for people in companies where buying licenses is harder than buying compute time on the cloud. On the other hand I think that the advantages of using a mature framework such as NSB offer huge advantages in reducing bugs and maintaining a production environment.

Code Structure

The message based paradigm of NSB is another advantage. You could write your Durable functions in a similar way to use concrete messages but boy is it tempting not to. I've found myself using a lot of tuples to chuck messages around which really I shouldn't. The constraints that NSB puts around messages are helpful in establishing good engineering practices. You can follow the same practices in Durable Functions but you'd need a strong code review culture and coding guidelines to keep you honest. There is an opportunity here for some Roslyn Analyzers or even a framework on top of Durable Functions.

On the surface the await/async model of Durable Functions is really cool. The .NET Framework provides the syntactic framework for doing orchestrations so why not lean on it? Well because it is complicated looking. You end up defining your entire workflow in a single function and being able to trace though it in your mind is limiting. Message handlers let you focus on smaller parts of the system at a time which is helpful to those of us without giant brains. Any reasonably complex orchestration is liable to spread over 50 lines and to mix business logic and the plumbing of doing things like running fan-outs and chaining.

The Golden Hammer

Functions can be trigged though a lot of different mechanisms. One of those is HTTP which means you can run your entire web application inside of Functions. In the same project as your web API you can also put in place Durable Functions and they will just work. This provides a low friction way of doing background tasks or multi-step processes with checkpoints. But it also mixes a lot of code together and removes the nice separation of code you can get with deploying a bunch of NSB processes. At the moment I'm leaning towards the ease of being able to stand up Durable Functions inside your API code as outweighing the increased maintenance cost of mixing code up. However it is really something which we'll have to watch evolve as Durable Function products mature.

Scaling

Finally I wanted to talk about the ease of doing things like scaling out. Particular have done a lot of work around ethereal instance as of late but for the longest time the handler processes were treated much more like pets than cattle. That mentality is totally different in the land of Functions where you don't even know what hardware is being used. Being able to transparently scale up and down is really nice.

Shut Up Already and Tell me What to Use

I wish decisions were that easy. There are advantages to both systems and I'm sure I've missed a number of key aspects worth examining here. Durable Functions are great and I'm happy to see some competition for Particular who tend to fall very much on the slow and stable side of the spectrum as opposed to the move fast and break stuff side. Durable Functions have some growing up to do. The tooling around them isn't there yet and I don't expect that tooling is going to come out of Microsoft so much as it will come out of a vendor.

If such tooling does emerge then you'll be back in the same boat as having to pay Particular for their product which does have an impact on the cost equation.

If I were that ThoughtWorks Tech Radar thing then I would probably put Durable Functions in the evaluate quadrant while NSB would remain in the adopt quadrant.