Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building Multi-Tenant Applications

Building Multi-Tenant Applications

My talk from Laracon US 2017

Tom Schlick

July 25, 2017
Tweet

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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?
  15. 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
  16. 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
  17. 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
  18. SEGMENT EVERYTHING CACHE ▸ Prefix your cache's as well to

    avoid collisions ▸ Can be done easily via cache config similar to search
  19. SEGMENT EVERYTHING EXTERNAL SERVICES ▸ Provide external services with your

    tenant_id for easier retrieval ▸ Especially important when dealing with webhooks
  20. 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
  21. 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)
  22. 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
  23. 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
  24. 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
  25. 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