A customer asked me to look at the behaviour of functions on consumption plans when they are deployed into slots or need to warm up.
I thought I would publish what I found on here, as I have always struggled to find clear material around this.

Slots on a consumption plan VS slots on an app service plan…

When using an app service plan your solution is deployed on dedicated hardware.
This means that a function app maintains its scale after a slot swap.

In the consumption plan model this is not the case. Whenever you swap slots, the scale of the function app will be back down to a single instance.

This is not a massive issue, if you are not receiving a lot of traffic at the time of the swap; and no problem at all if you only need a single instance anyway.
However, it does become an issue if your function app runs at a large amount of instances in a given slot and then swaps to a different slot.

Because of the sudden reduction in instances the function app will be overwhelmed and will take time to scale. This will result in timeouts and connection errors for an amount of time.

Downstream apps need to account for this behaviour or will otherwise start to fail.

Keeping function apps warm…

A “cold start” describes the scenario where a function has not been run in a while and therefore no hardware will be available to allocate new user traffic to.

Over time the functions team has made a range of improvements in this area from a  platform perspective.

Nowadays, when your function starts, there is almost always a machine waiting with the function runtime already running.
If your function is completely cold, your code will still need to be loaded into memory.

Depending on how many dependencies you need to load in (both the code itself and any packages it consumes) there may still be a delay when a newly deployed function first starts.

It is recommended to keep functions small and efficient and to only consume dependencies that you really need.

If you want to keep a function “warm” you can use an AppInsights availability test or another piece of automation that continuously calls the function. This – in itself – is a bit of an anti-pattern though, as functions on consumption plans are mostly intended for scenarios with large-ish amounts of traffic.