Zum Inhalt springen

Cookies ūüć™

Cookies helfen uns, Ihnen als Nutzer in Zukunft bessere Informationen und eine verbesserte Benutzererfahrung zu bieten. Details

Laravel: Welche Art von Multitenant Architektur sollte man wählen?

Chris Wolf

Chris Wolf

Laravel Multi Tenancy.
Multitenancy ist eine Architektur, bei der eine einzige Instanz einer Softwareanwendung mehrere Kunden bedient. In einer sogenannten "mandantenfähigen Umgebung" nutzen alle Kunden denselben Anwendungscode und dieselbe Datenbank, aber jeder Kunde hat einen eigenen Satz von Anwendungsdaten. Insbesondere SaaS-Produkte basieren oft auf einer mandantenfähigen Architektur.

Der Hauptvorteil einer mandantenf√§higen Architektur besteht darin, dass sie Skaleneffekte erm√∂glicht: Dieselbe Codebasis und Infrastruktur kann f√ľr mehrere Kunden genutzt werden, sodass die Entwicklungs- und Wartungskosten sinken. Updates und Upgrades m√ľssen nur einmal durchgef√ľhrt werfrn um f√ľt alle Kunden zur Verf√ľgung zu stehen.

In diesem Artikel gehen wir insbesondere auf die Datenbankmodelle und die Programmierung ein. Auf Domainmodelle gehen wir nicht ein.

Was ist Mandantenfähigkeit?

In der Softwaretechnik ist Multitenancy ein Prinzip in der Softwarearchitektur, bei dem eine einzelne Instanz der Software auf einem Server läuft und mehrere Mandanten (Tenants) bedient. Ein Tenant ist eine Gruppe von Nutzern, die den gleichen Zugriff mit bestimmten Privilegien auf die Softwareinstanz haben.

Bei Multi-Tenancy ist eine Softwareanwendung so konzipiert, dass jeder Tenant √ľber einen eigenen Bereich mit Anwendungsdaten, der Konfiguration, der Benutzerverwaltung und der mandantenspezifischen Anpassungen verf√ľgt. Der Begriff wird auch in der Netzwerkarchitektur verwendet, wo ein einziger Server mehrere unabh√§ngige Tenants oder Organisationen hostet.

Was ist der Nutzen bzw. Vorteil von Mandantenfähiger Software?

Mandantenf√§hige Software hat viele Vorteile, die sie zu einer attraktiven Option f√ľr Unternehmen machen. Einer der wichtigsten Vorteile ist, dass Unternehmen durch die gemeinsame Nutzung von Ressourcen Kosten sparen k√∂nnen. Au√üerdem kann die Mandantenf√§higkeit Unternehmen dabei helfen, ihre Ressourcen besser zu verwalten.

Der eigentliche Nutzen warum man ein System mandantentauglich entwirft, ist sodass es von Kunden genutzt werden kann, die wiederum eigene Kunden in ihren "Bereich" einbringen.

Zur verdeutliching hilft diese Grafik, die eine Multitenancy-Architektur mit einer gemeinsamen Datenbank zeigt, um es Steuerberatungskanzleien zu erm√∂glichen, ihre Kunden √ľber die Software zu verwalten.

Welche Multi-Tenant-Architektur ist geeignet?

Welche Art von mandantenf√§higer Architektur f√ľr dein Unternehmen geeignet ist, h√§ngt von einer Reihe von Faktoren ab, darunter die Sensibilit√§t der Daten, rechtliche Anforderungen ans Projekt, die Anzahl der Mandanten und die Organisationsstruktur.

Es gibt zwei Haupttypen von mandantenfähigen Architekturen: gemeinsame Datenbank oder getrennte Datenbanken. Eine weitere Umsetzungsmöglichkeit ist die Nutzung des gleichen Schemas mit geprefixten Tabellen innerhalb einer Datenbankinstanz. Wordpress nutzt diesen Ansatz wenn man eine Multisite-Installation verwendet.

Multitenancy mit einer gemeinsamen Datenbank

