Mandantenfähigkeit oder Mehrfachinstanz?

Ich versuche, eine webbasierte SaaS-Lösung zu erstellen, und bin auf eine Straße gestoßen, auf der ich nicht sicher bin, ob ich mehrere Mandanten oder mehrere Instanzen verwenden soll. Ich werde versuchen zu beschreiben, was ich erreichen möchte und welche Ansätze Vor- und Nachteile haben (meine Meinung, je nachdem, was ich gelesen habe). Bitte geben Sie Ihre Vorschläge an, falls ich bei einem Ansatz etwas verpasst habe.

Die Anwendung, die ich erstellen möchte, ist, wie bereits erwähnt, eine SaaS-Lösung, mit der Unternehmen ihre Konten erstellen können und jedes Konto / Unternehmen seine eigenen Benutzer, Kunden, Produkte, Dienstleistungen usw. hat. Jeder Benutzer; Wer ist ein Mitarbeiter des Unternehmens? In Bezug auf ein Konto / Unternehmen haben Sie nur Zugriff auf die Kunden, Produkte und Dienstleistungen des Unternehmens. Unternehmen können eine unbegrenzte Anzahl von Kunden, Produkten und Dienstleistungen haben. Daher sollte jedes Unternehmen über ein eigenes Rechenzentrum verfügen.

Zu diesem Zweck habe ich beschlossen, eine gemeinsam genutzte Datenbank (Speichern aller Benutzeranmeldeinformationen für Anmeldezwecke) und ein gemeinsames Schema für mehrere Datenbanken (Datenbank pro Konto / Unternehmen) zu erstellen. Grundsätzlich Multi Tenancy .

Dann schlug jemand vor, stattdessen Multi Instance zu verwenden, wobei jedes Unternehmen eine eigene Instanz der Anwendung (dh Code, Bibliotheken, Datenbank, Frameworks usw.) hat, die vollständig von den anderen Unternehmen getrennt ist. Das klingt besser, da ich mich nicht um eine zusätzliche Ebene kümmern muss, in der ich sicherstellen muss, dass die Benutzer jedes Mandanten nur auf die Daten ihres Unternehmens zugreifen können. Ich denke, es ist gut zu erwähnen, dass ich auf Docker angewiesen bin , um diesen Ansatz zu erreichen (ich habe ihn noch nie verwendet), aber ich denke, es fehlen Funktionen (dazu später mehr), die ich in Zukunft benötigen werde (zumindest habe ich das nicht getan) finde sie nicht mit ein wenig Suche).

Jeder Ansatz hat jedoch Vor- und Nachteile, sodass ich mich nicht für einen Ansatz entscheiden konnte. Hier ist eine Liste, die ich aber nicht kenne, da mir das Wissen in beiden fehlt, sodass es etwas geben könnte, das mir nicht bekannt ist, oder eine Lösung für ein Problem, das ich im Web nicht gefunden habe: [Jeder Ansatz hat eine geordnete Liste, von der ich einen Vergleich nach dem anderen verfolgte]

Multi Tenancy :

1. Gemeinsamer Host / Hardware, gemeinsam genutzter Code und mehrere Datenbanken.
2. Es ist einfacher , die Funktionalität des Codes zu erweitern und Fehler zu beheben (gemeinsam genutzter Code).
3. Es ist schwieriger , die Hardware zu erweitern (könnte einen Cloud-Dienst verwenden) oder die Datenbank eines einzelnen Mandanten auf ein anderes System zu verschieben, ohne Änderungen am Code vorzunehmen.
4. Wie bereits erwähnt, muss ich dem System vor allem eine zusätzliche Ebene hinzufügen, um sicherzustellen, dass der Benutzer tatsächlich zu seinem Unternehmen gehört und nicht auf die Informationen anderer Unternehmen zugreift.

Multi-Instanz :

1. Freigegebener oder nicht freigegebener Host / Hardware, Code pro Instanz und Datenbank pro Instanz.
2. Es ist schwieriger , die Funktionalität zu erweitern oder Fehler zu beheben (ich bin mir nicht sicher, ob es eine Möglichkeit gibt, dies in Docker zu tun, wo Sie einer Instanz oder einem Docker-Container Funktionalität / Feature hinzufügen und für die anderen bereitstellen können).
3. Es ist einfacher , die gesamte Instanz auf einen anderen Host / eine andere Hardware zu verschieben.
4. Als Instanz muss ich mich nicht um diese Ebene kümmern, da jede Instanz ihre eigene Datenbank hat.

Alle Vor- und Nachteile sind überflüssig, falls ich etwas manuell tun möchte (z. B. eine Instanz für jeden Mandanten manuell erstellen), und deshalb bezweifle ich die Docker-Lösung, es sei denn, es gibt eine Möglichkeit, dies zu lösen, was möglicherweise die Hauptlösung ist Grund der Frage. Ich würde es begrüßen, wenn Sie die Frage mit Verweisen auf die Lösungen beantworten würden und warum dieser Ansatz Ihrer Meinung nach besser ist als der andere.

Für den Fall, dass dies helfen würde (vielleicht?), Verwenden wir Laravel als Hauptframework für das Back-End (alle RESTfully).

Ich stelle mir im Moment genau die gleiche Frage.

Ich neige zu der Multi-Instance-Single-Tenancy-Lösung, habe aber noch keine endgültige Entscheidung getroffen. Lassen Sie mich einige meiner Gedanken teilen:

Der historische Hauptvorteil der mandantenfähigen Architektur besteht in einer besseren Nutzung der Infrastrukturressourcen durch Gegenseitigkeit (einzelnes Betriebssystem, einzelne Datenbank, einzelne Anwendungsschicht) und einer besseren Belegung dieser Ressourcen (wenn ein Benutzer nicht anwesend ist, kann ein anderer dieselbe Ressource verwenden). .

