Building a multitenant application with Django, a tutorial given at PyCon Nigeria 2019. This slide is based on the Django multitenant application documentation.
3. Glossary
• Database – collection of structured data to model reality in a way that support
processes requiring information.
• Schema - refers to the set of formulas or “rules” imposed on data in a database to be
organized into a certain way.
• App server – is a distributed network that provides the business logic for an
application.
4. What is Multi-tenancy?
• Multi tenant applications allow you to serve multiple customers with one install of the
application.
• It is the ability to run one instance of an app, and serve it to multiple distinct end user.
Each one of them is isolated from the other in terms of performance & data-leads.
5.
6. Iaas
• Iaas – Insfrasture Application as Software.
• This is the tenancy model created by virtualization, and it is the ability to carve
large large server into multiple virtual machine.
App 1 App 2
App 4App 3
Host OS
Hypervisor
it - centric
7. Paas
• Paas – Platform as a Service.
• This is a better way of hosting a co-habiting Apps rather than dedicating a whole
OS instance to them.
OS OS OS OS
Component
8. Saas
• Saas – Software as a Service.
• It is the ability to run a single instance of an app that serves multiple distinct end
users. Each one of them is isolated from the other in terms of performance & data-
leads.
APP 1
T 1 T 2 T 3
User
User
User
User
User
User
User
User
User
9.
10. Saas
• Benefits:
• Reduce infrastructure costs by sharing hardware resources.
• Simplify software maintenance by keeping a single code base.
• Simplify infrastructure maintenance by having fewer nodes.
App
management
is once.
Monitoring is
once.
QA is once.
11. Multi-tenancy
• Approaches:
• Shared database with shared schema
• Shared database with isolated schema
• Isolated database with a shared app server
Argh!
Django again…
16. Adding multi tenancy:
• python manage.py startapp tenants
• Create a model for storing Tenant data.
• TenantAwareModel class will be subclass from.
18. Identifying tenants:
• Giving each tenant their own subdomain.
• abc.example.com
• xyz.example.com
• This will be will have a subdomain_prefix which will identify the tenant.
22. Isolating the admin:
• Get_queryset: so that only the current tenant’s objects show up.
• Save_model: so that tenant gets set on the object when the object is saved.
23. Limitation:
• Weak separation of tenant’s data.
• Tenant isolation code is intermixed with app code.
• Duplication of code.
26. What to do?
• Map tenant to schema
• Manage database migrations
• Tenant separation in views
• A middleware to set schemas
• Add get and set methods to utils.py
27. • Mapping tenant to schema
Mapping tenants to schemas for easy routing
28. • Manage database migrations
• Tenant separation in views
• A middleware to set schemas
• Add get and set methods to utils.py
CREATE SCHEMA IF NOT EXISTS potter
SET search_path to potter
We make manage.py schema aware, therefore, it create schema according to
the tenant in case it never existed, and set search_path tenant accordingly.
29. • Tenant separation in views
• A middleware to set schemas
• Add get and set methods to utils.py
The following methods allow us to get and set the schema.
30. • Tenant separation in views
• A middleware to set schemas
Separating the tenants in the view.
31. • Tenant separation in views
• A middleware to set schemas
Separating the tenants in the view.
35. Multiple database support in Django:
To read poll from thor: Poll.objects.using(‘thor’).all()
But we’d rather avoid code duplication, therefore use db routing
36. DB_ROUTERS settings take a list of classes which implement a few methods. A router class looks like this.
DB routing:
But none takes an argument, therefore, we cannot call tenant_db_from_request
We use threadlock variables to calculate DB to use, pass it to the router