In einer Architektur mit gemeinsamer Datenbank teilen sich alle Mandanten dieselbe Datenbankinstanz. Das bedeutet, dass die Daten von mehreren bzw. allen Tenants in der gleichen Datenbank gespeichert werden. Die Trennung der Daten auf die Tenants wird i.d.R. durch eine groupid oder organisationid ermöglicht und findet damit auf Codeebene statt. Diese Form der Implementierung bietet keine physische Trennung der Daten. Eine eine gemeinsame Datenbank kann immer dann verwendet werden, wenn es keine rechtlichen Anforderungen an umfangreichere Datentrennung gibt.

Bei Multitenant-Implementierungen die mit einer gemeinsamen Datenbank arbeiten wird h√§ufig die geringere Sicherheit als ein Nachteil angef√ľhrt weil Daten von mehreren Kunden in der gleichen Datenbank liegen. Wir halten das f√ľr ein Scheinargument. √úbliche und weit verbreitete Shopsysteme funktionieren beispielsweise nach dem gleichen Prizip: Kundendaten werden in einer zentralen Datenbank abgelegt. Weiterhin ist es eine Frage von sauberer und robuster Implementierung um sicherzustellen dass die Trennung der Mandanten sauber funktioniert. Die Daten auf verschiedene Datenbanken aufzuteilen sollte unserer Meinung nach keine Abk√ľrzung sein um an der Softwarequalit√§t oder der sauberen Implementierung zu sparen. Die Testabdeckung des Codes hier von besonderer Bedeutung.

Vorteile von Multitenancy mit einer Datenbank

Ein Mandantenf√§higes Laravel System mit einer zentralen Datenbank erfreut sich grunds√§tzlich allen Vorteilen die Laravel bietet und sorgt damit f√ľr eine hoher Developer Experience und effizientes entwickeln.

Weitreichende Eingriffe ins Laravel Kernsystem bleiben aus und erleichern auch die Wartbarkeit eines Projekts bei zuk√ľnftigen Versionsupdates.

Ohne den Bedarf f√ľr jeden Mandanten eine eigene Datenbank anzulegen, lassen sich neue Mandanten schnell durch einen simplen Registrierungsprozess onboarden - quasi mit Boardmitteln von Laravel.

Multitenancy mit getrennten Datenbanken

Bei einer Architektur mit getrennten Datenbanken hat jeder Tenant seine eigene Datenbankinstanz. Das bedeutet, dass die Daten jedes Tenants von den anderen Tenants isoliert sind. Eine separate Datenbankarchitektur wird in der Regel verwendet, wenn es rechtliche Anforderungen zur Datentrennung gibt.

Achtung: Sackgasse!

Diese Art der Umsetzung ist deutlich aufw√§ndiger und damit kostenintensiver. Wenn dieser Weg einmal eingeschlagen wird, kann er au√üerdem nur schwer bis gar nicht r√ľckg√§gnig gemacht werden. Daher ist bereits zu Projektbeginn eine genaue Betrachtung unbedingt erforderlich. Ohne absolut notwendige Anforderungen ist eine Umsetzung mit mehreren Datenbanken nicht zu empfehlen.

Mehrere Datenbanken mit Laravel nutzen

Die Entwicklung von mandantenf√§higer Software kann auf viele verschiedene Arten erreicht werden, die aufw√§ndigere Methode ist die Verwendung mehrerer Datenbanken. Dieser Ansatz kann mit dem Laravel-Framework verwendet werden und erm√∂glicht es dir, f√ľr jeden Mandanten eine eigene Datenbank zu erstellen. Dadurch kann eine physische Isolierung der Daten erreicht werden. Diese Umsetzungsvariante ist ideal f√ľr Unternehmen, die eine umfassende Datentrennung ben√∂tigen.

Wenn pro Mandant eine Datenbank verwendet werden soll, empfehlen wir die Nutzung von Spaties Package "Multitenancy". Es erleichtert den Umgang mit separaten Datenbanken pro Mandant und liefert auch hilfreiche Artisan-Commands zu Verwaltung mit.

