Unterstützung der Mandantenfähigkeit

Was sind die typischen Herausforderungen bei der Konvertierung einer App mit einem Mandanten in eine App mit mehreren Mandanten? Sicherheit und Datenisolation sind für mich die wichtigsten. Was sind andere?

Ich bin einer der Architekten für einen ziemlich bedeutenden Automatisierungsaufwand, und in der Vergangenheit war es nur unser Unternehmen, das ihn einsetzte. Wir möchten es auch anderen ermöglichen, es zu nutzen. Jedes Mal, wenn wir davon sprechen, "es mandantenfähig zu machen", dreht sich die Konversation darum, Benutzer mit einem Mandanten von den Daten fernzuhalten, die ein anderer Mandant besitzt, und sicherzustellen, dass Benutzer mit einem Mandanten keine (absichtlich oder versehentlich) Auswirkungen auf einen anderen haben können Mieterumgebungen. Ich frage mich, ob Sicherheit / Datenisolation hier wirklich die einzigen Hauptprobleme sind oder ob es einige andere Hauptprobleme gibt, über die wir einfach nicht nachdenken.

architecture multitenancy

— Grant Palin
quelle

Die einfachste Lösung? Eine neue Instanz des gesamten Systems, einschließlich Hardware, leer, von Grund auf neu, ein neues System pro Mandant. Wenn das System und die Daten sehr wertvoll sind, kann dies eine ziemlich gute Option sein. Wenn Sie nicht für jede Instanz neue Hardware mögen, verwenden Sie die Virtualisierung. Es ist vielleicht nicht besonders effizient, spart aber sicherlich eine Menge Kopfschmerzen.

— SF.

Aus gestalterischer Sicht ist dies wahrscheinlich am einfachsten, aus administrativer Sicht scheint dies jedoch nicht der Fall zu sein. Zumindest unsere Systemadministratoren sind von diesem Vorschlag nicht sehr begeistert. (Und ja, wir verwenden VMs.) Viel mehr zu verwaltende Instanzen (Überwachung, Bereitstellung usw.) Wir suchen tatsächlich nach Möglichkeiten, dies einfacher zu handhaben, um hier eine physische Isolation zu erreichen, aber auf den ersten Blick Ansatz scheint Dev Einfachheit gegen Admin Einfachheit zu tauschen ...?

Antworten:

Neben der Speicherung von Daten können Probleme auftreten

Verfügbarkeit - Mit einem einzelnen Mandanten können sie nur selbst DoS ausführen. Selbst wenn die Daten ordnungsgemäß isoliert sind, kann ein Mandant dennoch Ressourcen erschöpfen.
Protokollierung - Alle Protokollnachrichten wurden von einem einzelnen Mandanten angenommen. Wenn Sie keine Protokolle pro Mandant speichern, werden Ihre Protokollnachrichten möglicherweise weniger nützlich.
Parallelität - Apps mit einem Mandanten werden möglicherweise unter mäßiger Last ausgeführt, oder ein hoher Konflikt um einige Sperren kann bestimmte Vorgänge effektiv serialisieren. Wenn Sperren pro Mandant multipliziert werden, wird möglicherweise eine Verschachtelung von Vorgängen angezeigt, die zuvor noch nicht stattgefunden haben. Rennbedingungen, bei denen es sehr unwahrscheinlich war, dass sie sich jemals manifestieren, können sich jetzt wahrscheinlich manifestieren.
Neue Quellen für Ressourcenkonflikte - wo früher n Sockets und m Dateihandles vorhanden waren, multiplizieren Sie jetzt diesen Mandanten.
Kompromisse zwischen Konfigurierbarkeit und Abwärtskompatibilität - Bevor Sie eine Komponente beim Rollout eines Ersatzes veralten können, muss jetzt möglicherweise ein Mandant eine Komponente und ein Mandant verlangen, dass die alte Komponente, die er ersetzt, unbegrenzt erhalten bleibt.
Vorladungsziel - Derzeit sind Sie ein Vorladungsziel für Probleme im Zusammenhang mit Ihrem Unternehmen. Bei mehreren Mietern müssen Sie möglicherweise auf Vorladungsanfragen reagieren, auch wenn Sie nicht an den rechtlichen Schritten beteiligt sind.

Einige davon setzen voraus, dass Sie alle Mandanten im selben Adressraum (Computer oder Cluster) ausführen. Wenn jeder Mandant Ihre Software auf seiner Hardware ausführt, können Sie einige der oben genannten Punkte diskutieren und Folgendes hinzufügen:

Schwierigkeiten beim Zugriff auf Computer zum Debuggen.
Supportanfragen für ältere Versionen.
Anforderungen zur Konfiguration von Drittanbietern.
Weniger Kontrolle über die Hardware, auf der es ausgeführt wird.
Weniger Kontrolle über den Patch- / Update-Zyklus des Betriebssystems, auf dem es ausgeführt wird.

— Mike Samuel
quelle

