PaaS Deployment Considerations

What type of django projects wouldn’t be suitable for PaaS deployment?

I know the benefits of PaaS are offloading the management of the server but what are some reasons where you can’t use PaaS and actually need a non-ephemeral file system or to access the infrastructure in a way that typical PaaS services restrict?

For example I believe you can still use celery, access hosted media files, I’m not seeing what the restrictions are of PaaS, thanks.

That’s the most limiting factor right there. Any Django project needing to run in an environment that requires direct server management is going to be difficult.

Some examples showing situations I work with regularly:

  • Our standard architecture includes a postfix installation. The Django app sends to the local postfix. Postfix then forwards the emails out to the wild. (There are a couple reasons for doing this - ability to do custom routing of outbound emails is just one.)

  • Modules requiring communication through non-standard protocols. We do a lot with SNMP over IPv6.

  • The need to integrate data exchanges with internal corporate systems behind a corporate firewall.

  • The ability to perform detailed diagnostics when problems occur, minimizing the time lost in the inevitable “finger-pointing” exercise that always happens when multiple parties are involved.

  • The need to integrate external processes with Django. (Cron jobs etc.)

  • The need to use a custom haproxy / nginx / uwsgi / PostgreSQL configuration.

Now, I recognize that some of these can be worked around in a PaaS-like environment, and a number of these aren’t strictly Django-related issues. But we’ve come to the conclusion overall that “offloading the management of the server” is not a net benefit for us.

[Edit: Almost forgot one more big one - the need to run the project in a non-internet-connected environment, such as an isolated lab.]

1 Like