Posted by A concise way to describe serverless is to steal a quote from Todd Howard’s E3 presentation in 2015: it just works.
In essence, you upload your code to Azure Functions and its runtime takes care of the rest. This approach works perfectly nine times out of ten. There are some occasions, however, where you need to adjust the knobs and dials of the runtime environment.
Most configurable settings are controlled through the host.json file. This file is at the root of every functions project. It starts out as an empty JSON document within which you add customizations.
Once a Function app is deployed, the contents of host.json are visible in the portal by clicking on the Function app in question, and then on Function app Settings.
Every configuration setting is explained in detail on Microsoft Docs. While many of them can be handy, there are only a handful that you need to know early on. So let’s have a look at those settings, what they do, and why they are useful.
functions
A Function app project can accommodate a large number of functions. By default, the functions host starts all the functions in the project. Oftentimes, you only want to run one or two functions at a time, typically for testing purposes.
The functions entry lets you do just that by telling the runtime which functions to start. Any function that isn’t listed will not execute.
{
"functions": [
"FunctionToRun",
"AnotherFunctionToRun",
"AndAnotherFunction"
]
}
Microsoft recommend using this setting only for your local hosting environment. But if you commit the host.json file with this entry, dotnet publish will include it as part of the deployment package. That means that when you deploy the package to Azure, the same setting will apply, and that’s not so good. You can avoid this from happening by performing a JSON substitution on the file as part of your build pipeline.
functionTimeout
There are two different plans for Azure Functions: Consumption and App Service. On the App Service plan, timeouts aren’t a concern. On the consumption plan, the default timeout for functions is five minutes, and can be extended up to ten minutes.
The functionTimeout frequently needs to be changed for functions that react to Service Bus messages. That’s because background worker functions typically perform long-running tasks that go beyond the default five minute timeout. Which brings me to a related parameter for the service bus trigger…
servicebus
By default, a message received from a Service Bus queue is locked for a five-minute window. During that time, no other instance of the function can receive the message.
But if your function is still processing five minutes later, the message once again becomes visible, and another running instance can receive it. This isn’t usually the desirable behaviour, since it would result in duplicate processing.
Luckily, you can avoid this from happening by changing the maxAutoRenewDuration parameter. The parameter tells Service Bus to automatically renew the lock on the message for the specified duration, ensuring that no one else can receive the message during that time.
The default value is five minutes, but my rule of thumb is to set the maxAutoRenewDuration to the same value as the function’s timeout.
logging
There are many aspects of the logging behaviour that can be controlled. One of the most interesting is the ability to set different log levels per function.
For the most part, you want the log level of your functions to be set to a clutter-free level, typically Information. You can accomplish this with the default property of the logging object.
"logging": {
"logLevel": {
"RoverAirways.Scheduler": "Verbose",
"default": "Information"
}
}But what if one of your functions is acting up, and you need to dig deeper? This is where per-function log level comes in to play. You can tell the functions runtime to log verbosely only for that function, avoiding the clutter that turning up the logging can generate.
Lots More To Discover
Of course, there are many other settings that can be changed. This is the essential list that I show developers when getting them started with Azure Functions.
You’re not limited to what’s in the host.json file either. There are other Function app platform settings that can be tweaked from the Azure portal. Have a look, you might find something pertinent to your functions.
Marc Roussy 