Multiple Function Apps with fewer Functions or few Function Apps with lots of Functions?

Question

We are currently deploying a single Function App per environment / per region in Azure. These Function Apps contain lots of Functions inside them. With the Service Plan set to consumption and therefore dynamic we are fairly happy with this as it reduces the operational complexity in our ARM templates.

We do wonder though, if it would be best to have more "function apps" per environment and spread our functions across them?

Is there any real benefit to doing this as we are under the impression performance will be scaled by the dynamic service plan?

Answer 1

Jordan,

The answer to the question would really depend on the type of workloads you're handling with your functions.

Although the scale controller will handle scaling to meet demand, functions within a Function App do share resources on each instance, and a resource intensive (either memory or CPU) may impact other functions in the same app.

There is also no process isolation between functions in the same Function App. They all run in the same process (except for some of the scripting languages like Python, Batch, etc) and in the same App Domain. So if isolation is a factor (for reasons like security, dependency management, shared state, ect.), you may want to consider splitting functions into different apps.

Versioning and deployment is another factor worth considering, as the unit of deployment is a Function App (and not the individual functions)

With that said, if you're not running into resource consumption issues with your workloads and the issues mentioned above are not a concern, as you pointed out, running multiple functions in a single function app significantly simplifies management, so I wouldn't change that approach if there's no need to do so.

I hope this helps!

Answer 2

My main concern was already pointed out by Fabio. All your functions are running in the same process. So, if one of the functions is running into a timeout, that the host will be shut down (incl. restart of course). This would also affect your other functions. I had this problem with a service bus trigger by calling a stored procedure, which sometimes reached the timeout threshold. The restart of my function app took about 7 minutes and the real-time data was not really real-time anymore ;-)