Dies vereinfacht auch den Software-Lebenszyklus erheblich : Sie stellen neue Versionen für eine Instanz bereit, alle Kunden werden gleichzeitig aktualisiert.

Es scheint jedoch, dass die jüngsten Fortschritte in der Cloud-Technologie die erste Klasse von Vorteilen in einer Architektur mit mehreren Instanzen (Instanz pro Kunde) weitgehend verfügbar machen (ich denke hier speziell an eine Plattform wie Jelastic, aber ich bin sicher, dass es andere gibt, die dies tun bieten die gleichen Funktionen):

• Container-basiertes PaaS
• Bereitstellung und automatische Skalierung von Containern (elastische Container)

Das Hardware- und Plattformmanagement ist also nicht mehr das Anliegen des Softwareanbieters. Die Ressourcen werden auf Infrastruktur- und Plattformebene viel effizienter als zuvor miteinander verbunden .

Es wird immer noch einen Overhead für mehrere Instanzen geben (einige Apps und Middleware werden N-mal anstatt nur einer ausgeführt), aber viel geringer als bei Verwendung einer separaten (virtuellen) Maschine pro Instanz. Die Datenbank kann trotzdem gemeinsam genutzt werden (ein Schema pro Instanz, mehrere Schemas pro DB-Server).

Ebenfalls :

• Die Automatisierung der Erstellung neuer Instanzen ist über die PaaS-API möglich
• Die Automatisierung der Bereitstellung neuer Versionen ist über die PaaS-API ohne Ausfallzeiten möglich (die Einrichtung erfordert einige Arbeit).
• Skalierung ist immer out, nie up. Wir müssen uns nicht um große Datenmengen auf Instanzebene kümmern.

Natürlich benötigen wir eine Art zentralen Dienst, der all dies automatisch verwaltet (z. B. die Erstellung einer Instanz, wenn ein neuer Benutzer ein Konto erstellt). Dies würde auch Zahlungs- und Lizenzprobleme, die Interaktion zwischen Instanzen usw. verwalten. Dieser zentrale Dienst ist möglicherweise recht komplex und schwer zu entwickeln, aber das Gute ist, dass wir ihn nicht im Voraus implementieren müssen (jetzt, da wir nicht viel haben Ressource), während Multi-Tenant von Anfang an in die App eingebunden werden müsste.

Das bringt mich zu den letzten Vorteilen der Entwicklung eines Einzelmieters für ein sehr frühes Startup-Projekt (vor der Investition):

• Dieselbe (oder fast dieselbe) Version der App kann lokal entweder als virtuelle Appliance oder Docker-Container oder sogar auf einem vom Kunden verwalteten Computer bereitgestellt werden (einige Unternehmen zögern immer noch mit der Cloud, und dies kann einem frühen Start helfen, dies nicht zu tun wichtige Early Adopters verdrängen)
• Wenn Sie ein Produkt mit begrenzten Ressourcen schneller herausbringen (die Anwendungsschicht und das Datenbankschema sind weniger komplex), können Sie ein "dummes" Einzelinstanz-Einzelmandantenprodukt (MVP) für Erstanwender herausbringen und den Geschäftswert der App anzeigen potenziellen Investoren und fügen Sie später die gesamte Cloud-Automatisierung hinzu
• Kann als Verkaufsargument für Kunden angesehen werden, die sich Sorgen um die Datensicherheit machen: Die Daten sind besser gekapselt, da jeder Kunde sein eigenes Schema oder sogar eine eigene Datenbank hat. Viel geringeres Risiko von "Verschütten"

NB: Ich denke hier offensichtlich an eine Geschäfts-App, bei der Kunden Unternehmen (jeweils mit mehreren einzelnen Benutzern) und keine Einzelpersonen sind. Es wäre nicht sinnvoll, für jeden einzelnen Benutzer eine eigene Instanz einer App auszuführen (oder?)

Die Unterstützung beider Optionen ist ebenfalls möglich (ein Pool von Mandanten über mehrere Instanzen hinweg).

Ich bevorzuge die Ursache der natürlichen Isolation für mehrere Instanzen. Die Instanz jedes Kunden wird in seinen eigenen Prozessen ausgeführt und seine Daten werden in seiner eigenen Datenbank isoliert. Auf Wunsch können Sie Instanzen pro Kunde / Instanz auf neue Versionen aktualisieren.

Mandantenbasierte Systeme sind mit einem Informationssicherheitsrisiko verbunden. Überlegen Sie nur, wie einfach es ist, eine "WHERE tenantId = x" -Klausel zu vergessen. Der Hauptgrund für die Verwendung eines mandantenfähigen Systems ist die Leistung. Prozesse sind sehr schwer. Wenn Sie einen Prozess gemeinsam nutzen, können Sie möglicherweise mehr aus einer Maschine herausholen. Dies war meiner Meinung nach in einer 32-Bit-Welt wahrer als heutzutage auf 64-Bit-Computern mit viel mehr RAM.

Ein System mit mehreren Instanzen würde möglicherweise etwas mehr Tools benötigen, um die Umgebung wie Datenbanken und Webanwendungsinstanzen zu erstellen und zu konfigurieren. Man kann argumentieren, dass Sie dieses Skript sowieso auch für Ihre Einzelinstanzbereitstellungen benötigen. Dies hat auch andere Vorteile, wie die Möglichkeit, Entwicklungs- und Testumgebungen einzurichten

Ich würde die Mandantenfunktionen so lange auslassen, bis Sie sich dafür einsetzen können (Engineering-Kosten im Vergleich zu Einsparungen bei der (Hardware-) Infrastruktur durch Prozessfreigabe).