Create guidance for moving from InProcess to Isolated Worker model

[dvdstelt]

Microsoft announced that Azure Functions InProcess model will receive its last update with .NET 8. This version of .NET has already been out for a while at the time of writing, but there hasn't been an SDK update for isolated functions yet, which we expect is Microsoft's way of warning users to migrate to the Worker model. We already encourage customers to not start new projects with InProcess functions.

For customers that already use NServiceBus Azure Functions InProcess we need a migration guide to allow them to migrate to Isolated Worker functions. A guide that explains to them how to switch NuGet package and potentially take additional steps to migrate.

[TravisNickels]

The migration guide for in-process to isolated worker model has been added to the docs site: https://docs.particular.net/nservicebus/upgrades/azure-functions-service-bus-in-process-isolated-worker

[andreasohlund]

@TravisNickels The isolated model doesn't support "AtomicSendsWithReceive", I didn't see that pointed out in the guide, was that considered?

[TravisNickels]

The isolated model doesn't support "AtomicSendsWithReceive", I didn't see that pointed out in the guide, was that considered?

There was discussion about not repeating information and there is a reference to that documentation in the related articles section.

I did have a more in-depth discussion with Daniel about "SendsAtomicWithReceive", but it was after this PR was already merged. However, I'm definitely open to the idea of explicitly including that in this migration guide, if we think it would be beneficial.

[andreasohlund]

Had a chat with @danielmarbach and we think its worth pointing out since if you have atomic sends enabled (not on by default) for the in-process model you would have to adjust things when migrating.

The adjustments would be:

1. (My preferred) Start using the outbox https://docs.particular.net/architecture/consistency#transactions-outbox-pattern
2. Ensure that all handlers involved are idempotent https://docs.particular.net/architecture/consistency#idempotency

Does this make sense? (happy to help out with the exact wording)

[TravisNickels]

Yeah, that makes sense.

I'm assuming that because the worker model doesn't have a SendsAtomicWithReceive assembly attribute like the in-process model does, that it's not possible to even change the transaction mode. Is that correct?

That would mean if a user had

[assembly: NServiceBusTriggerFunction("ASBFunctionEndpoint", SendsAtomicWithReceive = true)]

They would need to remove SendsAtomicWithReceive = true. Then implement outbox and/or configure all handlers to be idempotent.

I will raise a new PR to address the changes and ping both of you for a review.

[andreasohlund]

I'm assuming that because the worker model doesn't have a SendsAtomicWithReceive assembly attribute like the in-process model does, that it's not possible to even change the transaction mode. Is that correct?

That is correct, the reason is that the worker SDK doesn't (at least yet) have a way to marshal the transaction over the process boundary.

They would need to remove SendsAtomicWithReceive = true. Then implement outbox and/or configure all handlers to be idempotent.

Correct

[TravisNickels]

I have raised a new PR to address these concerns:

• Add consistency section for isolated worker migration guide #6815