A platform-as-a-service (PaaS) provides infrastructure and a software layer on which a web application is deployed. Running your web application from a PaaS removes the need to know as much about the underlying servers, operating system, web server, and often the WSGI server.
Note: If you are not interested in deploying to a PaaS you can move ahead to the WSGI servers section.
The PaaS layer defines how the application accesses resources such as computing time, files, and external services. The PaaS provides a higher-level abstraction for working with computing resources than deploying an application to a server or IaaS.
A PaaS makes deployment and operations easier because it forces the developer
to conform applications to the PaaS architecture. For example, Heroku looks
for Python's requirements.txt file in the base directory of the repository
during deployment because that is the file's de facto community standard
location.
If you go the PaaS route, you can skip configuring an operating system and web server prebaked into PaaS offerings. PaaS offerings generally start at the WSGI server layer.
Although PaaS offerings simplify setting up and maintaining the servers, operating system, and web server, developers still have responsibilities for other layers of their web stack.
While it's useful to know the operating system that underpins your PaaS, for example Heroku uses Ubuntu 10.04, you will not have to know as much about securing the operating system and server level. However, web applications deployed to a PaaS are just as vulnerable to security breaches at the application level as a standard LAMP stack. It's still your responsibility to ensure the web application framework and your app itself is up to date and secured. See the security section for further information.
PaaS bakeoff: Comparing Stackato, OpenShift, Dotcloud and Heroku for Django hosting and deployment by Nate Aune.
Deploying Django by Randall Degges is another great free resource about Heroku.
AWS in Plain English shows what current Amazon Web Services individual services are currently called and what they could've been called to be more clear to users.
5 AWS mistakes you should avoid explains how common beginner practices such as manually managing infrastructure, not using scaling groups and underutilizing instances can create problems you'd be better off avoiding altogether.
Heroku's
Python deployment documentation
provides clear examples for how to work with virtualenv, pip and
requirements.txt to get a applications deployed to their platform.
Miguel Grinberg's Flask tutorial contains an entire post on deploying Flask applications to Heroku.
This series on DevOps Django by Randall Degges is great reading for using the Heroku service:
Deploying a Django App to AWS Elastic Beanstalk is a fantastic post that shows how to deploy to Amazon Web Service's own PaaS.
Deploy your hack in 3 steps: Intro to AWS and Elastic Beanstalk shows how to deploy a simple Ruby Sinatra app, but the steps are generally applicable to Python web apps as well.
Are you wondering what it will cost to deploy a reasonable sized production app on a platform-as-a-service like Heroku? Check out Cushion's transparent costs list where they include their expenses from using a PaaS as well as other services.
The beginner's guide to scaling to 11 million users on AWS is a useful list of services you'll need to look at as you grow an application from 10 to 100 to 1000 to 500,000 and beyond to millions of users.
How to Separate Your AWS Production and Development Accounts is a basic post on keeping developer sandbox accounts separate from production AWS environments.
Deploying a Django app on Amazon EC2 instance is a detailed walkthrough for deploying an example Django app to Amazon Web Services.
How much is Spotify Paying Google Cloud? provides some insight into how Spotify runs all of their infrastructure on Google Cloud and posits what they may be paying to run their service.
Two blog posts on using AWS Autoscaling in Automatic replacement of Autoscaling nodes with equivalent spot instances and Autoscaling nodes: seeing it in action provides a fairly complicated but potential approach for making AWS cheaper, depending on whether the majority of your cost is in compute nodes.
Review the potential Python platform-as-a-service options listed above.
Sign up for a PaaS account at the provider that appears to best fit your application needs. Heroku is the PaaS option recommended for starters due to their detailed documentation and walkthroughs available on the web. However, the other options are also viable since their purpose is to make deploying applications as easy as possible.
Check if there are any PaaS-specific configuration files needed for your app to run properly on the PaaS after it is deployed.
Deploy your app to the PaaS.
Sync your application's configuration with the database.
Set up a content delivery network for your application's static content unless your PaaS provider already handles this deployment step for you.
Check if the application's functionality is working and tweak as necessary.
Searching for a complete, step-by-step deployment walkthrough? Learn more about The Full Stack Python Guide to Deployments book.
