I want to do a Blue Green deployment from staging to production on azure.

Our web application maintains a long running EventSource/SSE connection to our back end server. During a swap from staging to production, these long running connections must not be interrupted.

In other words, if the production server is initially the blue server, any connections to the blue server must continue on the blue server during and after the promotion of the green server to production. New connections will be routed to the green server.

My own testing suggest that Azure Cloud services (classic) VIP swap does not work this way, at least with https connections. During the swap, existing connections are terminated. Upon further reading of How to Manage Cloud Services, it seems there is no guarantee that existing connections will be maintained.

As described in the last section, a deployment swap is typically very fast since it is just a configuration change in the Azure load balancer. In some cases, however, it can take ten or more seconds and result in transient connection failures. To limit impact to your customers, consider implementing client retry logic.

The first part of my question is whether what I have described above is the expected behaviour of a VIP swap or should it be maintaining existing connections.

The second part of the question is what is the recommended way of achieving my goal on Azure. I have been unable to find official documentation from Azure that details this scenario with detail on existing connections.

Please note, I want to avoid DNS based solutions. I am looking for something further down the network stack. Something similar to using Elastic Load Balancer on AWS for a blue green deployment as detailed here


It seems that drain stop is not supported on azure load balancer .

The other method using a custom health check could work but is a bit kludgy

In fact, the health check method is pretty impractical for removing a whole cluster of servers at once so I have come up with a workaround.

I tried setting up an https redirector that could be easily switched between blue and green by an environment variable but this resulted in the Origin for cors being set to null and allowing a null origin is not recommended.

In the end the solution I am opting for is a configuration service that will be queried for the latest endpoint. In my situation that will work, but I can see that it could be a problem for many implementations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.