My team and I are having a hard time defining the architecture for my backend environment using Django. To contextualize a little, we built an application similar to an App Store, for all our developments to be displayed, with the difference that it also launches the apps.
To maintain all the information about this apps, we built this backend in Django that is basically a database accessed through an API from the App Store, and a Django Admin website to register the informations to be delivered in the API (the one Django automatically generates).
The thing is, today, we have only one technology involved and therefore only one database and one Django Admin. But, other areas in our company want to use this architecture we built, with other apps and therefore other informations, not related to our environment.
The question is, should we deploy several Djangos in different ports of our server? Or should we try to create a dependency in our models to a "Technology" related to it? (For this option it is important to note that our architecture is complex and highly nested). Or maybe should we use the multiple databases provided from Django?
Has anyone had a situation similar to this one?
Thank you in advance!
The problem for me with creating a dependency in our models to a "Technology" is has to do with what OP means with other informations which are not related to OP's environment. Is OP able to create a database model that works, whose system is not overly complex and that can accommodate for all of the cases OP wants? If that's the case, I don't see why not.
There's an interesting Q&A talking about having multiple instances of Django in the same server. Personally I have already deployed in virtual shared hosts whose logic was essentially that, with the limitation that OP is sharing with other people too. OP can see in that thread that there are various cases where it was a viable option. Personally I find such shared hosts only viable in initial stages as they weren't as performant... but a great way to save resources if one is working with tight budgets. IMO this can be one of the best options for OP's case... which is considered single-tenant.
In regards to multiple databases, this automatically leads me to an approach to multi-tenant applications (within the multi-tenant applications there are approaches where one only needs one database as well). OP wants to go for this case if OP's application can serve all of the users from the same host, which doesn't seem the case for OP, unless OP is able to create a dependency in OP's models to a "Technology" (as addressed in the first paragraph).