5
votes

I am thinking about Azure Functions on a Consumption Plan as an alternative to implementing something on Azure WebJobs on an App Service plan.

Recently with WebJobs we have been experiencing problems monitoring and identifying the app responsible for causing TCP port exhaustion on an App Service plan instance. When one app causes the port exhaustion, all apps on the same plan go down, and there is presently no way of diagnosing the culprit either via Azure Portal or via backend monitoring.

I am wondering how Azure Functions on a Consumption Plan differs in this regard, in terms of monitoring, mechanisms for scaling and impact on other functions on the same plan, and diagnosing the cause of such events.

1
I really doubt they do, since Azure Functions are basically a slightly different version of Web Jobs.4c74356b41
FYI - here is a document describing some of the sandbox limitations - github.com/projectkudu/kudu/wiki/…Chris Anderson-MSFT
Thanks, I am probably missing something but how does that link relate to the Consumption Plan?Sentinel

1 Answers

3
votes

Short answer: if you write your function code with horizontal scale in mind, you should find that port exhaustion has minimal impact on your overall throughput.

The consumption plan for Azure Functions works very differently to a dedicated App Service Plan. The problem you describe of one app impacting the performance of other apps makes sense on dedicated because all of those apps are running on the same set of VMs. For the consumption plan, your function app will run on many different VMs over time, based on the workload. A given instance of your function app might suffer from port exhaustion, but that should result in decreased throughput for that instance which in turn will result in more instances of your function app being activated. Also, multiple consumption based function apps on the same plan can and will run on different VMs and so they won't be competing for resources.

Of course there are situations where this wont work - if you have a timer trigger that is creating hundreds of outbound connections you could absolutely hit port exhaustion issues because timers don't scale out to multiple instances. The answer in this case is to have your timer add events to something that easily supports horizontal scale out such as a queue, topic or eventhub.

In terms of monitoring/diagnosis, the situation is basically the same as it is for dedicated (i.e. its difficult). But as I've outlined above, the need for this should be significantly diminished in the consumption plan. If you observe any behavior to the contrary, please let us know!