What is the difference between deploying a Flask application on an ec2 instance (in other words running your script on any computer) and deploying a Flask application via AWS Elastic Beanstalk? The Flask deployment documentation says that:
While lightweight and easy to use, Flask’s built-in server is not suitable for production as it doesn’t scale well and by default serves only one request at a time. Some of the options available for properly running Flask in production are documented here.
One of the deployment options they recommend is AWS Elastic Beanstalk. When I read through Amazon's explanation of how to deploy a Flask app, however, it seems like they are using the exact same server application as comes built-in to Flask, which for example is single threaded and so cannot handle simultaneous requests. I understand that Elastic Beanstalk allows you to deploy multiple copies, but it still seems to use the built-in Flask server application. What am I missing?
Elastic compute resources (AWS and others) generally allow for dynamic load balancing, and start more compute resources as they are needed.
If you deploy on a single ec2 instance, and this instance reaches capacity, your users will experience poor performance. If you deploy elastically, new resources are dynamically added as to ensure smooth performance.
TL;DR Completely different - Elastic Beanstalk does use a sensible WSGI runner that's better than the Flask dev server!
Almost, but not quite.
You can confirm that this isn't the case by removing the run-with-built-in-server section yourself - i.e. the following from the example:
You'll stop being able to run it yourself locally with
python application.py
but it'll still happily run on EB!The EB Python platform uses its own WSGI server (Apache with mod_wsgi, last I looked) and some assumptions / config to find your WSGI callable:
From Configuring a Python project for Elastic Beanstalk:
If you check out the docs for the
aws:elasticbeanstalk:container:python
namespace you'll see you can configure it to look elsewhere for your WSGI application: