[moritonal]

I used to describe most processes in Azure as "magical", and meant that word as dangerous. It worked like magic, which meant you had no idea how it worked. App Service Slot swapping was a good example of this, when several MS engineers couldn't explain how it worked.

Note how their docs don't give any technicals as to _how_ this tech works[1].

1. https://docs.microsoft.com/en-us/azure/azure-functions/funct...

[giaour]

> Note how their docs don't give any technicals as to _how_ this tech works[1].

From the linked page:

> Update routing: If all instances on the source slot are warmed up successfully, the two slots complete the swap by switching routing rules. After this step, the target slot (for example, the production slot) has the app that's previously warmed up in the source slot.

[moritonal]

To me those aren't technicals. Let's assume that by "routing rules" they implicitly mean IP Routing Rules. So what's swapped, the DNS name of the machines, the machine IP's are swapped or an insert into the ARP table? Does this mean that a live web-socket connection will swap to the new machine, or stay attached to the old one until flushed...

Hey, if you can make sense of it, sure, enjoy. I just know that we had a lot of issues when I used it last and would often beat our head against Kudo to try tracert to other devices to find the machine black-holing requests because the information wasn't shown in the Azure UI.

[giaour]

I've only used this feature with HTTP requests going to a function app, but my understanding was that there is a reverse proxy involved. I have an app with two slots, and both slot domains (<app name>.azurewebsites.net and <app name>-staging.azurewebsites.net) report the same external IP address. You can set up routing rules where a percentage of incoming traffic is forwarded to a specific slot, which would be hard (impossible?) to manage via DNS or ARP tables.