3👍
IMHO it comes down to what degree of change is possible, what the impact is, and how likely is it to happen. For example:
They will have a common userbase / database
Are you saying the same people use all the sites? If so then the risk profile will be less severe than if it was different people (say different organizations). Basically (through good appropriate architecture) you want to be de-coupling things so that when one thing changes it doesn’t have a massive impact on everything else.
If you run off the same instance then it’s easy to update every site at once (say you need to perform a maintenance patch on the base system), but on the other hand that can bite you (one group of users is happy to have the change but others aren’t – either because of the functional change or the downtime needed to apply the patch (for example).
Running the same code-base but in different instances is a larger maintenance overhead but removes a lot of risk associated with managing change; the conversation then becomes one of how to most efficiently maintain many instances of the same thing, rather than mapping risk associated with each time you make a change.
2👍
Actually, you can run those 2 (or more) sites under the same WSGI instance.
Depending on your version of Django and the features you need there are some drawbacks (like using threadlocals) but all in all those 2 solutions work pretty well.
Django 1.8+: https://bitbucket.org/levit_scs/airavata
Django <:1.7: https://bitbucket.org/uysrc/django-dynamicsites/overview (but it will probably require some fiddling depending on your version of Django)
What those 2 applications add compared to Django sites framework is the ability to easily serve sites on the same instance according to the domain name.
- Is there a way to access the context from everywhere in Django?
- How can I send signals from within Django migrations?