Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Multi-tenancy Research Day

1.130 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie, Unterhaltung & Humor
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Multi-tenancy Research Day

  1. 1. Multi-Tenancy Research Meeting: Using Design Patterns to Implement Multi-Tenancy Jaap Kabbedijk, MSc. Utrecht University1
  2. 2. Jaap Kabbedijk  PhD. Candidate @ Utrecht University  Interests: Requirements Engineering, Software Variability, SaaS, Open Source Software, Software Architecture  Graduated on the topic of “Decision making in Requirements Engineering”  First publication in the PaaS project  J. Kabbedijk & S. Jansen, Variability in Multi-tenant Environments: Architectural Design Patterns from Industry, Proceedings of the International Variability Workshop@ER, 20112 www.productasaservice.org
  3. 3. Outline  Motivation and goal  Case Companies  Concepts  Pattern Evaluation Method  Conclusion  Discussion3 www.productasaservice.org
  4. 4. Research Motivation  Customers have specific requirements for the software they use  Offering specific on-premises variants can be hard to:  Manage  Update  Maintain  Complying to customer specific requirements in a SaaS environment has drawbacks:  Difficulty with scalability  Difficulty with maintainability  Architectural erosion4 www.productasaservice.org
  5. 5. Main Project Goal Minimizing the total cost of ownership (TCO), by profiting of the economy of scale of the SaaS deployment model, while keeping flexibility in offering functionality to customers5 www.productasaservice.org
  6. 6. What will we do? What will we do in order to answer the question: ‘How to facilitate variability in Multi-tenant Software as a Service deployments?’6 www.productasaservice.org
  7. 7. What will we do? What will we do in order to answer the question: ‘How to facilitate variability in Multi-tenant Software as a Service deployments?’ Come up with Runtime Variability Patterns (RVP)7 www.productasaservice.org
  8. 8. Case Companies  AFAS  Exact  MP-Objects  Possibly Unit4 and Mamut  Most in Truffle 100 (www.truffle100.com)8 www.productasaservice.org
  9. 9. What is Multi-Tenancy? Bron: Microsoft Research, 20069 www.productasaservice.org
  10. 10. When do you need Multi-tenancy?10 www.productasaservice.org
  11. 11. What is Variability?11 www.productasaservice.org
  12. 12. How to get the Patterns? Develop Patterns Publish Evaluate & Test Patterns Patterns12 www.productasaservice.org
  13. 13. Pattern Development  Identify Run-time Variability Patterns currently used  Case study at AFAS  Case study at Exact  Case study at MP-Objects  Identify RVPs in literature (literature study)  Come up with new RVPs (design science)13 www.productasaservice.org
  14. 14. Test and Evaluation  Identify RVP evaluation criteria  Evaluate RVPs by expert reviews  Test RVPs on small scale and large scale (testbed)14 www.productasaservice.org
  15. 15. Expert Review Session  20 experts  Twice a year  Direct feedback from industry  Interactive voting  Direct discussion15 www.productasaservice.org
  16. 16. Evaluation Criteria (1/2) (based on expert review session)  Scalability – How does the pattern behave if the customer base grows?  Maintainability – How easy can the software be maintained when this pattern is applied?  Reusability – How easy can this pattern be reused in other parts of the software without code duplication?  Risk – What is the risk in terms of security of implementing this pattern? What are other typical risks and possible countermeasures?16 www.productasaservice.org
  17. 17. Evaluation Criteria (2/2) (based on expert review session)  Complexity – How complex is it to implement the pattern in a software product?  Flexibility – How well can the pattern cope with different system environments?  Required Changes – How much should be changed to a solution that does not yet implement the pattern?  Cost of Implementation – How much does the implementation of the pattern cost in total?17 www.productasaservice.org
  18. 18. Test Tooling  Selenium  SauceLabs  Tellurium  JUnit  TestComplete  TestArchitect18 www.productasaservice.org
  19. 19. Reporting (based on expert review session)19 www.productasaservice.org
  20. 20. Testbed • Patterns • Comments Tools Patterns Industry • Evaluations Testbed • Patterns Academia • Comments • Evaluations Test Data Testing Logic Pattern Database20 www.productasaservice.org
  21. 21. Publish  Summarize all RVPs and test results in the RVP database (continuous)  Publish catalogue (in the end)21 www.productasaservice.org
  22. 22. Pre/Post Update Hooks (1/3)22 www.productasaservice.org
  23. 23. Pre/Post Update Hooks (2/3)  Intent - To provide the possibility for tenants to have custom functionality just before or after an event  Motivation - To let the software product fit the tenants business processes best, extra actions could be made available to tenants before or after an event is called  Solution – The use of a component able of calling other components before and after the update of data. The tenant-specic modules are listed in a separate table23 www.productasaservice.org
  24. 24. Pre/Post Update Hooks (3/3)  Explanation – See image  Consequences - Extra optional components have to be available in the software system in order to be able to implement this pattern  Example - In a bookkeeping program, tenants can choose, whether they want to update a third party service as well by using a component that uses the API of a third party service to make changes there. If so, the FunctionalComponent can call the third party communicator after an internal update is requested24 www.productasaservice.org
  25. 25. Module Dependent Menu (1/3)25 www.productasaservice.org
  26. 26. Module Dependent Menu (2/3)  Intent - To provide a custom menu to all tenants, only containing links to the functionality relevant to the tenant  Motivation - Displaying all possible functionality in the menu would decrease the user experience of tenants, so menus have to display only the functionality that is relevant to the tenant  Solution – Every time a tenant displays the menu, the menu is built dynamically based on the modules he has selected or bought26 www.productasaservice.org
  27. 27. Module Dependent Menu (3/3)  Explanation – See image  Consequences - To be able to use this pattern, an extra table containing user-IDs and the modules available to this user has to be implemented. Also, the extra class ModuleChecker has to be implemented  Example - In a large bookkeeping product, containing several modules that can be bought by a tenant, the menus presented to the tenant can be dynamically composed based on the tenants license27 www.productasaservice.org
  28. 28. Discussion28 www.productasaservice.org
  29. 29. Multi-tenancy levels  Data Model Multi-tenancy  All tenant share the same database and data model  Application Multi-tenancy  All tenant share the same software instance  Configurable Multi-tenancy  All tenants share both database and software instance, while being able to configure the product the way they want it29 www.productasaservice.org
  30. 30. Variability levels  Look-and-Feel Variability  Possible different variants only enable changes in the look and feel  Data Model Variability  Different variants allow for changes in the data model  Application Variability  Different variants allow for changes in the product functionality30 www.productasaservice.org
  31. 31. Thanks!  www.productasaservice.org  www.jkabbedijk.nl  www.slingerjansen.nl31 www.productasaservice.org