wecode-multi-tenant-application-presentation.pdf

Transcript

1. Building and Scaling A Multi- Tenant Application (The Edureck Experience) WeCode/Abuja
2. Imo Inyang Full Stack Developer @ Reimnet @imo_inyang on twitter imo@reimnet.com • Team Lead @ Edureck • Www.edureck.com
3. An application, intended for multiple client businesses, that's installed on a single instance/pool and serves all clients from that instance. (Thus the single instance serves multiple tenants.) What is a Multi-Tenant App?
4. What is a Multi-Tenant App?
5. What is a Multi-Tenant App?
6. The design pattern that a multi-tenant application developer chooses typically is based on a consideration of the following factors: Multi Tenant application design Concerns
7. Tenant Identity and isolation. • You needs to ensure that no tenant has access to other tenants’ data. • Providing protection from noisy neighbors, • Being able to restore a tenant’s data with ease • Implementing tenant-specific customizations.
8. Cloud resource cost. An SaaS application needs to be cost- competitive. Thus developer might choose to optimize for lower cost in the use of cloud resources, such as storage and compute costs.
9. DevOps is a Cake. A multitenant application developer needs to incorporate isolation protection, maintain, update and upgrade, and monitor the health of their application and database schema, and troubleshoot tenant issues.
10. Scalability. The ability to incrementally add more tenants and capacity for tenants who require it is imperative to a successful SaaS operation.
11. Multi Tenant Common Design and Data model
13. Database-per-tenant. Each tenant has its own database. All tenant-specific data is confined to the tenant’s database and isolated from other tenants and their data. Shared database - Sharded. Multiple tenants share one of multiple databases. A distinct set of tenants is assigned to each database by using a partitioning strategy such as hash, range, or list partitioning. This data distribution strategy often is referred to as Sharding. Shared database-single. A single, sometimes large, database contains data for all tenants, which are disambiguated in a tenant ID column.
14. Isolation. The degree of isolation between tenants can be a measure of how much tenant isolation a data model achieves. Cloud resource cost. The amount of resource sharing between tenants can optimize cloud resource cost. A resource can be defined as the compute and storage cost. DevOps cost. The ease of application development, deployment, and manageability reduces overall SaaS operation cost. Design Concerns
15. Ownership of tenant data. An application in which tenants retain ownership of their own data favors the pattern of a single database per tenant. Scale. An application that targets hundreds of thousands or millions of tenants favors database sharing approaches such as sharding. Isolation requirements still can pose challenges.
16. Business model. If an application’s per- tenant revenue if small (less than a dollar), isolation requirements become less critical and a shared database makes sense. If per- tenant revenue is a few dollars or more, a database-per-tenant model is more feasible. It might help reduce development costs.
17. Identifying Tenants You should try to identify tenant early in your application request cycle. • Ensure Tenant exist • Load Tenant Configs • etc
18. Sample Application Request Cycle Application Index
19. Resources • Google is your friend on this one !
20. The • Thanks for your time – hope it was worth it? • If you think I can help, reach me via imo@reimnet.com or @imo_inyang on twitter End