4

I've got a Flask based web application that deploys to AWS Lambda via Zappa. All is well and good.

The Flask documentation says:

While lightweight and easy to use, Flask’s built-in server is not suitable for production as it doesn’t scale well. Some of the options available for properly running Flask in production are documented here.

On a stand-alone server, Python is single threaded (Global Interpreter Lock (GIL) etc) and therefore doesn't handle multiple requests well without due care and attention.

On AWS Lambda (and presumably other FaaS infrastructure) each HTTP requests gets a separate Python instance, so the GIL is not an issue and Lambda takes care of scaling by using multiple function invocations.

Therefore, is using a WGSI container (Gunicorn, uWGSI, etc) so strongly recommended when running on AWS Lambda? Why or why not?

Some factors I can guess might be relevant include:

  • cost
  • resources (e.g. database connections)
  • bugs
  • start up performance
  • per request overhead
afaulconbridge
  • 1,107
  • 9
  • 21

1 Answers1

7

When the documentation talks about "Flask's built-in server", it's talking about the server that you get when you run the command flask run (or in older applications running a command like python my_application.py with a line in the main function like app.run()).

When you run flask on Lambda (using Zappa or another solution like aws-wsgi or serverless-wsgi), you're not using Flask's built-in server or any server at all; the wrapper code (in Zappa or anything else) is translating the lambda event to a call to your WSGI application.

Since there is no actual WSGI server, it's not possible to use Gunicorn, uWGSI, etc (well, it may be possible, but it would be very convoluted).

Tim Ludwinski
  • 2,704
  • 30
  • 34