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
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
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
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
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
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
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
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.
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
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
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
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
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
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?
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
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
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
SEGMENT EVERYTHING EXTERNAL SERVICES ▸ Provide external services with your tenant_id for easier retrieval ▸ Especially important when dealing with webhooks
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
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)
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
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
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
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
PACKAGES Single Database: https://github.com/HipsterJazzbo/Landlord Multi Database: https://github.com/tomschlick/townhouse (in progress) https://github.com/orchestral/tenanti
mot_techtalk
mozu1206
syumai
track3jyo
masatoshiitoh
maguroalternative
gishi_yama
honma12345
little_rubyist
ivargrimstad
pineapplecandy
fendo181
chriscoyier
thekraken
moore
thoeni
bkeepers
soudai
malarkey
dougneiner
panda_program
samlambert
bryan
addyosmani