Chapter 10 ■ http ServerS
176
With PaaS, much of the tedium of establishing and running an HTTP service is automated away—or, at least,
devolves upon your PaaS provider rather than upon yourself. You are exempted from having to rent servers, providing
them with storage and IP addresses, configuring root access with which to administer and reboot them, installing the
correct version of Python, and copying your application to every single server along with the system scripts necessary
to start your service up automatically after a reboot or power failure.
Instead, these burdens are assumed by the PaaS provider that might install or rent thousands of machines,
hundreds of database servers, and many dozens of load balancers in order to serve its customer base. Having
automated all of these steps, all that the provider needs is a configuration file from you. The provider then can add
your domain name to its DNS, point it at one of its load balancers, install the correct version of Python and all of your
Python dependencies inside an operating system image, and have your application up and running. The process can
make it easy to push new source code to them and easy to roll back if the new version of your application seems to
generate errors when faced with real users. You get away without having to create a single /etc/init.d file or reboot a
single machine.
Heroku is a current favorite in the PaaS space and provides first-class support for Python applications as part of
their ecosystem. Heroku and its rivals are especially valuable for small organizations that lack the expertise or the time
in-house to set up and administer tools such as load balancers.
The emerging Docker ecosystem is a potential rival to Heroku because it lets you create and run Heroku-style
containers right on your own Linux machine, making it much easier to test and debug them than when every line of
configuration that you want to tweak involves a long and slow push and rebuild on Heroku.
If you have only a vague familiarity with PaaS, you might expect such a service to take your WSGI-ready Python
application and get it running for you without any additional effort.
It turns out that this is not the case. Under Heroku or inside a Docker instance, you will still have the
responsibility of choosing a web server.
The reason for this is that while PaaS providers provide load balancing, containerization, version-controlled
configuration, container image caching, and database administration, they still expect your application to provide the
gold standard in HTTP interoperability: an open port to which the PaaS load balancer can connect and make HTTP
requests. And to turn your WSGI application or framework into a listening network port, you are obviously going to
need a server.
Some developers, satisfied that the PaaS service is going to be doing load balancing for them, select a simple
single-threaded server and put the PaaS service in charge of spinning up as many instances of their application as
they need.
But many developers instead opt for Gunicorn or one of its competitors so that each of their containers can have
several workers running at once. This makes a single container able to accept several requests in case the round-
robin logic of the PaaS load balancer makes it back to the same container before its first request is finished—which is
a particular problem if some of the resources offered by your service might take several seconds to render and cause
subsequent requests to be queued up until the first is complete.
Note that most PaaS providers do not make any provision for serving static content, unless you serve it from
Python or else add Apache or nginx to your container. While you could design your URL space so that static resources
come from an entirely different hostname than do dynamic pages and host those static resources elsewhere, many
architects prefer to be able to mix static and dynamic resources in a single namespace.
GET and POST Patterns and the Question of REST
Dr. Roy Fielding, one of the principle authors of the current HTTP standards, wrote his Ph.D. dissertation on its
design. He coined the term Representational State Transfer (REST) to name the architecture that emerges when all of
the features of a hypertext system like HTTP are operating at full tilt. His dissertation is online if you want to consult it.
Chapter 5 is where he builds up the concept of REST from a series of simpler concepts.
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm