Suchen

Definition: mandantenfähige Systeme Was ist eine Multi-Tenancy-Architektur?

Autor / Redakteur: M.A. Dirk Srocke / Florian Karlstetter

Multi-Tenancy-Architekturen oder mandantenfähige Systeme bedienen mit einer Software-Instanz verschiedene Nutzer. Dieser Ansatz soll im Idealfall Lizenzkosten sparen, das Management erleichtern und Ressourcen effizient nutzen.

Multi-Tenancy beschreibt mandantenfähige Systeme und ist im Bereich Cloud Computing ein weit verbreiteter Begriff.
Multi-Tenancy beschreibt mandantenfähige Systeme und ist im Bereich Cloud Computing ein weit verbreiteter Begriff.
(Bild: gemeinfrei (geralt / pixabay) / CC0 )

Der Begriff Multi-Tenancy leitet sich einerseits vom lateinischen Begriff „multi“ im Sinne von „zahlreich“ ab. Das englische „Tenancy“ wurde derweil dem Alt-Französischem entlehnt und beschreibt ein Pacht- oder Mietverhältnis. Entsprechend bezeichnete IT-Systeme bedienen zugleich mehrere Kunden respektive Auftraggeber. Ein Tenant muss dabei nicht zwingend mit einem Einzelanwender gleichgesetzt werden, sondern beschreibt wahlweise auch eine Nutzergruppe mit gleichen Zugriffs- und Nutzungsrechten. Im Deutschen hat sich in diesem Kontext auch das Adjektiv „mandantenfähig“ etabliert.

Zu unterscheiden sind einerseits Multiple Instances Multi-Tenancy. Hierbei werden Mandanten einzelnen Anwendungsinstanzen zugeordnet. Nachfolgend gehen wir allerdings von einer Native Multi-Tenancy aus; bei dieser ist der Anwendung bewusst, dass sie mehrere Mandanden bedient.

Solche Multi-Tenancy-Umgebungen unterscheiden sich von virtualisierten Umgebungen, bei denen klassische Anwendungen (Single-Tenancy) in einer isolierten Umgebung ausgeführt werden. Im Gegensatz dazu teilen sich die Nutzer eines mandantenfähigen Systems tatsächlich eine identische Anwendung(sinstanz), die auf ein und demselben Betriebssystem samt Hardware läuft sowie eine einheitliche Datenhaltung nutzt.

Anforderungen an Multi-Tenancy

Dem entsprechend muss Multi-Tenancy-Software bereits während ihrer Entwicklung auf den Mehrnutzerbetrieb ausgelegt werden. Das beinhaltet Aspekte wie Isolierung und Datensicherheit, Performance und Service Level sowie die Konfiguration der Anwendung.

Konkret sollen mandantenfähige Systeme also insbesondere sicherstellen, dass Daten einzelner Mandanten nicht vermischt werden. Diese Anforderung kann beispielsweise über Namensräume gelöst werden; hierbei greifen Tenants ausschließlich auf Objekte einer ihnen zugeordneten Sub-Domäne zu, seien es Datastores oder Auftragswarteschlangen.

Alternativ lassen sich Multi-Tenancy-Anwendungen auch mit unterschiedlich mandantenfähigen Backendsystemen koppeln – beispielsweise wäre es möglich, für jeden Mandanten einer Multi-Tenancy-App eine eigene Single-Tenancy-Datenbank zu betreiben. Um die Performance zu steigern, ließen sich Mandanten andererseits gleichmäßig über „sharded“ Datenbanken verteilen – so ließen sich die Vorzüge eines Multi-Tenancy-Datenbankmanagementsystems nutzen, gleichzeitige und leistungshungrige Zugriffe mehrerer Tenants auf eine Datenbank aber reduzieren.

Des Weiteren sollten Multi-Tenancy-Architekturen auf die Anforderungen einzelner Mandanten eingehen. Das umfasst etwa die Anpassung an individuelle Unternehmenslogos, Workflows, Datenmodelle oder Zugriffsrechte.

Motivation sowie Pro und Kontra

Damit sind Multi-Tenancy-Lösungen zunächst komplexer zu erstellen, können im Betrieb jedoch deutlich effizienter arbeiten. Weil sich mehrere Tenants eine Anwendungsinstanz teilen, lassen sich Overheads reduzieren und (Hardware)Ressourcen effizienter nutzen. Wird auch unterhalb des eigentlichen Multi-Tenancy-Programms laufende Software gemeinsam genutzt, braucht es zudem weniger Lizenzen als bei Single-Tenancy-Umgebungen – beispielsweise für das Betriebssystem oder die Datenbankmanagementlösung.

Betreiber können Multi-Tenancy-Lösungen zudem bequemer aktualisieren. Während bei Single-Tenancy-Lösungen für jeden Kunden ein Update aufgespielt werden muss, wird dieser Prozess hier nur noch ein einziges Mal nötig.

Auf der Kehrseite bedeutet das allerdings auch, dass fehlgeschlagene Updates alle Mandanten zugleich betreffen. Gleiches gilt für spezielle Features – die lediglich von einer kleinen Nutzergruppe gewünscht, dann aber samt eventueller Wechselwirkungen oder Bugs für alle Anwender implementiert werden. Als mögliche Behelfslösung kann hier der gleichzeitige Betrieb mehrerer Anwendungsversionen dienen.

Umstritten ist der Nutzen von Multi-Tenancy-Anwendungen für das Data Mining seitens der Service-Betreiber. Einerseits sind kundenübergreifend in einer Datenbank gespeicherte Informationen leichter zu erschließen als verteilte Daten. Dem entgegen stehen allerdings Compliance-Anforderungen, denen zufolge Provider eben keinen Zugriff auf vertrauliche Informationen ihrer Kunden erhalten sollen. Überdies werden operative Daten vor einer weiteren Auswertung in der Regel ohnehin in eine zusätzliche Mining-Datenbank überführt.

Vorläufer und Entwicklung

Die Vorläufer von Multi-Tenancy-Infrastrukturen lassen sich bereits den 1960er Jahren ausmachen. Damals wurde die Rechenzeit von Mainframes vermietet und verschiedenen Nutzern per Timesharing zur Verfügung gestellt; existierende Programme wurden häufig von unterschiedlichen Anwendern wiederverwendet.

Seit den 1990er Jahren aufkommende Web-Anwendungen näherten sich dem heutigen Modell weiter an. E-Mail-Anbieter bedienten beispielsweise mit einer einzigen Instanz all ihre Nutzer. Als Weiterentwicklung bieten die heutigen Multi-Tenancy-Anwendungen zusätzliche Anpassungsmöglichkeiten für bestimmte Nutzergruppen.

(ID:45561086)

Über den Autor