Endpoint hosted in Azure function app. Deployment slots considerations

Architecture & Design
,
1

Our company’s strategy is to move to endpoints hosted in Azure Function apps. We already have a couple of endpoints running this way, but haven’t utilized deployment slots for deployments yet (blue/green deployments with production slot swapping). We are doing full Infrastructure as Code.

Does anyone have any experience with this approach? Any pros/cons or specific considerations? Will it work with traffic percentages between the two slots or is that only for http based triggers?

2

We never got around to fully explore this, but now we really need to conclude about how to solve this. Consider the case where we have an endpoint hosted in an Azure Function app. The app has 2 deployment slots, one for production and one for staging. What we envision as a solution is

  • Both slots use the same database and Azure ServiceBus namespace
  • To differentiate messages sent from “Staging”, we first add a message mutator for outgoing messages to add a header “environment”.
  • We then add a custom pipeline behaviour, like the example here: Aborting Pipeline execution • NServiceBus • Particular Docs . If the “environment” header of the message being handled does not match the environment the endpoint runs in we stop further processing of the message.

Is this a viable approach or are there any pitfalls here?

3

We are concerned about your proposed solution. NServiceBus endpoints consume from their queues in a competing consumer pattern. This means that even though you have mutators and behaviors, there is no way to guarantee messages for one environment will not be picked up in another. With a behavior that drops messages, this would result in message loss.

It is unusual for a staging environment to operate in a production environment, our further concern would be that even if you could manage the logic in a way that prevents message loss, it is still dangerous code being deployed in production. A regression or a configuration mishap could still lead to message loss in production.

In general we would recommend using separate Azure Service Bus namespaces and databases for each environment.

4

Hi Bob and thank you for a good answer. I was afraid this was not a feasible approach because of the “competition” between the endpoints for consuming messages on the same queue.

The reasoning for wanting this behaviour however was to get the staging environment as close to production as possible, since we want to use blue-green deployment to simply switch traffic and message handling between the staging and production slot. And also to be able to test the staging-for-production deployment slot before switching to be super-confident that everything works as expected.

We’ll revert to having a staging environment azure servicebus namespace and use the production database (or a separate clone of the production database).