Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Streichung des Begriffs „Einzelmandant“

Im Rahmen der Verwendung des Begriffs Multi-Tenant ist es nur natürlich, dass Benutzer den Begriff Single-Tenant verwenden möchten, um SaaS-Umgebungen zu beschreiben. Vor dem zuvor skizzierten Hintergrund sorgt der Begriff Single-Tenant jedoch für Verwirrung.

Handelt es sich bei dem obigen Diagramm um eine Single-Tenant-Umgebung? Technisch gesehen hat zwar jeder Mandant seinen eigenen Stack, aber diese Mandanten werden immer noch in einem Multi-Tenant-Modell betrieben und verwaltet. Aus diesem Grund wird der Begriff Single-Tenant generell vermieden. Stattdessen werden alle Umgebungen als Multi-Tenant-Umgebungen bezeichnet, da sie lediglich eine Variante der Tenancy implementieren, bei der einige oder alle Ressourcen gemeinsam genutzt oder dediziert werden.

Wir stellen vor: Silo und Pool

Angesichts all dieser Modellvarianten und angesichts der Herausforderungen rund um den Begriff Multi-Tenancy haben wir einige Begriffe eingeführt, mit denen wir die verschiedenen Modelle, die beim Aufbau eines SaaS verwendet werden, genauer erfassen und beschreiben können.

Zwei Begriffe, die wir verwenden, um die Nutzung von Ressourcen in einer SaaS-Umgebung zu charakterisieren, sind Silo und Pool. Diese Begriffe ermöglichen es uns, die Natur von SaaS-Umgebungen zu kennzeichnen, indem wir Multi-Tenant als übergreifende Beschreibung verwenden, die auf eine beliebige Anzahl von zugrunde liegenden Modellen angewendet werden kann.

Auf der einfachsten Ebene soll der Begriff Silo Szenarien beschreiben, in denen eine Ressource einem bestimmten Mandanten zugewiesen wird. Umgekehrt wird das Poolmodell verwendet, um Szenarien zu beschreiben, in denen eine Ressource von Mietern gemeinsam genutzt wird.

Wenn wir uns ansehen, wie die Begriffe Silo und Pool verwendet werden, ist es wichtig, sich darüber im Klaren zu sein, dass Silo und Pool keine all-or-nothing Konzepte sind. Silo und Pool könnten für den Ressourcenstapel eines gesamten Mandanten gelten, oder sie könnten selektiv auf Teile Ihrer gesamten SaaS-Umgebung angewendet werden. Wenn wir also sagen, dass eine Ressource ein Silomodell verwendet, bedeutet das nicht, dass alle Ressourcen in dieser Umgebung isoliert sind. Das Gleiche gilt für die Verwendung des Begriffs gepoolt.

Das folgende Diagramm zeigt ein Beispiel dafür, wie isolierte und gepoolte Modelle in einer SaaS-Umgebung detaillierter verwendet werden:

Dieses Diagramm enthält eine Reihe von Beispielen, die den gezielteren Charakter der Silo- und Poolmodelle veranschaulichen sollen. Wenn Sie dies von links nach rechts verfolgen, werden Sie feststellen, dass wir mit einem Bestell-Microservice beginnen. Dieser Microservice verfügt über isolierte Rechenleistung und gepoolten Speicher. Es interagiert mit einem Produktservice, der über gepoolte Rechenleistung und gepoolten Speicher verfügt.

Der Produktservice interagiert dann mit einem Rechnungs-Microservice, der über gepoolte Rechenleistung und isolierten Speicher verfügt. Dieser Dienst sendet Nachrichten über Warteschlangen an den Versandservice. Die Warteschlangen werden in einem Silomodell bereitgestellt.

Schließlich erfasst der Versand-Microservice Nachrichten aus den isolierten Warteschlangen. Es verwendet gepoolte Rechen- und Speicherressourcen.

Dies mag zwar etwas kompliziert erscheinen, aber das Ziel besteht darin, den granularen Charakter der Silo- und Poolkonzepte hervorzuheben. Beim Entwerfen und Erstellen Ihrer SaaS-Lösung wird erwartet, dass Sie diese Silo- und Poolentscheidungen auf der Grundlage der Bedürfnisse Ihrer Domain und Ihrer Kunden treffen.

Lauter Nachbar, Isolation, Tiering und eine Vielzahl anderer Gründe können beeinflussen, wie und wann Sie das Silo- oder Poolmodell anwenden.