Was ist eine Multi-Tenancy-Architektur?

Der Begriff “Tenancy” stammt ursprünglich aus dem Französischen und beschrieb dort ein Pacht- oder Mietverhältnis. Analog dazu bezeichnet Multi-Tenancy in der IT ein System, das mehrere “Mieter” (Tenants) gleichzeitig bedient. In der deutschen Sprache wird dafür häufig der Begriff “Mandantenfähigkeit” verwendet.

Eine Multi-Tenancy-Architektur versorgt mit einer einzigen Softwareinstanz mehrere unterschiedliche Nutzer. Jeder User hat zwar seine eigenen Zugriffsrechte, Konfigurationsdetails, Daten und Datenpräsentationen, greift jedoch auf dieselbe Software, Systemumgebung und Hardware zu.

Ein Nutzer muss dabei nicht zwingend eine einzelne Person sein. Es kann sich auch um eine Nutzergruppe handeln, in der alle Anwender dieselben Zugriffs- und Nutzungsrechte haben.

Im Gegensatz dazu erfordern Single-Tenancy-Architekturen für jeden Nutzer eine eigene Softwareinstanz (Multi-Instances-Architektur). Dafür kommen virtualisierte Systemumgebungen zum Einsatz: Auf einem Server wird für jeden Nutzer ein eigener virtueller Server eingerichtet.

Multi-Tenancy-Architekturen kommen ohne Virtualisierung aus, weil sie selbst die Fähigkeit mitbringen, mehrere Nutzer vollkommen getrennt voneinander zu bedienen. Sie können also für alle Nutzer mit derselben Hardware und Systemumgebung betrieben werden.

Multi-Tenancy-Software muss bereits während ihrer Entwicklung auf den Mehrnutzerbetrieb hin konzipiert werden (Native Multi Tenancy). Denn Aspekte wie Datensicherheit, Performance und Konfigurierbarkeit müssen bei mandantenfähiger Software anders behandelt werden als bei Single-Tenancy-Architekturen.

Ein wichtiger Vorteil von Multi-Tenancy besteht darin, dass zwischen mandantenabhängigen und mandantenübergreifenden Daten und Objekten unterschieden werden kann:

• Mandantenabhängig sind Daten, Datenmodelle und -präsentationen, Konfigurationen, Zugriffsrechte oder das Firmenlogo.
• Mandantenübergreifend sind dagegen beispielsweise Ländernamen, Postleitzahlen-Listen, Währungskurse oder standardisierte Branchenkataloge. Anpassungen bei diesen Daten und Objekten werden in der Multi-Tenancy-Architektur automatisch allen Mandanten zur Verfügung gestellt. Das fördert die Datenkonsistenz und ermöglicht es, besonders benutzerfreundliche Software zu schreiben.

Es gibt drei Varianten, wie Datenbanken in einer Multi-Tenancy-Architektur eingebunden werden können.

Ein Schema definiert, wie einzelne Tabellen (“Relationen”) einer Datenbank miteinander verknüpft sind. In der hier beschriebenen Variante besitzt jeder Nutzer eine eigene Tabelle. Alle Tabellen sind mit derselben Datenbank verknüpft. Diese Variante bietet sich an, wenn alle Nutzer mit denselben Datenfeldern arbeiten. Der Vorteil liegt in der einfachen Einrichtung und der leichten Skalierbarkeit.

In dieser Variante unterhält jeder Nutzer sein eigenes Datenbankschema, in dem er eigene Datenfelder definiert. Diese Variante wird häufig gewählt, wenn die Anwendung an sich zwar ein einheitliches Datenbankschema nahelegt, aber aufgrund unterschiedlicher Anforderungen an die Daten einzelne Datenfelder individuell definiert werden müssen. Ein Beispiel dafür sind internationale Daten, die je nach Land verschiedene Datumsformate, Währungen und regulatorische Anforderungen haben.

Bei dieser Variante erhält jeder Nutzer eine eigene Datenbank. Das bietet maximale Flexibilität und eine besonders starke Isolation der Daten zwischen den Nutzern. Andererseits steigt mit dieser Lösung der Aufwand des Providers für das Management, die Wartung und die Skalierung.

Single-Tenancy bedeutet, dass jeder Kunde seine eigene Softwareinstanz bekommt. Diese läuft auf einem dedizierten virtuellen Cloud-Server für ihn alleine. Auf diese Weise kann der Tenant sogar auf den Quellcode zugreifen, ohne damit andere Nutzer zu beeinträchtigen. Zudem kann er alleine die gesamte Performance des Cloud-Servers nutzen, während bei Multi-Tenancy mehrere Benutzer auf dieselben Systemressourcen zugreifen.

Fast alle SaaS-Dienste basieren auf Multi-Tenancy, denn im Vergleich mit Single-Tenancy ist diese Architektur deutlich kostengünstiger. Sie erlaubt eine effizientere Nutzung der Hardwareressourcen, erfordert weniger Wartungsaufwand und ist leichter skalierbar. Der Anbieter kann Backups und Aktualisierungen für sämtliche Tenants gleichzeitig durchführen.

Bei der Single-Tenancy-Architektur müssen diese Aktualisierungen für jede Instanz einzeln vorgenommen werden. Allerdings können so unterschiedliche Softwareversionen für verschiedene Nutzer parallel betrieben werden.

Allgemein gesprochen ist die Single-Tenancy-Architektur aufwendiger und damit teurer, bietet dem Kunden aber mehr Kontrolle über seine Systemumgebung und ermöglicht flexiblere Anpassungen. Umgekehrt ist die Multi-Tenancy-Architektur kostengünstiger und flexibler skalierbar.

