Building Multi-Tenant Applications

My talk from Laracon US 2017

Transcript

1. BUILDING MULTI-TENANT APPLICATIONS TOM SCHLICK - LARACON US 2017
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
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
4. WHAT IS MULTI-TENANCY? Multi-tenancy is a single instance of software that serves multiple customers privately.
5. EXAMPLES OF MULTI-TENANT APPS
6. WHY WOULD YOU USE MULTI-TENANCY? ▸Cost Savings ▸Single Deployment Point ▸Easier Maintenance
7. DATABASE STRATEGIES
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
9. SINGLE DATABASE: SETUP SCOPING QUERIES
10. SINGLE DATABASE: SETUP SCOPING QUERIES
11. SINGLE DATABASE: SETUP SCOPING QUERIES
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
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
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
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
16. MULTI DATABASE: SETUP CONNECTIONS ON THE FLY
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.
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
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
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
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
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
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?
24. SEGMENT ALL THE THINGS
25. SEGMENT EVERYTHING QUEUED JOBS
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
27. SEGMENT EVERYTHING CONSOLE COMMANDS
28. SEGMENT EVERYTHING CONSOLE COMMANDS
29. SEGMENT EVERYTHING CONSOLE COMMANDS
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
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
32. SEGMENT EVERYTHING CACHE ▸ Prefix your cache's as well to avoid collisions ▸ Can be done easily via cache config similar to search
33. SEGMENT EVERYTHING EXTERNAL SERVICES ▸ Provide external services with your tenant_id for easier retrieval ▸ Especially important when dealing with webhooks
34. DOMAIN STRATEGIES
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
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)
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
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
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
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
41. PACKAGES Single Database: https://github.com/HipsterJazzbo/Landlord Multi Database: https://github.com/tomschlick/townhouse (in progress) https://github.com/orchestral/tenanti
42. QUESTIONS? @TOMSCHLICK TOM@SCHLICK.EMAIL
43. THANK YOU! @TOMSCHLICK TOM@SCHLICK.EMAIL