The Azure Functions team has yet again joined us for another monthly live webcast by staying remote and safe.
In this live webcast, along with Jeff Hollan, Carrie and Ankit joined us to give a picture of the latest happenings in Azure Functions space.
Without any further delay, let us jump in as there are tons of update are awaiting.
What’s new?
- VS Code Azure Functions Extension 1.0 –This extension will now support custom handler functions which will allow you to create functions in any language that supports the HTTP server and then we also have OpenAPI triggers where people can use their API specification to generate functions directly using the VS Code extension.
- VNet Storage Account (West Europe) – We can now have VNet lock down storage in a premium account. It is in a very early stage of preview, but we have tested it and it works in West Europe right now where we are also tracking improvements to make it global as soon as possible. Also, check out the Azure Functions networking options document as there is a whole section on what you have to do to set this up.
- Retry policy (fixed duration & exponential back off) – There is now an ability to write a retry policy for your functions. You can configure a delay which is like to wait for 20 seconds and then retry it. You can also choose to go with exponential back off where you can start with 2 seconds, go to 4 seconds, and then go to 8 seconds. This feature also allows to retry indefinitely.
- Durable Functions 2.3.1 – Durable Functions 2.3.1 is now out. So, there are updates & getting some of those spooky bugs fixed around entities partition telemetry and more.
- Java 11 GA
Demo
Avoid spooky long startup
Today, we will see how to avoid long startups in the Function Apps as they are one of the spookiest things when you are developing applications.
Let’s get started
Today we will be performing some witchcraft where we will write a Function App that will have a function such that anytime it is triggered it will cook a potion for us.
So, to cook a potion in the function we need to get a heated cauldron and then add the ingredients.
- There is a Function App or Function project called WITCHCRAFT and one HTTP triggered function called cookPotion.
- This is the code for the function and when this function is triggered, it cooks a potion. When that function is executed it will get a cauldron from the cauldronProvider by calling a function & then adds the ingredients. Finally, it responds back saying your potion is ready.
- This is the function that we were calling from our Azure Functions in the previous step.
- To wrap up, the function gets the cauldron as an ingredient. So, here is going to be a 3 second startup penalty cost when we initialize the cauldron and then we add the ingredients which takes another 3 seconds but for any request after that, we already have the cauldron and should just keep adding the ingredients.
So, first request will probably take 6 seconds and the other ones will take 3 seconds.
Now, Ankit deployed this to a premium Function App, and ran some load tests to see how it performs. He gave it consistent load for a period of 6 seconds and kept increasing the load as time passed. Initially, it took about 6 seconds and then it goes back down to 3 seconds in few other calls, and then it jumps back right again to 6. This is because load increases or your Function App scales, or a bunch of new instances get added and that makes you pay the 6 second penalty again.
We can the cliffs that are formed for the startup cost in the below picture
What can we do to avoid these?
Let’s now talk about Warmup triggers which are not very new classes of triggers.
- So, warmup triggers as you expect triggers on a warmup event. What that means is these are the first thing that would be executed in any given instance that is running your function.
- Before any HTTP requests are sent to that instance, your function would have run this warmup trigger.
- For now, it is only supported in Premium SKUs.
Let’s take a brief overview of how things work to understand how warmup triggers are used
- Let’s say we have this front end which is the load balancer and we have 2 active instances and one pre-warmed instance which is a very normal scenario for Azure Premium Functions.
- As requests come in explicit among the active instances & as load increases what Azure does is that it will turn that pre-warmed instance into an active instance and then a new instance will come up.
- In the new instance, the first thing that happens is a warmup call. This is when the warmup trigger actually executes and then it gets marked as pre-warmed instance. So, all the active instances have already ran the warmup trigger.
- So, we see here how during a scale out a warmup trigger is executed in every instance.
Make use of warmup trigger in your code by creating a warmup function where you can have only one warmup trigger in a function project.
Similar to the test that was shown before, another one was done to the same Function App after deploying warm up trigger. The same exact load was given, but it never takes 6 seconds and there were no such peaks as before.
The blue line is when warmup triggers were used, and the orange line is when they were not used and had to pay that extra cost.
Community highlights
- Marc Duiker and Gwyneth Peña-Siguenza – Azure Functions University
- Omkar Khair – Solving Enterprise Integration with Azure Serverless
- Tom Meadon – Extracting keys from Functions using the REST API
- Bogdan Bujdea – Background processing in .NET Core: Azure Functions
- Rayis Imayev – Using Durable Functions in Azure Data Factory
- Marc Duiker – How to Write Safe Orchestrations
What’s Coming?
- Consumption <-> Premium tooling for migration
- Python 3.9 preview
- Node 14 preview
- RabbitMQ triggers and bindings GA
- Pull container images from ACR using MSI (Premium)
- Authentication features for Linux Consumption
Question & Answer Session
- Is the V2 platform upgrade still on target for this month and does it happen all at once across all subscriptions?
- Will it be possible to use .Net functions using the current V3 runtime or do we need to wait for Functions V4?
- Is V1 still supported?
We are doing a platform upgrade on the V2 runtime to provide security patches for that runtime and the upgrade will not happen all at once across subscriptions where it will be done in phases.
There are 2 options now, one is you can opt out of the platform upgrade and you can just keep running it in the mode it is now were you will not get any updates moving forward but if you are using .Net & especially if you have got any mail saying that you are using APIs that are to be impacted by this upgrade, then it is recommended to move to V3.
We are trying to make sure that you can keep using V3 & then still be able to run your .Net 5 apps. So, hope you wouldn’t have to wait for the next versions.
Yes! No plans and no announcements to deprecate it so you can keep using V1. But if you are not using .Net, it is recommended to upgrade to V3 because that’s where most of the investments and new features are lining up like the retry policy feature.
