Immutable, versioned Azure Functions?

[b-c-lucas]

Hi there,

I'm looking into expanding a project's serverless backend from only running on AWS Lambdas to also running on Azure Functions; however, in my scenario, a core requirement for doing so is the immutability of the deployed code.

From the AWS docs...

• Lambda concepts

When you invoke or view a function, you can include a qualifier to specify a version or alias. A version is an immutable snapshot of a function's code and configuration that has a numerical qualifier. For example, my-function:1. An alias is a pointer to a version that you can update to map to a different version, or split traffic between two versions. For example, my-function:BLUE. You can use versions and aliases together to provide a stable interface for clients to invoke your function.

• Lambda function versions

Qualified ARN – The function ARN with a version suffix. The following example refers to version 42 of the helloworld function: arn:aws:lambda:aws-region:acct-id:function:helloworld:42.

In thinking about how this could be accomplished with Azure Functions, I was immediately drawn to combining immutable blob storage with deployment slots; however, Consumption plan is limited to a single slot so I don't think my proposed solution will work in my scenario.

TL;DR: What's the closest thing to an immutable versioned Azure Function I can achieve under the Consumption Plan?

[Ved2806]

Thank you for your feedback! We will check for the possibilities internally and update you with the findings.

[b-c-lucas]

Thanks, @Ved2806 - any news on this front?

[Ved2806]

We are investigating this issue further, we will let you know about the findings soon.

[Ved2806]

Hi @mattchenderson Could you please help with this?

[b-c-lucas]

@Ved2806 @mattchenderson any findings you can share with me yet?

[mattchenderson]

Unfortunately, I don't think there's a clean solution here. I've seen some folks use run-from-package to point to versioned zip artifacts on their blob storage, but that doesn't really address the client working with this. APIM might help for HTTP workloads, but you'll still need the mapping to work with that backing artifact somehow - possibly just another app instance, though that's management overhead. It's worth noting that many other triggers would become competing consumers if pointed at the same source. Event Grid would be a way to work around that to some extent, though it requires a little bit more management as well.

[Ved2806]

Hi @brad-lucas Please let us know, does this helps? Is this issue resolved?

[b-c-lucas]

Thanks, @mattchenderson, for the reply.

I don't know that I'd consider the issue resolved, @Ved2806: if anything, I think this is a feature request.

I think this problem would become at least somewhat manageable if consumption plan could leverage deployment slots, with the function app owner needing to maintain the N slots' mappings to their appropriate code package: is there any technical reason consumption plan can't have multiple deployment slots?