Zusätzliche Herausforderungen durch ein Multi-Database Setup

Wenn mehrere Datenbanken genutzt werden, wird es erforderlich stets zu wissen, mit welchem Tenant gerade gearbeitet werden soll. D.h. alle Requests, Artisan-Commands, Queues etc. m√ľssen ihren Mandanten kennen (Tenant-Aware sein).

Onboarding neuer Kunden

Auch hier ist der Aufwand gr√∂√üer als gew√∂hnlich. F√ľr jeden neuen Mandanten muss beim Onboarding (vgl. bei der Registrierung) eine neue Datenbank erstellt werden. Nat√ľrlich kann dieser Prozess automatisiert werden, es ist jedoch ein zus√§tzlicher und komplexer Infrastrukturanteil der mit Aufw√§nden verbunden ist, die eingespart werden k√∂nnen.

Wenn dieser Schritt nicht automatisiert wird, k√∂nnen neue Mandanten nur manuell oder Teilmanuell z.B. mit einem Artisan-Command hinzugef√ľgt werden.

Wirkliche Vorteile von Mandantenfähiger Software

Die Vorteile der mandantenfähigen Softwareentwicklung liegen darin, dass sie Skaleneffekte voll ausschöpft, nahezu sofortige Elastizität bietet und die Softwarequalität durch eine höhere Testabdeckung verbessert. Eine einzige Instanz der Software kann mehrere Mandanten bedienen, was die Kosten im Vergleich zu herkömmlichen Entwicklungsmodellen senkt.

Umsetzung mit Laravel Boardmitteln

Weil eine Umsetzung mit mehreren Datenbanken nur sehr selten benötigt wird, beschränken wir uns hier auf die Umsetzung von Multitenancy mit einer einzeilnen Datenbank.

Grunds√§tzlich bringt Laravel bereits alles mit was gebraucht wird, um ein mandantenf√§higes System zu entwickeln. F√ľr eine ein-Datenbank-L√∂sung werden auch keine zus√§tzlichen Packages ben√∂tigt. Was es braucht, ist ein Model und eine Tabelle Organisations. In unseren Projekten bevorzugen wir die Bezeichnung "Organisation" f√ľr einen Mandanten, Tenant oder Group w√§re aber genauso m√∂glich.

Die jeweiligen Ressourcen die die App verwaltet, werden nun an diese Organisation gebunden. Dazu braucht es in den jeweiligen Tabellen nur eine Spalte "organisation_id". Via PhpUnit-Tests stellen wir l√ľckenlos sicher dass kein Mandant die Daten des anderen sieht. Test Driven Development (TDD) ist in solchen Projekten ein unerl√§sslicher Ansatz. An den Kunden muss an dieser Stelle bereits fr√ľhzeitig kommuniziert werden warum diese Aufw√§nde erforderlich und lohnenswert sind.

Unsere Empfehlung

Multitenancy mit einer einzigen Datenbank ist eine gute L√∂sung, weil sie Skaleneffekte, nahezu sofortige Elastizit√§t und eine verbesserte Softwarequalit√§t erm√∂glicht. Au√üerdem bietet sie eine Trennung zwischen dem Eigent√ľmer/Betreiber der Anwendung und den einzelnen Tenants, was die Sicherheit und Verwaltbarkeit erh√∂ht.

Sofern es keine rechtlichen Anforderungen gibt, die eine tatsächliche, physische Datentrennung erforderlich machen, ist eine Mehrmandantenlösung mit einer Datenbank völlig ausreichend und zu empfehlen.


Weiteres Material:

- Vortrag von Tom Schlick zu Multitenancy in Laravel, Laracon 2017

- Wikipedia zu Mandantenfähiger Software

- Foto von Joshua Coleman

Bereit zu starten?

Mit uns haben Sie einen zuverlässigen Partner an Ihrer Seite, der sichere, hochwertige und planbare Softwarelösungen bietet.