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.
3. 28.04.2008:
āSAPs neue Mittelstandssoftware
āBusiness By Designā klemmtā
25.10.2008:
āSAP will sich von
Outsourcing-Tochter trennenā
19.02.2009:
āSAP dementiert Verkaufsstopp
fĆ¼r āBusiness by Designāā
Source: heise.de
3
4. Single-Tenancy Multi-Tenancy
Tenant1 Tenant2 Tenant3 Tenant1 Tenant2 Tenant3
App App App App
Database Database Database Database
OS OS OS OS
Hardware Hardware Hardware Hardware
4
5. Challenges
Lack of Ad-hoc Technology
Documentation Solutions Focus
5
6. Architectural Styles
An architectural /style is a coordinated set of
ļ§ Client Server ļ§ Blackboard
architectural constraints that restricts
ļ§ Pipe-and-Filter ļ§ C2
the roles / features of architectural elements
and the ļ§ Peer-to-Peer
allowed relationshipsREST (WWW)
ļ§ among those elements
within any architecture that conforms to that style.
ļ§ Mobile Code ļ§ SPIAR (AJAX) [Fielding2000]
Idea: Multi-tenancy Style
6
11. Multi-tenant Database
Private Table Layout Extension Table Layout Universal Table Layout
Account27
AID Name Robot Speed Account33
1 ABC X 20 AID Name
2 DEF Y 50 1 GHI
Account46
AID Name Lines
1 JKM 12
11
12. Multi-tenant Database
Private Table Layout Extension Table Layout Universal Table Layout
Industrial-Account
Tenant ID Row Robot Speed
Account-Extension
27 0 X 20
Tenant ID Row AID Name
27 1 Y 50
27 0 1 ABC
27 1 2 DEF Telecommunication-Account
33 0 1 GHI Tenant ID Row Lines
46 0 1 JKM 46 0 12
12
14. Shared
Single Code Base
Architectural
Architectural Data Resources
Constraints
Properties
STATE
Customization Component Stateless Application Tier
14
15. Architectural Trade-offs
Resource Sharing
vs. Security / Availability
Complexity
vs. Time to market
Customizability
vs. Maintainability
15
18. Client Tier Application Tier Data Tier
Web / Worker Blobs, Tables,
Roles SQL Azure
Application Multi-tenant
Browser Cache (optional)
Load Balancer
Threads Database
REST
Asynch,
Customization Synch Data
REST Transfer
Meta-Data Meta-Data
Rich Client
Manager
Worker Role
18
19. Client Tier Application Tier Data Tier
JSP / Servlet,
Google Big Table
Python
Application Multi-tenant
Browser Cache (optional)
Load Balancer
Threads Database
REST
Asynch,
Customization Synch Data
REST Transfer
Meta-Data Meta-Data
Rich Client
Manager
App Engine
Services
19
20. ā¦and SAP? ?
27.01.2010
āMit dem Featurepack 2.5,
das Mitte dieses Jahres erscheint,
bekommt Business ByDesign
eine Multi-Tenant-Architekturā
Peter Lorenz
Leiter SME Solutions SAP
Source: isreport.de
20
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:-"Das System hat noch nicht die erforderliche Performance und hat noch zu viele Aussetzer", 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&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-> 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