In this article, I’m going to compare the Azure Functions latest V4 and V3 and share some main differences and highlights of the new version. Hope this article will give some insights about what to notice in the latest version.
Firstly, all the changes can be found in this breaking change doc, also we have a Github post to track the changes. I’m not going to go into details about each difference mentioned in the post, but I will highlight some breaking changes below.
So, what’s changed?
Azure Function Proxies → Azure API Management
The use of Azure Function Proxies has been decommissioned in V4, and it will be replaced by APIM(Azure API Management) instead. APIM will come as a separate service with more functionalities and built-in security sets, version controls, and more. For details, please read this APIM doc.
The main difference is that the APIM will charge as a separate service, while the Function proxies will be counted within the Azure Function itself. Please refer to the below form to get more detailed info:
| Azure Proxies | Azure API Management | |
| Basic Proxy Settings | Yes | Yes |
| Security | N/A | Authenticated with OAuth+OpenID. APIM can also bind client certificates to have enhanced security. |
| Integration Services | Can only work with Azure Functions. | Support integrate with multiple services, including Logic App, Container App, etc. |
| Version Control | N/A | Rich Support with Tags and Versions. Refer to APIM Version Control for more info. |
| Calculate Price By | Data usage | Execution Time & Data Usage. Pricing page will show the details. |
| Pricing Details | It will be calculated with Azure Functions. | APIM dedicated service pricing |
| Recommended Scenarios | Don’t require much integration with other proxy services. | Large API management with various services and enhanced security. |
Extensions version upgrade
By default, Azure Functions will automatically take care of the extension versions. However, if you manually update the Azure Function version via AppSettings, some of the extension versions may require a manual upgrade.
The minimum required function extension version is as follows:
For .NET user
| Extension | Minimum Version |
| Microsoft.Azure.WebJobs.Extensions.Storage | 4.0.4 |
| Microsoft.Azure.WebJobs.Extensions.ServiceBus | 4.2.1 |
| Microsoft.Azure.WebJobs.Extensions.EventHubs | 4.3.0 |
| Microsoft.Azure.WebJobs.Extensions.DurableTask | 2.4.1 |
| Microsoft.Azure.WebJobs.Extensions.CosmosDB | 3.0.9 |
| Microsoft.Azure.WebJobs.Extensions.EventGrid | 2.1.0 |
| Microsoft.Azure.WebJobs.Extensions.RabbitMQ | 1.0.0 |
| Microsoft.Azure.WebJobs.Extensions.Kafka | 3.2.1 |
For non .NET users
You should update host.json file to reference extension version ≥ 2.0 bundle.
Share storage account with same truncated hostname is not permitted
As this Github post mentioned, when you create the Function App, the name will be truncated if the length is more than 32 characters. If the truncated hostnames are the same, it will cause the hostID collision error, and therefore it is not allowed to use the same storage account.
The reason for this change is to prevent possible errors introduced from the sharing of the storage account. And by changing the hostID collision into error rather than warning, such behavior would get blocked in the first place and will prevent from causing further impact.
Actually, we do not recommend this sharing even with different function apps, due to it may trigger some unexpected behaviors, but such behavior is still allowed in Function V4, which is also mentioned in this post: Share storage accounts.
Update the Key Vault secret provider to use Azure.Identity
The old secret provider library, Microsoft.Azure.KeyVault has been replaced by the new Azure.Identity & Azure.Security.KeyVault.Secrets library in Azure Function V4. For details, please refer to this Github post.
Certain app settings will need to change to the following values:
Old
| App Settings | Value |
| AzureWebJobsSecretStorageType | keyvault |
| AzureWebJobsSecretStorageKeyVaultName | Key Vault name |
| [Optional] AzureWebJobsSecretStorageKeyVaultConnectionString | Key Vault connection string |
New
System-assigned managed identity
- Enabled system managed identity inside your Functions App
- Give the created identity Key Vault secret permissions through access policies
| App Settings | Value |
| AzureWebJobsSecretStorageType | keyvault |
| AzureWebJobsSecretStorageKeyVaultUri | Key Vault URI |
User-assigned managed identity
- Create a user-assigned managed identity
- Assign the user-managed identity to your Functions App
- Give the created identity Key Vault secret permissions through access policies
| App Settings | Values |
| AzureWebJobsSecretStorageType | keyvault |
| AzureWebJobsSecretStorageKeyVaultUri | Key Vault URI |
| AzureWebJobsSecretStorageKeyVaultClientId | User managed identity client ID |
App registration
- Create an AAD app registration
- Give the created identity Key Vault secret permissions through access policies
| App Settings | Values |
| AzureWebJobsSecretStorageType | keyvault |
| AzureWebJobsSecretStorageKeyVaultUri | Key Vault URI |
| AzureWebJobsSecretStorageKeyVaultTenantId | App registration tenant ID |
| AzureWebJobsSecretStorageKeyVaultClientId | App registration client ID |
| AzureWebJobsSecretStorageKeyVaultClientSecret | App registration client secret |
The reason for this change is that the previous authentication library has been deprecated, which could lead to major security concerns in the future. In order to avoid this, please follow the guidance above to change the App Settings.
Language supported version change in Azure Function V4
The language versions will vary when choosing different function runtime versions, please refer to the below form:
| Function Runtime Version | In Process | Out-of-Process |
| Function 4.x | .NET 6.0 | .NET 6.0 |
| Function 3.x | .NET Core 3.1 | .NET 5.0 |
| Function 2.x | .NET Core 2.1 | N/A |
| Function 1.x | .NET Framework 4.8 | N/A |
You may notice an interesting part of in-process and out-of process. What’s the difference between them?
-
The in-process app will run as a class library in the same process as the host. It is the default way as you develop and deploy to the Azure Functions. In this way, the .NET function app version should be the same as the function runtime.
-
The out-of-process (aka isolated process) app, will have the ability to run even when the version is not natively supported in the future function runtime. It will give you a more flexible way to use different language versions. If you would like to use the isolated process app, please follow the following steps:
- Basic project files, including host.json, local.settings.json, C# project file(.csproj), and Program.cs file that’s the entry point of the app.
- Add the Application Setting to your project. For Linux/Windows function app, the values are different:
- Windows: FUNCTIONS_WORKER_RUNTIME = dotnet-isolated
- Linux: linuxFxVersion = DOTNET-ISOLATED|6.0
It should work fine after applying the changes mentioned above.
Of course, there are other changes made in the new version of the Azure Functions, and the post will just focus on some of the changes. If you would like to ask anything related to the Azure Functions, please feel free to leave the comments, and I would be glad to help.
Posted at https://sl.advdat.com/36Rd8Eihttps://sl.advdat.com/36Rd8Ei