The Azure Functions team has again joined us for another monthly live webcast by staying remote and safe.
In this live webcast Jeff Hollan, Pragna and Shelton Graves joined us to update the Azure Functions space’s latest happenings.
Without any further delay, let us jump in as there are tons of updates are waiting.
What’s new?
- .NET 2.2 auto-upgrade complete
- .NET 5 out-of-process preview: The push for .NET to be out-of-process is to get us to a point where host and runtime or functions host are completely decoupled from the user code. Users can bring in their own dependencies, and it is not tied to the .NET version that the functions host is running.
- Durable Functions 2.4: This comes with some of the new previews for distributed tracing.
- Node.js 14 public preview
- RabbitMQ triggers and bindings GA: It has been in public preview for a while and now it is made generally available. You can use it to send and receive messages using RabbitMQ API.
- Python 3.9 Preview
- Python performances best practices: Python performance is a little bit unique, so there is a new document recommended on best practices to make sure that you are building your app taking advantage of all the good stuff.
- KEDA 2.0 support in Azure Functions core tools
- Custom Handers GA: It lets you write functions in any language.
- Java Functions on Linux GA
Retry Policy
Pragna explained the retry policy support, which got a good response when announced.
Check out the retry policy documentation page.
Retry policy is a new feature that was introduced just before the holidays, and it is now in preview to gather more feedback & enhance the feature a little more.
This feature is mainly driven by user feedback, and one of the motivations has been the Event Hub trigger that doesn’t have built-in retries. So, while designing the feature, the team realized that having a generic retry policy that applies to any trigger will be quite useful instead of introducing something particular to Event Hubs. So, they went ahead and added this to the SDK.
A retry policy was introduced to be applied to any trigger, along with a few configurable options. As of now, we have 2 retry strategies, and they are
- Fixed delay
- Exponential backoff
Fixed Delay
It waits for a specific amount of time before retrying an execution.
Exponential Backoff
It starts and then randomly increases the delay up to a maximum delay. The execution completes either when it succeeds or when the number of retries is exceeded (Maximum retry count is configurable).
Another thing to note is that users can apply the retry policy at the function level or function app level. The retry policy at the function level takes precedence over the policy applied at the function host level.
In C#, this can be achieved by adding one of the new attributes, which includes FixedDelay & ExponentialBackOff. The code sample for all the languages is available in the public documentation for trial.
DEMO
Pragna demonstrates how it works in node.js. The below is a node.js function where there is a new retry function introduced in the function.Json, and it follows a schema where you can specify the delay strategy, maximum retry count & delay interval.
The strategy specified here is “fixed delay”, the delay interval is 3 seconds & the maximum retry count is set to 4. If there is a failure, the function execution would be retried 4 times with each retry spaced 3 seconds.
This function throws errors on the first few invocations and, then it will eventually succeed.
Let’s go ahead and execute this function to find what the logs look like
The invocations here have multiple executions, and each execution is assigned a new invocation id, but on the client-side, it’s all a single execution. So, instead of handling these transient errors on the client-side, a single function execution is doing it for you.
The id highlighted below is the invocation id that started, and then it failed with an error. Then, the next invocation id tells the next retry and then another one. Finally, the last one succeeds.
If the retry count is not persisted, and if a functions host instance crashes in the middle for any reason, then the retry is restarted. This is where the team is collecting feedbacks and enhancing the feature more.
One important thing to highlight is that few triggers have built-in retries such as Azure Queues, Azure Blobs. So, here the retry policy is applied on top of it. For example, an Azure Queue trigger’s default behavior would retry up to 5 times before it moves to a queue. If you apply the retry policy and set the maximum retry count to 2, then the message would be retried ten times.
Community Highlights
- Barbara Forbes – Deploy PowerShell functions with GH Actions
- Sumit Kharche – Creating .NET Azure Functions series
- Marc Duiker and Gwyneth Peña-Siguenza – Azure Functions University 👩🎓👨🎓
- Tom Kerkhove – Core tooling for KEDA 2.0
- Konstantin Lepeshenkov – Durable Functions Monitor
- Serverless Notes (They have got almost 50 best practice & tips in there) – PowerShell and Azure DevOps
What’s Coming?
- Retry policy retry context
- .NET 5 tooling and feature improvements (production-ready)
- Deployment Center preview (GA)
- Key Vault behind VNET in Premium Functions
Question & Answer Session
- About static web apps, any update on support for the root domain (like without www)?
- Any ETA on the integration of Key Vault reference with VNET restrictions?
- Is there a plan on Durable Functions for PowerShell? Like when GA will come up or when more flexible options will become available?
Durable Functions PowerShell GA is probably 2 to 3 months away.
We are working on it! It is not sure when it will land, but this is one of the top requests and Azure DevOps tooling support.
It is hard to say, but it might be at the end of February.
