Azure Function app: Good Practices
Azure functions allow one to author and execute small snippets of code (functions) without worrying about the infrastructure. Coding in azure functions can be done using JavaScript, C#, F#, Node.js, Python, PHP, batch, bash and PowerShell, and these codes are triggered by events.
Prerequisite knowledge:
· Knowledge of serverless architecture
· Basic understanding of Azure functions
Best Practices
“Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.” ― Kurt Vonnegut
As every developer abhor to rework on their code, a few proven practices help in delivering a reliable function app to the end-user. Here mainly we will be focusing on three areas, namely
- Prevent problems
- High Performance
- Defensive Coding
Prevent problems
· Monitoring your azure functions
For reliable infrastructure, its necessary to ensure that the functions are not getting timed out or throwing exceptions. So have a regular practice of checking for problems in the monitoring section of function app. This will help in
1. Realtime and historical logging
2. Viewing exceptions in logs
3. Getting better insights by using app insights service
· Asynchronous Programming
The code should be async without any blocking calls is the suggested programming practice for function app. The function apps’ runtime allows us to make the call async and returns the result in which we can just ‘await’ and handle exceptions seamlessly.
· Set Daily usage Quota
The consumption plan for the function app allows us to configure the daily usage quota in terms of memory (size calculated in GB) usage allowed per day.
If the application should not exceed the free tier(400,000 GB-s for consumption plan), we can configure approximately 1/31 of that, or 13,000 GB per day (assuming that only one function is there in our app service environment).
High performance
· Reuse the code from a common folder
There can be situations where a single piece of code needs to be shared in other Azure functions(say OAuth). In such cases, write your shared code inside a folder in the root of your Function App directory (e.g. “Shared”) and you can import the code in any functions.
By default, the files in that directory won’t be tracked for changes as we add as a custom shared folder. If you want to ensure that as soon as the files change in that “shared” directory, function app should identify the changes and recompile, then you can add your “Shared” directory to the watchDirectories list in host.json file.
· Avoid long-running functions
A function can have multiple dependencies; importing these dependencies into a function can cause an increase in load time and unexpected timeouts. So, breaking off large functions into smaller groups of function sets that work together and return responses quickly is recommended.
· Use Queues
An HTTP trigger or a webhook function requires an immediate response. So, to return an immediate response, one can use a queue trigger function where the HTTP trigger payload is passed into a queue. Considering the function requirements, one can choose between Storage Queues and Service Bus Queues.
· Avoid test functions
Since resources are being shared by all the functions in a function app, it is highly recommended to remove test functions in the Production environment.
Defensive coding
Defensive coding is a technique designed to ensure code correctness and reduce the number of bugs. The following are some of the defensive coding practices for azure function app.
· Azure functions are stateless
As azure function being stateless, write code in such a way that it assumes nothing about underlying VM’s or state of the system.
· Functions should be Idempotent
The notation of idempotence means that the operation’s result must remain unchanged when an operation is applied more than once. So, ensure that the state of the code remains the same after each function call.
Conclusion
Based on requirements and use-cases, one may choose between languages and runtime for the function app, but the above practices will remain as the baseline for function app.
