迁移AWS Lambda Python2.7至Azure Functions时遇对象未实例化错误

Hey there! Let's break down what's going on here and fix that frustrating error you're seeing. The root cause is simple: you created a JavaScript-based Function App, and even after deleting the JS files and adding your Python code, the underlying runtime configuration is still set to JavaScript. Unlike AWS Lambda (where you can set runtimes per function), Azure Functions ties the runtime language to the Function App level—so it's looking for a JS entry point that no longer exists, hence the null reference error.

Here's how to fix this properly, tailored to your AWS Lambda background:

1. Create a Python Function App (The Right Way) #

Skip the workaround of starting with a JS app—create a Function App specifically configured for Python:

• When creating a new Function App in the Azure Portal:
  • Under Runtime stack, select Python (note: Python 2.7 is deprecated in Azure Functions, so pick a supported 3.x version like 3.8, 3.9, or 3.10. You'll need to upgrade your Python 2.7 code to be compatible, which mirrors AWS Lambda's end-of-support for Python 2.7)
  • Choose the Consumption Plan—this is the closest equivalent to Lambda's serverless pay-per-use model
  • Ensure a Storage account is configured (Azure Functions requires this for state management and logs, similar to Lambda's underlying storage infrastructure)

2. Fix Your Existing JS Function App (If You Don't Want to Start Over) #

If you'd rather reconfigure your existing app instead of creating a new one:

• Go to your Function App in the Azure Portal
• Navigate to Configuration > General settings
• Change the Runtime stack to Python, select your target 3.x version, and save
• Wait for the app to restart, then delete any remaining JS files and add your Python function files

3. Structure Your Python Function Correctly #

Azure Functions expects a specific folder structure (similar to Lambda's handler structure, but more explicit):

• For a single function, your folder should look like this:

  MyFunctionApp/
  ├── MyPythonFunction/
  │   ├── __init__.py
  │   └── function.json
  └── requirements.txt
  

• In __init__.py, define your function handler (analogous to Lambda's handler function):

  import azure.functions as func
  
  def main(req: func.HttpRequest) -> func.HttpResponse:
      # Your migrated Python code goes here (updated to Python 3.x)
      return func.HttpResponse("Hello from Azure Functions!", status_code=200)
  

• The function.json file tells Azure how to trigger your function—for an HTTP trigger (like a Lambda API Gateway trigger), use this template:

  {
    "scriptFile": "__init__.py",
    "entryPoint": "main",
    "bindings": [
      {
        "authLevel": "anonymous",
        "type": "httpTrigger",
        "direction": "in",
        "name": "req",
        "methods": ["get", "post"]
      },
      {
        "type": "http",
        "direction": "out",
        "name": "$return"
      }
    ]
  }
  

• Use requirements.txt to list any dependencies (just like how you'd use Lambda layers or pre-install packages locally before deployment)

4. Test Locally First (Avoid Portal Headaches) #

Think of Azure Functions Core Tools as your Azure equivalent of the AWS SAM CLI:

• Install Azure Functions Core Tools
• Run func init MyFunctionApp --python to create a new Python app locally
• Add your function with func new --name MyPythonFunction --template "HTTP trigger"
• Replace the sample code with your migrated Python logic (updated to 3.x)
• Test locally with func start—this will catch configuration errors before you deploy to Azure

内容的提问来源于stack exchange，提问作者Soumyajit Dutta