Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards an Architectural Style for Multi-tenant Software Applications

2,739 views

Published on

Multi-tenant software applications serve different organizations from a single instance and help to save development, maintenance, and administration costs. The architectural concepts of these applications and their relation to emerging platform-as-a-service (PaaS) environments are still not well understood, so that it is hard for many developers to design and implement such an application. Existing attempts at a structured documentation of the underlying concepts are either technology-specific or restricted to certain details. We propose documenting the concepts as a new architectural style. This paper initially describes the architectural properties, elements, views, and constraints of this style. We illustrate how the architectural elements are implemented in current PaaS environments, such as Force.com, Windows Azure, and Google App Engine.

Published in: Technology
  • Be the first to comment

Towards an Architectural Style for Multi-tenant Software Applications

  1. 1. Towards an<br />Architectural Style<br />Multi-tenant<br />for<br />Software Systems<br />Dr.-Ing. Heiko Koziolek<br />Industrial Software SystemsABB Corporate Research<br />1<br />
  2. 2. Source: salesforce.com<br />2<br />
  3. 3. 28.04.2008: „SAPs neue Mittelstandssoftware ‚Business By Design‘ klemmt“<br />25.10.2008:<br />„SAP will sich von Outsourcing-Tochter trennen“<br />19.02.2009:<br />„SAP dementiert Verkaufsstopp für ‚Business by Design‘“<br />Source: heise.de<br />3<br />
  4. 4. Single-Tenancy<br />Multi-Tenancy<br />Tenant1<br />Tenant2<br />Tenant3<br />Tenant1<br />Tenant2<br />Tenant3<br />App<br />App<br />App<br />App<br />Database<br />Database<br />Database<br />Database<br />OS<br />OS<br />OS<br />OS<br />Hardware<br />Hardware<br />Hardware<br />Hardware<br />4<br />
  5. 5. Challenges<br />Technology Focus<br />Lack ofDocumentation<br />Ad-hoc<br />Solutions<br />5<br />
  6. 6. ArchitecturalStyles<br /><ul><li> Client / Server
  7. 7. Pipe-and-Filter
  8. 8. Peer-to-Peer
  9. 9. Mobile Code
  10. 10. Blackboard
  11. 11. C2
  12. 12. REST (WWW)
  13. 13. SPIAR (AJAX)</li></ul>Idea: Multi-tenancy Style<br />6<br />An architectural style is a coordinated set of architectural constraints that restricts the roles / features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.<br />[Fielding2000]<br />
  14. 14. ArchitecturalProperties<br />Elasticity<br />ResourceSharing<br />Maintainability<br />Customizability<br />7<br />
  15. 15. SPOSAD Style forMulti-Tenancy<br />Client Tier<br />Application Tier<br />Data Tier<br />Browser<br />Multi-tenantDatabase<br />Cache (optional)<br />Load Balancer<br />Application Threads<br />REST<br />Data<br />Asynch, Synch<br />Transfer<br />Customization<br />REST<br />Meta-Data<br />Rich Client<br />Meta-DataManager<br />8<br />
  16. 16. SPOSAD Style forMulti-Tenancy<br />Maintainability<br />Elasticity<br />Client Tier<br />Application Tier<br />Data Tier<br />Browser<br />Multi-tenantDatabase<br />Cache (optional)<br />Load Balancer<br />Application Threads<br />REST<br />Data<br />Asynch, Synch<br />Transfer<br />Customization<br />REST<br />Meta-Data<br />Rich Client<br />Meta-DataManager<br />Customizability<br />ResourceSharing<br />9<br />
  17. 17. Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />10<br />
  18. 18. Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />11<br />
  19. 19. Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />12<br />
  20. 20. Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />13<br />
  21. 21. ArchitecturalConstraints<br />SharedData Resources<br />Single Code Base<br />STATE<br />Customization Component<br />Stateless Application Tier<br />14<br />
  22. 22. ArchitecturalTrade-offs<br />15<br />ResourceSharing<br />vs. Security / Availability<br />Complexityvs. Time to market<br />Customizabilityvs. Maintainability<br />
  23. 23. Evaluation?<br />16<br />
  24. 24. Client Tier<br />Application Tier<br />Data Tier<br />VirtualApplicationComponents<br />CustomizedOracle RAC<br />Browser<br />Multi-tenantDatabase<br />Cache (optional)<br />Load Balancer<br />Application Threads<br />REST<br />Data<br />Asynch, Synch<br />Transfer<br />Customization<br />REST<br />Meta-Data<br />Rich Client<br />Meta-DataManager<br />RuntimeEngine<br />Universal Table Layout<br />17<br />
  25. 25. Client Tier<br />Application Tier<br />Data Tier<br />Web / WorkerRoles<br />Blobs, Tables, SQL Azure<br />Browser<br />Multi-tenantDatabase<br />Cache (optional)<br />Load Balancer<br />Application Threads<br />REST<br />Data<br />Asynch, Synch<br />Transfer<br />Customization<br />REST<br />Meta-Data<br />Rich Client<br />Meta-DataManager<br />WorkerRole<br />18<br />
  26. 26. Client Tier<br />Application Tier<br />Data Tier<br />JSP / Servlet,Python<br />Google Big Table<br />Browser<br />Multi-tenantDatabase<br />Cache (optional)<br />Load Balancer<br />Application Threads<br />REST<br />Data<br />Asynch, Synch<br />Transfer<br />Customization<br />REST<br />Meta-Data<br />Rich Client<br />Meta-DataManager<br />AppEngineServices<br />19<br />
  27. 27. …and SAP? ?<br />27.01.2010<br />„Mit dem Featurepack 2.5, das Mitte dieses Jahres erscheint, bekommt Business ByDesigneine Multi-Tenant-Architektur“ <br />Peter Lorenz Leiter SME Solutions SAP<br />Source: isreport.de<br />20<br />
  28. 28. Conclusions<br />Multi-tenancy as an Architectural Style<br />21<br />
  29. 29. 22<br />

×