These are my favourite tips and tricks. These are only those who me and my colleguages have tried out.
Keep it slim
Functions should do one thing and they should do it well. When you develop it in C# and Visual Studio, it is so tempting to develop a “microservice” in a good way, you add interfaces, implement good patterns, and all of a sudden you get a monolith packaged in a microservice. If your function grows, stop, rethink. Better to see how it input and output bindings can be used. Also orchestration with Logic Apps or Durable Functions can help.
It might be an obvious one, but it is super easy to setup CI/CD for Azure Functions in Azure DevOps. Set it up as early as possible. Don’t rely on publishing from Visual Studio.
Different environments like Production and Staging (Test, UAT, QAT, verification), and DEV are not straight forward anymore, when everything is reactive and micro. But it is good to have at least two setups: one for Production and one for Staging. Especially separating the storage accounts has been proven to be a success story. You can have the same queue name, but different connections. Deploying to Staging and Production will be easier. The functions in different “environments” will write/read a queue with the same name but in different storage accounts.
I also find it convenient to have postfix in the azure function names, like collect-shipments-staging and collect-shipments-production.
If it is possible, use separate resource groups for the “environments”.
Tips for performance
One instance at a time
Use host.json to prevent parallelization
Add messages to a queue as output
Instead of adding queue messages in code, define it as an output. You can even add multiple messages. This saves you instantiating of CloudStorageAccount which is a good thing for performance.
Take Last Run into account
Just check the timer parameter: timer.Schedule.Last for the time when your Azure Function ran last.
This tip is from CloudBurst in Malmö in September 2019. Eventhough your function runs on a consumption plan, the chance is big that your code will run on the same server, which means that you can reuse some resources, like HttpClient.