Das größte Problem bei der Mandantenfähigkeit ist meiner Meinung nach die Anpassung. Dies geschieht routinemäßig, wenn Sie eine Geschäftsanwendung an Unternehmen verkaufen. Dies kann von etwas so Einfachem wie jedem Kunden, der seine eigenen Skins wünscht, bis hin zur Möglichkeit, zusätzliche Felder, Regeln, Formulare und Berichte zu konfigurieren, variieren. Der Grad der Anpassung, den Sie unterstützen müssen, spielt eine entscheidende Rolle in der Architektur.

— Sriram
quelle

Mikes Antwort ist sehr gut, und viele der Punkte dort spielen aufgrund ihrer kurzen Länge fast eine untergeordnete Rolle. Nehmen Sie sich diese also zu Herzen.

Ein Punkt, den ich hinzufügen möchte, ist, dass Sie über gute Verwaltungstools verfügen sollten, um neue Mandanten zu erstellen (und später zu verwalten). Abhängig von der physischen Architektur, mit der Sie arbeiten, kann dies alles andere als trivial sein und wird häufig übersehen. Die Vorteile einer Software als Serviceprodukt kommen nur dann wirklich zum Tragen, wenn eine große Anzahl von Mietern vorhanden ist. Daher sollte ein angemessener Aufwand in die Verpflegung investiert werden.

Um Srirams Antwort zu erweitern; Die Anpassung pro Mandant ist so gut wie verboten. Alles, was ein Mandant ändern möchte, sollte konfigurierbar sein . Wenn Ihre Lösung beispielsweise das dynamische Hinzufügen von Datenfeldern in mindestens einigen Schlüsselbereichen nicht berücksichtigt, werden Sie wahrscheinlich mit Anpassungsanforderungen überschwemmt. Es ist einer der wenigen Fälle , in denen ein wenig zusätzliche Komplexität im Voraus tatsächlich off zahlt (sagen wir mal es geht gegen YAGNI, oder zumindest, diese Ebene der Konfiguration ist fast eine wesentliche Voraussetzung, damit Sie sind Gonna benötigen).

— Daniel B.
quelle

Warum ist die Anpassung "verboten"? Es ist sicherlich technisch erreichbar. Es gibt viele verschiedene Muster, die die Wiederverwendung des Kernsystems für mehrere Mieter ermöglichen und gleichzeitig kundenspezifische Teile für einzelne Mieter bereitstellen. Wenn ein Kunde bereit ist, Sie für die Anpassung zu bezahlen, erscheint es sinnvoll, dies in Betracht zu ziehen. Aus diesem Grund gibt es viele mandantenfähige Produkte, die pro Client angepasst werden können. Es liegt eher im Sinne von YAGNI IMO, Erweiterbarkeit zuzulassen und nicht standardmäßig alles konfigurierbar zu machen.

— RationalGeek

Nun, ich beziehe mich im Allgemeinen auf Software als Service-Implementierungen (von "Mandantenfähigkeit"). Sicher, es ist technisch erreichbar, aber es widerspricht den Grundlagen von SaaS. In finanzieller Hinsicht erzielen Sie niedrigere Kosten, indem Sie die Implementierung und wahrscheinlich die Infrastruktur für viele Mieter gemeinsam nutzen. Auf diese Weise können Sie Ihr Produkt zu einem niedrigeren Preis anbieten und so den "langen Schwanz" des Marktes erobern (eine große Anzahl von Menschen, die nur bereit sind, einen kleinen Betrag zu zahlen). Sie können vielleicht 5 Zweige eines Systems verwalten, aber nicht 15000, und genau darauf zielt SaaS ab.

— Daniel B

Auf Unternehmensebene sehe ich häufig SaaS-Anbieter, die bereit sind, erhebliche Anpassungen an ihrem Code vorzunehmen, um einen Kunden zu gewinnen. Wenn ein Kunde 6 oder 7 Zahlen für den Service bezahlt, ist dies wahrscheinlich ein vernünftiges Geschäftsmodell.

— RationalGeek

Ja, in diesen Fällen denke ich schon. Die meisten Änderungen, die ich gesehen habe, wurden als neue konfigurierbare Funktionen implementiert, die standardmäßig für vorhandene Clients deaktiviert waren. Ich denke, das Problem ist, wenn die ersten 3 oder 4 Klienten jeweils eine Sonderbehandlung erhalten, weil die Lösung noch nicht abgeschlossen ist. Die Lösung ist zu spezifisch und schafft eine Kultur von "OK, wir hacken sie einfach ein". Aber ja, ich stimme Ihrem Kommentar zu großen Kunden zu.

— Daniel B

Dies ist eine hilfreiche Unterscheidung, die Sie hinsichtlich der Anpassbarkeit treffen. Ich denke, dass das gleiche Konzept auch für die Verwaltbarkeit gelten könnte. Unsere Mandantenfähigkeit zielt wahrscheinlich auf relativ weniger größere Kunden als auf Long-Tail-Kunden ab. Wenn der Hauptzweck der Mandantenfähigkeit darin besteht, Long-Tail zu erfassen, ist dies möglicherweise nicht einmal der richtige Ansatz für uns. Vielen Dank für diese Überlegungen.