PaaS
Last updated
Last updated
PaaS provides infrastructure and a software layer on which a web application is deployed.
Removes the need to know as much about the underlying servers, operating system, web server, and often the WSGI server.
Note: If not interested in deploying to a PaaS, check out the 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.
The following open source projects allow you to host your own version of a platform-as-a-service. Running one of these gives you the advantage of controlling and modifying the project for your own applications, but prevents you from offloading the responsibility of keeping servers running to someone else.
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.
Check if the application's functionality is working and tweak as necessary.
It's still your responsibility to ensure the web application framework and your app itself is up to date and secured. See the for further information.
and are Amazon Web Services' PaaS offerings. CodeStar is the newer service and recommended for new projects.
uses Kubernetes as a foundation for a custom self-hosted PaaS. Note that it was created by Eldarion, which had one of the first Python-specific PaaS offerings on the market around the time that Heroku was launched.
builds on Docker and has hooks for plugins to extend the small core of the project and customize deployments for your applications.
is open source PaaS designed to run on top of AWS services.
explains the abstract layer differences among "X-as-a-service" offering types and when to consider using each one.
by .
by Randall Degges is another great free resource about Heroku.
shows what current Amazon Web Services individual services are currently called and what they could've been called to be more clear to users.
covers high-level advantages and disadvantages of several self-hosted PaaS projects.
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 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 .
This series on DevOps Django by is great reading for using the Heroku service:
is a fantastic post that shows how to deploy to Amazon Web Service's own PaaS.
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 where they include their expenses from using a PaaS as well as other services.
The 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.
is a basic post on keeping developer sandbox accounts separate from production AWS environments.
is a detailed walkthrough for deploying an example Django app to Amazon Web Services.
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.
gives some quick back-of-the-envelope calculations on why running your applications on a PaaS is obviously going to appear more expensive if you do not take the cost of your own software engineers into the equation.
Two blog posts on using AWS Autoscaling in and provide a potential approach for making AWS cheaper via autoscaling. While these posts may look a bit more dfifficult than the Heroku dyno slider bar, if you're already using AWS this should prove fairly easy to configure.
Set up a content delivery network for your application's unless your PaaS provider already handles this deployment step for you.
