1. Enabling Multi-Tenancy An Industrial Experience Report Cor-Paul Bezemer, Andy Zaidman, Bart Platzbeecker, Toine Hurkmans, Aad ‘t Hart

2. Outline What is multi-tenancy? Converting single-tenant to multi-tenant applications CodenameMT Lessons learned

3. What is Multi-Tenancy? vs.

4. What is Multi-Tenancy? A multi-tenant application lets customers (tenants) share the same hardware resources, by offering them one shared application and database instance, while allowing them to configure the application to fit their needs as if it runs on a dedicated environment. vs.

5. Multi-Tenancy vs. Multi-User Tenant can span multiple users Tenants can have SLAs Tenants have more configurability options

6. Benefits of Multi-Tenancy Lower number of application and database instances Results in easier (& cheaper) deployment Requires high degree of configuration Higher utilization of hardware resources Results in lower hardware costs Lower deployment and hardware costs Results in the opportunity to offer a service at a lower price

7. Challenges of Multi-Tenancy Performance Scalability Security Zero-downtime Maintenance Configurability increases complexity

8. Exact Codename and Multi-Tenancy Exact Codename: prototype of a Web 2.0 community Codename is currently single-tenant Why is multi-tenancy interesting for Codename? Allow rapid ‘deployment’ of different communities Install one instance, configure/maintain many Save on hardware resource costs

9. A Multi-Tenant Codename Version Goal: Create a multi-tenant version of Codename Requirements: Minor adjustments in existing code Let developers be (mostly) unaware of multi-tenancy Clearly separate multi-tenant components

11. Codename Architecture

12. CodenameMT: Authentication Add CodenameMT as a known party to the existing single sign-on server Add TenantID to token (claim and User objects) Note: ‘original’ Codename authentication still in place!

13. CodenameMT: Configuration Layout style Adapt global.asax to load tenant-specific masterpage/theme General configuration Stored in the database (handled by Data Access Layer) File I/O Load tenant-specific lists/entities Workflow - future work

15. Lessons Learned Lightweight reengineering approach Approx. 100 lines of code added to ~165K LOC Approx. 3 days of implementation were needed Layered architecture is important Fully transparent for the end-user End-user is unaware that the application is multi-tenant Little effect for the developer

16. Future Work Performance monitoring/prediction Prototype in ‘ideal’ multi-tenant architecture Apply ideas to Exact Online “Can we predict a peak in performance, and take appropriate scalability measures in time?”