Last time (link) I described how to create Python 3.6 environment for Azure Functions deployments. Basing on what I described, I've had an occasion to deploy this kind of envs in (near)production projects. In most cases It was working well. But...
In one of my open projects - a project based on Azure Logic Apps and Functions, where Functions were going to act as a XML parser "on demand" - Python 3.6 on Functions failed under the pressure of (not so big) workload. I was sending a bunch of HTML/XML files to Function, which was supposed to parse them. Functions were trigerred tens of times per day (not houndreds or thousands). Functions were generating WebJob-SDK-related exceptions - without any explanation what was the root cause of the failure.
After some research and asking some questions to Python guys in Microsoft, I can say that Python support on Azure Functions is really experimental. Not because of lack of care, but because of the language support architecture.
Today, if we are using Python on Azure Functions (and it does not matter if we are using built-in interpreter or custom interpreter) it works by launching an instance of python.exe on every function invocation. "This works fine when there is a low volume of calls, but it does not scale at all under load." - and it's official link.
So... what to expect?
Let's clarify some things first:
Two versions of the Azure Functions runtime are available. The 1.x runtime is GA. It's the only runtime that is approved for production applications. The 2.x runtime is currently in preview, so the languages it supports are in preview. The following table shows which languages are supported in each runtime version.
The 2.x runtime doesn't support experimental languages. In 2.x, we will add support for a language only when it scales well and supports advanced triggers.
We are all (Python on Azure Users) waiting for GA Python support on Azure Functions 2.0. I cannot tell when it will be done, but topic is discussed on Azure Advisors group and there is a slight glimpse of hope for having it sooner rather than later. Python language provider for Azure Functions is a frequent request from users' and clients' sites, so it should be high on the backlog.