Slide 1
Slide 1 text
BUILDING MULTI-TENANT
APPLICATIONS
TOM SCHLICK - LARACON US 2017
Slide 2
Slide 2 text
HI, I'M TOM SCHLICK!
I'm from Pittsburgh, Pennsylvania
▸ Former Lead Software Engineer at RunMyBusiness,
a Commercial Real Estate consultancy
▸ Attendee of every US Laracon
▸ Creator of ZoneWatcher, a DNS changelog service
▸ Follow on Twitter @tomschlick
Slide 3
Slide 3 text
WHAT WE WILL COVER
▸ What is Multi-Tenancy? Why would you need it?
▸ Single Database vs Multi Database setups
▸ Segmenting the Job Queue, Console commands, Search, etc
▸ Dealing with external services
▸ Examples for getting started and popular packages
Slide 4
Slide 4 text
WHAT IS
MULTI-TENANCY?
Multi-tenancy is a single instance
of software that serves multiple
customers privately.
Slide 5
Slide 5 text
EXAMPLES OF MULTI-TENANT APPS
Slide 6
Slide 6 text
WHY WOULD YOU USE MULTI-TENANCY?
▸Cost Savings
▸Single Deployment Point
▸Easier Maintenance
Slide 7
Slide 7 text
DATABASE
STRATEGIES
Slide 8
Slide 8 text
STRATEGY: SINGLE DATABASE
▸ Data from all tenants lives together
▸ tenant_id column in each table to
segment data id tenant_id name
1 1 Walter
2 2 Jesse
3 1 Skyler
4 3 Hector
USERS
Slide 9
Slide 9 text
SINGLE DATABASE: SETUP
SCOPING QUERIES
Slide 10
Slide 10 text
SINGLE DATABASE: SETUP
SCOPING QUERIES
Slide 11
Slide 11 text
SINGLE DATABASE: SETUP
SCOPING QUERIES
Slide 12
Slide 12 text
SINGLE DATABASE
PROS
▸ Very conventional approach, lots of existing knowledge on how to setup
▸ Migrations stay simple
▸ Easy to display data from multiple tenants on the same page
Slide 13
Slide 13 text
SINGLE DATABASE
CONS
▸ Must include a scope or WHERE clause on every database query
▸ Using third party packages often requires modification to add the "tenant_id"
field to both models & migrations
▸ Hard to scale database across multiple servers without a sharding plan set at
the beginning
▸ Painful to export all of a specific customer's data
Slide 14
Slide 14 text
STRATEGY: MULTIPLE DATABASES
▸ Multi Database with separate database per tenant
▸ Each tenant has a full copy of the application in their own database
including migrations
id name
1 Walter
2 Skyler
TENANT 1: USERS
id name
1 Jesse
TENANT 2: USERS
id name
1 Hector
TENANT 3: USERS
Slide 15
Slide 15 text
MULTI DATABASE: SETUP
SHARED DATABASE
▸ Acts as the "router"
connecting the current
domain to the proper tenant
database
id subdomain name
1 hooli Hooli
2 initech Initech
3 umbrellacorp Umbrella Corp
TENANTS TABLE
Slide 16
Slide 16 text
MULTI DATABASE: SETUP
CONNECTIONS ON THE FLY
Slide 17
Slide 17 text
MULTI DATABASE
PRO: REDUCED POINTS OF FAILURE
▸ Single point where data is segmented. Easy to test.
▸ Set it and forget it. No query scopes or WHERE clauses required.
▸ Less chance of Customer A's private data being shown to Customer B.
Slide 18
Slide 18 text
MULTI DATABASE
PRO: USE THIRD PARTY PACKAGES "OFF THE SHELF"
▸ No modification needed to add "tenant_id" field to every table & model
▸ Risk of breaking changes is much lower
Slide 19
Slide 19 text
MULTI DATABASE
PRO: EASIER LONG TERM SCALABILITY
▸ Customer's databases can easily be transitioned between servers depending
on size, load, or failure
▸ Instead of scaling vertically by creating larger database servers, you can scale
horizontally by creating more small sized servers
Slide 20
Slide 20 text
MULTI DATABASE
PRO: DATA PORTABILITY
▸ Data is easier to export, without complex separation steps
▸ Backups can be done separately per tenant, making them easier to restore
▸ Enterprise customers can be transitioned to on-premise setups easily
▸ Tenant data can be easily deleted at the request of the owner
Slide 21
Slide 21 text
MULTI DATABASE
PRO: CLUSTERS
▸ Deploys and maintenance can be done gradually, keeping the majority of
customers online at once
▸ Choose where to store a customer's data based on their location, for reduced
latency
▸ Customers can be added to "beta clusters" which get features before the
general pool
Slide 22
Slide 22 text
MULTI DATABASE
CON: MORE COMPLEX MIGRATIONS
▸ Each tenant database must have migrations run independently
▸ You must have two sets of migrations, one folder for the tenant dbs, and
another for the shared db
Slide 23
Slide 23 text
CHOOSING THE CORRECT STRATEGY
1. Do you commonly need to display information from multiple tenants on the
same page?
2. Do you need the option to segment, export, or privately host data for
particular customers?
3. Do you plan to use a lot of third party packages?
4. Are your customers providing highly sensitive data to your application?
Slide 24
Slide 24 text
SEGMENT ALL
THE THINGS
Slide 25
Slide 25 text
SEGMENT EVERYTHING
QUEUED JOBS
Slide 26
Slide 26 text
SEGMENT EVERYTHING
CONSOLE COMMANDS
All console commands that interact with the database should be able to do 2 things:
▸ Apply the command to ALL tenants
▸ Apply the command to a single tenant
Slide 27
Slide 27 text
SEGMENT EVERYTHING
CONSOLE COMMANDS
Slide 28
Slide 28 text
SEGMENT EVERYTHING
CONSOLE COMMANDS
Slide 29
Slide 29 text
SEGMENT EVERYTHING
CONSOLE COMMANDS
Slide 30
Slide 30 text
SEGMENT EVERYTHING
FILE & ASSET STORAGE
▸ Segment files in the same way you do for multi database setups by storing
each file in a folder with the tenant's id
▸ Makes it easy to backup, move, and delete those files if the time comes
Slide 31
Slide 31 text
SEGMENT EVERYTHING
SEARCH
▸ Create separate indexes for each of your tenants for both Singe & Multi DB
setups
▸ Laravel Scout makes this dead simple, allowing you to apply a prefix key to
your indexes
Slide 32
Slide 32 text
SEGMENT EVERYTHING
CACHE
▸ Prefix your cache's as well to avoid collisions
▸ Can be done easily via cache config similar to search
Slide 33
Slide 33 text
SEGMENT EVERYTHING
EXTERNAL SERVICES
▸ Provide external services with your tenant_id for easier retrieval
▸ Especially important when dealing with webhooks
Slide 34
Slide 34 text
DOMAIN
STRATEGIES
Slide 35
Slide 35 text
DOMAIN STRATEGIES
#1: THE SUBDOMAIN : PROS HTTPS://ACME.YOURAPP.COM
▸ Works with either Singe or Multi Database setups
▸ Custom branding for your customers
▸ Allows customers to be logged into multiple accounts at once as each
subdomain has their own sessions
▸ Allows you to use DNS to choose which servers handle requests per client
Slide 36
Slide 36 text
DOMAIN STRATEGIES
#1: THE SUBDOMAIN : CONS HTTPS://ACME.YOURAPP.COM
▸ Requires a wildcard SSL certificate to setup which can be costly (until
LetsEncrypt offers them in Jan 2018)
▸ Your api has to live on the same domain, which can make it more complicated
to funnel traffic to separate api servers
▸ Customers going to YOURAPP.COM directly would have to know which tenant
they are a part of to get redirected to their own login page (similar to Slack's
login)
Slide 37
Slide 37 text
DOMAIN STRATEGIES
#2: THE CUSTOM DOMAIN : PROS HTTPS://YOURAPP.ACME.COM
▸ Works best with Multi Database setups
▸ Your customer gets to white label your application to their own users
Slide 38
Slide 38 text
DOMAIN STRATEGIES
▸ Your Nginx setup becomes more complicated requiring you to serve different
domains with separate SSL certificates
▸ Your customer controls the DNS which limits your ability to make changes for
infrastructure reasons
#2: THE CUSTOM DOMAIN : CONS HTTPS://YOURAPP.ACME.COM
Slide 39
Slide 39 text
DOMAIN STRATEGIES
#3: BASIC DOMAIN : PROS HTTPS://YOURAPP.COM
▸ Works best for Single Database Setups
▸ All customers know where to login easily
▸ API can live on subdomain
▸ Easy setup as its the most common approach
Slide 40
Slide 40 text
DOMAIN STRATEGIES
#3: BASIC DOMAIN : CONS HTTPS://YOURAPP.COM
▸ Logging into multiple accounts at once isn't available out of the box
▸ No easy way to specify which server gets the traffic from a specific customer
without some type of middleman load balancer
Slide 41
Slide 41 text
PACKAGES
Single Database:
https://github.com/HipsterJazzbo/Landlord
Multi Database:
https://github.com/tomschlick/townhouse (in progress)
https://github.com/orchestral/tenanti