One of the architects here at Engie must have talked with a solutions expert at NServiceBus - the recommendation was to use WebJobs instead of Function Apps as endpoints for NServiceBus. Lots of the examples show what is basically webjobs (console app). We have a workflow function app that we depend upon to service various ad hoc requests (return state of a workflow…). Is there some overriding reason webjobs must be used?
With the current NServiceBus architecture, Azure Functions are not compatible with the conventional NServiceBus endpoints. Typical endpoints are more suitable for long-running message processing. Azure Functions are good to get something in/out with short execution time and bursty load. Azure Functions hosting model is currently not supported by NServiceBus, and due to Functions opinionated API, many features will never be compatible (delayed recoverability for example). Additional issue with Functions is that certain behaviors are dependent on the trigger type. Failed messages for example, for ASB those are dead-lettered. For ASQ failed messages will be moved to various <originalqueue>-poison queues.
We currently have a survey about Azure Functions going on. I would encourage to participate if you have feedback.
So if we use a function app as an endpoint, we will miss out on the delayed recoverability features?
If I remember from the NServiceBus recoverability features, a multiple second-level-retry failed message should end up in the “error” queue, but you are saying with Function Apps it end in the dead-letter queue? Function apps then ignore NServiceBus recoverability settings?
Function apps then ignore NServiceBus recoverability settings?
I’ll put in a slightly different way - you’re asking to an SUV, but given a bicycle. Both types of transportations, but designed for different use-cases 
Azure Functions have their design that considers any message (in case of ASB or ASQ) coming in either successfully processed or failing, based on the outcome of execution (no exception vs exception thrown). By default, Azure Functions will apply their immediate retries, that have nothing to do with NServiceBus immediate recoverability. After that, it will dead-letter message. I.e. Azure Functions simply has no Delayed recoverability or error queue NServiceBus concepts. For that reason, it’s not possible to hook into something that doesn’t exist. For reasons such as this one, if you want a fully qualified NServiceBus endpoint with all features, you better off with WebJobs. Especially if you already use Azure App Service.
We are considering some level of support for Functions, but this likely will never be 1:1 mapping to the conventional endpoints. And also will depend on what we see a common usage pattern is.