Die nachstehende Tabelle fasst die Unterschiede auf einen Blick zusammen.

Die Geschichte von Multi-Tenancy begann in den 1960er-Jahren: Große Rechenzentren boten Rechenzeit in Form von kleinen “Zeitscheiben” (Time Slices) an. Allerdings existierte damals noch keine Client-Server-Architektur. Vielmehr griffen die Nutzer über Terminals ohne eigene Rechenleistung auf das Rechenzentrum zu. Diese Terminals bestanden nur aus Bildschirm, Tastatur und Modem. Abgerechnet wurde die Nutzung über den Verbrauch an Rechenzeit, RAM und Speicher.

In den 1990er-Jahren begannen Rechenzentren, die Anwendungen von Kunden zu hosten. Diese Anbieter, Application Service Providers (ASPs) genannt, mussten dazu oft für jede Software einen eigenen Server bereitstellen oder jede Software in einem eigenständigen Prozess ablaufen lassen.

Erst später entwickelte sich die Virtualisierungstechnik, welche die oben beschriebene Multi-Instances-Architektur mit mehreren virtuellen Servern auf derselben Hardware ermöglichte.

Der bislang letzte Evolutionsschritt bestand in der Entwicklung von mandantenfähigen SaaS-Anwendungen wie wir sie heute kennen. Diese laufen in der Cloud und können viele Benutzer gleichzeitig bedienen.

Multi-Tenancy-Architekturen haben viele Vorteile, sowohl für die Provider als auch für deren Kunden.

Der Provider kann Anpassungen an der Grundkonfiguration der Software, am Datenbankschema oder dem Server für alle Benutzer gleichzeitig vornehmen. Ebenso leicht lassen sich diese Änderungen an die Nutzer kommunizieren, sei es in der Dokumentation oder direkt auf der Benutzeroberfläche.

Die enormen Cyberbedrohungen verlangen von Providern ein kontinuierliches Sicherheitsmonitoring der Systeme. Eine Multi-Tenancy-Architektur bedeutet in diesem Zusammenhang, dass nur eine einzige Softwareinstanz überwacht werden muss. Auch die Lizenzkosten der Überwachungssoftware sind in diesem Fall niedriger als bei einer Vielzahl voneinander isolierter Instanzen. Und nicht zuletzt lassen sich Patches im Bedarfsfall rasch installieren.

Kommen neue Kunden hinzu oder benötigt ein Nutzer mehr Speicherplatz, ist die Multi-Tenancy-Architektur ebenfalls von Vorteil: Einzig der Cloud-Server, auf dem die Software läuft, muss gegebenenfalls skaliert werden, was für die Provider problemlos möglich ist.

Leistungsdaten wie die Anzahl der Nutzerzugriffe, verbrauchte Rechenzeit oder registrierte Störungen sind wertvolle Hinweise für die Optimierung von Software und Systemumgebung. Multi-Tenancy erlaubt eine einfache und zentrale Analyse dieser Daten. Selbstverständlich bleibt der Datenschutz dabei gewahrt.

Es gibt Software, die es den Nutzern ermöglicht, einzelne Kreationen anderen Anwendern zugänglich zu machen. Dabei ist etwa an Programmiercode oder Design-Templates zu denken. In einer Multi-Tenancy-Architektur ist das unkompliziert und sicher umsetzbar.

Die Lizenzkosten für die Software, das Betriebssystem und andere Komponenten sind niedrig, da ungeachtet der Nutzeranzahl nur eine Instanz erforderlich ist. Wie erwähnt reduziert sich auch der Arbeitsaufwand des Providers für Konfiguration und Wartung, was sich ebenfalls in günstigeren Preisen niederschlägt.

Wie jede Technologie haben Multi-Tenancy-Architekturen auch potenzielle Nachteile:

• Fehlerhafte Konfigurationen und Updates wirken sich gleichzeitig auf alle Nutzer aus.
• Das initiale Aufsetzen der Architektur ist komplexer und aufwendiger.
• Die Absicherung der Nutzerdaten ist aufwendiger, weil diese nicht so stark voneinander isoliert sind wie in der Multi-Instances-Architektur.
• Die einzelnen Nutzer können die Software weniger flexibel individualisieren und nicht auf den Quellcode zugreifen.

Hier einige Beispiele für Anwendungsformen von Multi-Tenancy-Architekturen:

• Webhosting: Die großen Provider bieten Web-Präsenzen an, bei denen sich mehrere Kunden einen Server und eine IP-Adresse teilen.
• CMS: Verschiedene Content-Management-Systeme und Onlineshops können mehrere Mandanten auf derselben Instanz bedienen.
• ERP: Die meisten ERP-Systeme sind mandantenfähig, sodass beispielsweise ein Konzern seinen Tochtergesellschaften separate Datenbanken bereitstellen kann.
• Buchhaltungssoftware: Einige mandantenfähige Accounting-Programme bieten Buchhaltern die Möglichkeit, mehrere Klienten mit einer einzigen Softwarelizenz zu bedienen.
• SaaS: Moderne SaaS-Produkte sind grundsätzlich mandantenfähig. Neue Kunden können sich selbstständig registrieren und anschließend die Software sofort nutzen.

Sie möchten mandantenfähige SaaS-Anwendungen für Ihr Unternehmen nutzen? Dann sollten wir uns unterhalten. Die Experten der ahd analysieren Ihren Status quo, geben Programm-Empfehlungen und übernehmen die Implementierung sowie das Change-Management. Insbesondere für Microsoft 365 sind wir Ihr kompetenter Ansprechpartner. Kontaktieren Sie uns jetzt für eine unverbindliche Erstberatung!