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. BUILDING MULTI-TENANT
    APPLICATIONS
    TOM SCHLICK - LARACON US 2017

    View Slide

  2. 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

    View Slide

  3. 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

    View Slide

  4. WHAT IS
    MULTI-TENANCY?
    Multi-tenancy is a single instance
    of software that serves multiple
    customers privately.

    View Slide

  5. EXAMPLES OF MULTI-TENANT APPS

    View Slide

  6. WHY WOULD YOU USE MULTI-TENANCY?
    ▸Cost Savings
    ▸Single Deployment Point
    ▸Easier Maintenance

    View Slide

  7. DATABASE
    STRATEGIES

    View Slide

  8. 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

    View Slide

  9. SINGLE DATABASE: SETUP
    SCOPING QUERIES

    View Slide

  10. SINGLE DATABASE: SETUP
    SCOPING QUERIES

    View Slide

  11. SINGLE DATABASE: SETUP
    SCOPING QUERIES

    View Slide

  12. 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

    View Slide

  13. 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

    View Slide

  14. 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

    View Slide

  15. 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

    View Slide

  16. MULTI DATABASE: SETUP
    CONNECTIONS ON THE FLY

    View Slide

  17. 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.

    View Slide

  18. 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

    View Slide

  19. 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

    View Slide

  20. 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

    View Slide

  21. 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

    View Slide

  22. 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

    View Slide

  23. 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?

    View Slide

  24. SEGMENT ALL
    THE THINGS

    View Slide

  25. SEGMENT EVERYTHING
    QUEUED JOBS

    View Slide

  26. 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

    View Slide

  27. SEGMENT EVERYTHING
    CONSOLE COMMANDS

    View Slide

  28. SEGMENT EVERYTHING
    CONSOLE COMMANDS

    View Slide

  29. SEGMENT EVERYTHING
    CONSOLE COMMANDS

    View Slide

  30. 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

    View Slide

  31. 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

    View Slide

  32. SEGMENT EVERYTHING
    CACHE
    ▸ Prefix your cache's as well to avoid collisions
    ▸ Can be done easily via cache config similar to search

    View Slide

  33. SEGMENT EVERYTHING
    EXTERNAL SERVICES
    ▸ Provide external services with your tenant_id for easier retrieval
    ▸ Especially important when dealing with webhooks

    View Slide

  34. DOMAIN
    STRATEGIES

    View Slide

  35. 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

    View Slide

  36. 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)

    View Slide

  37. 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

    View Slide

  38. 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

    View Slide

  39. 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

    View Slide

  40. 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

    View Slide

  41. PACKAGES
    Single Database:
    https://github.com/HipsterJazzbo/Landlord
    Multi Database:
    https://github.com/tomschlick/townhouse (in progress)
    https://github.com/orchestral/tenanti

    View Slide

  42. QUESTIONS?
    @TOMSCHLICK [email protected]

    View Slide

  43. THANK YOU!
    @TOMSCHLICK [email protected]

    View Slide