How close are development webservers to production webservers?

Question

Most python frameworks will have a development webserver of some kind that will have a warning that it isn't for use as production servers. How much different do they tend to be from their production equivalents?

I haven't quite decided which framework to go with, much less what production server to use, so it's kinda difficult for me to pin this down to a "compare development server x to production server y." So with that said, let me make the question a little bit more precise: In your past experience with a python framework, how much time did you have to spend getting your application up and running with a production system once its been developed on a development server? Or did you skip the development server and develop your app on a server that's more like what you will use in production?

Answer 1

Generally, they are same in terms of the settings which are required to run the applications which include the environment setting.
However, the clients genereally have dev systems which are less powerful in terms of the processing power and other h/w resources. I have seen using them virtual servers in dev evironment since they generally have multiple projects going on in parallel an this helps them reducing the cost.

Answer 2

Ideally, the logical configuration of the development, test, and production server should be the same. They should have the same version of OS, web server, and all other software assets used to run the application. However, depending on how strong your environment things will crop - hand copied images/scripts etc on the dev machine that do not make it through test and or production.

to minimize this you probably need some sort of push script that can move you from one stage to the next, ie PushVersionDev, PushVesionTest,PushVersionProd. ideally this should be the same script with parameters for target server(s) representing all that you need to move the app through the various stages.

I would recommend a read of Theo Schlossnagle's book Scalable Internet Architectures for more ideas on the matter.

To answer your question directly....once you get your application tested and implemented, the time to roll to productoin is not great - deploy OS, web server, supporting frameworks if they need installation, application and you are good to go. From bare metal I have seen linux servers go online in 1 hour, windows about 90 minutes. if you have the OS and web server going even less..minutes.

Answer 3

The lower environments should try to match the production environment as closely as possible given the resources available. This applies to all development efforts regardless of whether they are python-based or even web-based. In practical terms, most organizations are not willing to spend that type of money. In this case try to make at least the environment that is directly below production as close to production as possible.

Some of the variable to keep in mind are:

• many times there are multiple machines (app server, database server, web server, load balancers, fire walls, etc) in a production. Keep these all in mind.

• Operating Systems

• number of CPUs. Moving from a one CPU lower environment to a multi core production environment can expose multi-threading issues that were not tested

• load balancing. Many times lower environments are not load balanced. If you are replicating sessions (for instance) across multiple production app servers, you should try to do the same in a lower environment

• Software / library versions

Answer 4

I develop with django. The production server we have is remote, so it's a pain to be using it for development. Thus, at first, I created a vm and tried to match as closely as I could the environment of the prod server. At some point that vm got hosed (due to an unrelated incident). I took stock of the situation at that time and realized there really was no good reason to be using a customized vm for development. Since the resources available to the app weren't the same as the prod server, it was no good for timing queries anyway (in an absolute sense).

That said, I now use django's built in dev server with sqlite for development, and apache/wsgi and postgresql for production. As long as the python dependencies are met on both sides, it's 100% compatible. The only potential problem would be writing raw sql instead of using the orm.

Answer 5

Your staging environment should mimic your production environment. Development is more like a playground, and the control on the development environment should not be quite so strict. However, the development environment should periodically be refreshed from the production environment (e.g,. prod data copied to the dev db, close the ports on dev that are closed on prod, etc.).

Ideally, dev, stage, and prod are all on separate machines. The separate machines can be separate physical boxes, or virtual machines on the same physical box, depending on budget/needs.