Towards an<br />Architectural Style<br />Multi-tenant<br />for<br />Software Systems<br />Dr.-Ing.  Heiko Koziolek<br />In...
Source: salesforce.com<br />2<br />
28.04.2008: „SAPs neue Mittelstandssoftware ‚Business By Design‘ klemmt“<br />25.10.2008:<br />„SAP will sich von Outsourc...
Single-Tenancy<br />Multi-Tenancy<br />Tenant1<br />Tenant2<br />Tenant3<br />Tenant1<br />Tenant2<br />Tenant3<br />App<b...
Challenges<br />Technology Focus<br />Lack ofDocumentation<br />Ad-hoc<br />Solutions<br />5<br />
ArchitecturalStyles<br /><ul><li> Client / Server
Pipe-and-Filter
Peer-to-Peer
 Mobile Code
Blackboard
 C2
 REST (WWW)
 SPIAR (AJAX)</li></ul>Idea: Multi-tenancy Style<br />6<br />An architectural style is a coordinated set of architectural ...
ArchitecturalProperties<br />Elasticity<br />ResourceSharing<br />Maintainability<br />Customizability<br />7<br />
SPOSAD Style forMulti-Tenancy<br />Client Tier<br />Application Tier<br />Data Tier<br />Browser<br />Multi-tenantDatabase...
SPOSAD Style forMulti-Tenancy<br />Maintainability<br />Elasticity<br />Client Tier<br />Application Tier<br />Data Tier<b...
Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />10<br />
Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />11<br />
Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />12<br />
Multi-tenant Database<br />Private Table Layout<br />Extension Table Layout<br />Universal Table Layout<br />13<br />
ArchitecturalConstraints<br />SharedData Resources<br />Single Code Base<br />STATE<br />Customization Component<br />Stat...
ArchitecturalTrade-offs<br />15<br />ResourceSharing<br />vs. Security / Availability<br />Complexityvs. Time to market<br...
Upcoming SlideShare
Loading in...5
×

Towards an Architectural Style for Multi-tenant Software Applications

1,985

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
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,985
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
147
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Salesforce-Amerikanische Silicon Valley FirmaEiner der berühmtestenSoftware as a Service providerCustomerRelationship SoftwareUmsatz 2009: 1 Mrd US$, 47000 Kunden, über 1.1 Mio Benutzer, auf angeblich weniger als 1000 ServernKunden: z.B. Deutsche Bank, Allianz VersicherungSalesforce.com zählt zu den am schnellsten wachsenden Technologieunternehmen weltweit. Laut Forbes wächst nur Google schneller (Stand: Januar 2008).Technisch beeindruckend: hohe Skalierbarkeit, steigende Anzahl an Transaktion: mehr als 14 MrdTransaction pro Quartalsinkende Antwortzeiten: weniger als Viertelsekunde mittlere Antwortzeit pro ausgelieferter Seite
  • SAP Business By DesignVoll integrierte Enterprise ResourcePlanning Lösung für kleine und mittelständische Unternehmen in einer gehostetenSaaS LösungEntwicklung seit 2003, angekündigt 2007 für 2008, 2010 noch nicht voll ausgerolltGerüchte: Entwicklungskosten bei über 500 Mio EuroKlemmt:-&quot;Das System hat noch nicht die erforderliche Performance und hat noch zu viele Aussetzer&quot;, zitiert die Zeitung einen SAP-Entwickler. Es müsse noch viel zu viel aufwendig nachjustiert werden.- massive Performance-Probleme in der früherern Entwicklung, unterstützte nur 10 Benutzer pro ServerVerkaufsstopp?- Ursprünglich hatte man in Walldorf mit 10,000 zahlenden Kunden bis zum Jahr 2010 kalkuliert, doch derzeit scheint es davon noch keine 100 zu geben. -SAP sei mit seinen Diensten einfach zu teuer, und außerdem gebe es speziell bei Mittelständlern anhaltende Ängste, ihre wertvollen Geschäftsdaten einem Software-Dienstleister außerhalb ihrer Kontrolle anzuvertrauen. Die Probleme von Business by Design haben verschiedene Ursachen. Meiner Meinung nach ist eine dieser Ursachen, dass SAP auf eine single-tenant Architektur und nicht auf eine multi-tenant Architektur gesetzt hat
  • Tenant = Organization, Unternehmen mit Mitarbeitern als BenutzerMTEine applikation / eine Code Basis, zentrale Updates/Patches, spezielle Vorrichtungen für Kundenspezifische AnforderungenEine DB, geteilte Schemata, gemeinsame TabellenEin OSEine Hardware, verteilt, LastverteilungSkalierbarkeit durch Lastverteilung auf Cluster, spezielle Datenbankabfragen, wenig overheads, minimum an mehrfach Vorhandenen RessourcenST- Angepasste Applikation pro Kunde (Firma)DB pro Kunde Viele OS LizenzenServer pro KundeVorteil Sicherheit, Nachteil: Skalierbarkeit, schwierig sich an Lastspitzen anzupassen
  • Was ist also das Problem? Die Herausforderung?Documentation:Kein Handbuch für Multi-tenancyarchitekturen, keine BücherKaum wissenschaftlich LiteraturDas Umsetzen von Multi-tenancy wird weitläufig noch als Wettbewerbsvorteil gesehen und daher verschleiertKonstruktion schwierig, ohne Hilfestellung/Doku sehr teuerAd-hoc SolutionsTry-and-error Prinzip, kein Erfahrungsschatz, Wissen wird von Unternehmen nicht weitergeben Wacklige LösungenArchitekten können trade-offs (Zielkonflikte) nur schwierig einschätzenTechnologieGuides für Microsoft-Produkte und SaaS, Guides von IBM für Java Produkte und SaaSHöhere Abstraktion fehltArchitekturkonzepte nicht formal und technologie-unabhängig dokumentiert
  • Jetzt die Lösungidee, mein Ansatz!Was könnte die Lösung sein?Fielding, REST, WWW, 2000: Ein Architekturstil ist eine koordinierte Menge von architektonischen Bedingungen / Einschränkungen, die die Rolle der Architekturelement und deren Beziehungen zu einander einschränken.Beispiele: Client-Server, der Server arbeitet nur auf Anfrage, verschickt keine eigenen AnfragenPipe-and-Filter: es gibt keinen Zwischenspeicher, alle Informationen für die Berechnungen werden zwischen den Komponenten weitergereichtUsw.Modernere Stile sind REST für das WWW und SPIAR for AJAX AnwendungenDie Idee ist nun, Multi-tenancy in diese Liste einzureihen und explizit als Architektur Stil zu dokumentieren.Dokumentationsschema nach Perry und Wolf: Komponenten, Konnektoren, Daten Elemente und constraints auf diesen Elementen
  • ArchitecturalProperties = Ziele, können auch als Anforderungen verstanden werden,Hier 4 der wichtigsten:ResourceSharing:Möglichst viel Hardware und Software soll gemeinsam genutzt werdeVerhindert die Verschwendung von Ressource, kompliziert aber Isolation von ClientsBeispiele: -Kosteneinsparung für Datenbankadministration durch gemeinsame Datenbanken-Speichereinsparung durch nicht-dedizierte ServerElasticity:Hier könnte auch Scalability stehen, also die Fähigkeit mit wachsender Anfragelast zurecht zukommen (siehe Salesforcefolie)Elasticity schließt auch das Stoppen von Servern mit ein wenn die Anfragelast sinkt, daher werden die Ressourcen am effektivsten genutztWichtig für MT systeme wegen der hohen Anzahl an Tenants und der potentziell sehr großen Anfragelast mit LastspitzenMaintainability:Einsparung von Wartungskosten durch eine einzelne Anwendung und Codebasis für alle TenantsBugs müssen nur einmal behoben werdenBugfixes müssen nur einmal eingespielt werden, es müssen keine Fixes von Kunden installiert werden, dies erfolg zentralCustomizability:-bei nur einer geteilten Anwendung: Anpassungen an eigene Geschäftprozesse und Datenmodelle notwendig-Kunden geben sich nicht mit Standardlösungen zufrieden
  • SPOSAD steht für Shared, Polymorphic, ScalableApplication and Data- Hier jetzt Teil der Lösung, high-level Ansicht der Komponenten und Connectoren die in diesem Stil zum Einsatz kommenBasiert auf multi-tierarchitektur: clienttier, evtl. presentationtier, applicationtier, datatierClient: Web Browser (Internet Explorer), Rich Client (Eclipse RCP)Synchrone REST Kommunikation mit ApplicationtierOptionale Cache, Lastverteiler für meherer Server ApplicationThreads, stellen Präsentation und Business Logic bereit, basieren auf gleichem Code sind aber für verschiedene Tenants über Metadata anpassbarMeta-Data Manager verwaltet Meta-Daten (z.B. proprietäre Datenfelder, GUI, Workflows, Forms, usw.) und passt den Applikationscode anMulti-tenant Datenbank, gemeinsam genutzt von allen Tenants, Enthält Daten (Kundennr, Konto, usw.) und Meta-daten (Datentypen, proprietäre Erweiterungen)Asynchrone KommunikationAndere Sichten hier nicht gezeigt, Virtualisierung kann drunterliegenErstmal nur highlevel, man kann die einzelnen Komponenten noch aufschlüsseln und die Kommunikationsbeziehungen detailierter beschreibenWie bilden sich nun die gewünschten Architektureigenschaften ab?
  • ResourceSharing vor allem in der Datenbank aber auch in der Infrastruktur (App Container, VM, OS, Hardware)Elasticity z.B. durch LoadBalancer, die auto-scaling unterstützen also auch downgraden.Maintainbility durch gemeinsame Code-basis der ApplicationThreads, nur einmalige Wartung notwendingCustomizability durch Meta-data Manager, der tenant-spezfischen Anpassungen durchführen kannDatenbank im folgenden noch mal genauer, verschieden Schemata zum ResourceSharing möglich
  • VorherComponent&amp;connectorView, jetzt Information View, wie sind die Daten strukturiert
  • Jeder Tenant bekommt seine eigenen Tabellen mit möglicherweise eigenen Datenfeldern 27, 33, 46 sind die TenantidsVorteil: keine komplizierten Joins notwendig, einfach zu implementierenNachteil: Overhead für die Erstellung und Verwaltung von vielen kleinen Tabellen bei großer Anzahl von Tenants
  • Gemeinsame Daten werden in einer großen Tabelle gehalten für alle TenantsTenant-spezifische Erweiterungen über eigene TabellenVorteil: weniger Tabellen, weniger OverheadNachteil: möglicherweise aufwändige, ineffiziente Joins um die Daten zu rekonstuieren
  • -Daten aller Tenants in einer einzigen Tabelle, Spalten im Varchar Datentyp für beliebige Erweiterungen-Vorteil: sehr geringer Verwaltungs- und Speicheroverhead-Nachteil: Rekonstruktion der Datentypen, Backups, Rowlevelaccesscontrolusw-&gt; keine one-size-fitsit all Lösung, jedoch ist das Universal Table Layout dasjenige mit dem meisten ResourceSharing- Wird so von force.com genutzt, eine Tabelle mit 500 variablen Spalten für alle 50000 tenants, spezielle Query-Optimierungs Routinen
  • Nach der Definition von Fielding zeichnen vor allem die Einschränkungen einen Stil ausHier 4 der wichtigsten EinschränkungenNur eine Code-Basis für alle Tenants: Einsparung von Wartungskosten, mehrere Codebasen angepasst für individuelle Tenants/Clients sind nicht zulässingGemeinsame Datenressourcen: keine eigenen Datenbanken pro Tenant zur Einsparung von OverheadsEs gibt eine Komponente zur Anpassung der Applikation an Kundenanforderungen: keine StandardapplikationKein client-spezifischer Zustand darf im Application Tier gehalten werden: Erhöht die Skalierbarkeit, keine Wartezeiten für ApplikationsthreadssEvaluation schwierig. Es müssten erste Applikationen nach dem Stil gebaut werden und dann getestet werden, ob sie die angestrebten Architektureigenschaften erfüllenAuch der Aufwand für die Entwicklung auf Basis des Stils müsste mit einer Ad-hoc Entwicklung verglichen werdenDas ist bisher auch für andere Stile nicht gemacht worden.- Hier nur sehr eingeschränkte Form der Evaluierung: Vergleich der Architekturkonzepte mit den Konzepten der neuen PaaS Plattformen
  • Force.com basiert auf der Salesforce Infrastruktur, lässt es zu dort eigene Applikationen zu erstellenWindows Azure ist Microsofts Antwort auf Cloud computing, viele MS technologien, .NET, basiert auf Windows Server 2008Google AppEngine: Java und Python Welt
  • Die Idee ist MT als Architekturstil zu dokumentierenVorteileLeichtere Entwicklung für zukünftige Projekte, schränkt den Entwurfsraum einKosteneinsparungen durch weniger Try-and-errorIngenieursmäßiger Ansatz, best PracticesTechnologieagnostik, keine Spezifika von .NET oder Enterprise Java, Fokus auf ArchitekturkonzepteQuantifizierung und Konkretisierung von Trade-offs, ZielkonfliktenFuture Work: stilbeschreibung verfeinern, detaillieren, Evaluation verbessern, SaaSapplikationen untersuchen
  • 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 />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×