Ein tieferer Einblick in den Begriff "Multi-Tenancy" und das Teilen unserer Erkenntnisse darüber, wie wir ihn wahrnehmen.
Wir hören häufig über die Bedeutung der Erstellung einer Multi-Tenant-Anwendung, insbesondere im Kontext der Entwicklung einer Software as a Service (SaaS)-Anwendung.
Es gibt einige Verwirrung über das Konzept einer "Multi-Tenant-App" und die verschiedenen Modelle, die zu ihrer Entwicklung verwendet werden. In diesem Artikel haben wir uns diese Begriffe in praktischerer Weise genauer angesehen.
Die Single-Tenant-Architektur ist ein Software- oder Cloud-Computing-Modell, bei dem jeder Kunde oder Mieter eine dedizierte Instanz einer Anwendung oder eines Dienstes hat. Wenn wir uns den Ursprung des B2B-Geschäftsmodells ansehen, beginnt es damit, dass jede Softwareinstanz nur einem Kunden oder einer Organisation dient.
Die Single-Tenant-Architektur wird häufig in Szenarien verwendet, in denen Compliance von größter Bedeutung ist oder maßgeschneiderte Sicherheitsanforderungen bestehen. Zum Beispiel bevorzugen Branchen wie Finanzen, Gesundheitswesen und Regierung, die strenge regulatorische Anforderungen haben, häufig Single-Tenant-Lösungen, um Compliance sicherzustellen.
Es ist jedoch wichtig zu beachten, dass Single-Tenant-Architekturen im Vergleich zu Multi-Tenant-Architekturen ressourcenintensiver und komplexer zu verwalten sein können, da jede Kundeninstanz ihre eigene Infrastruktur und Wartung erfordert. Aus diesem Grund sind sie möglicherweise besser geeignet für Anwendungen mit weniger, aber größeren Kunden oder bei denen Anpassung und Isolation entscheidend sind.
Software-Multi-Tenancy ist eine Softwarearchitektur, bei der eine einzige Instanz von Software auf einem Server läuft und mehreren Mietern dient. Systeme, die auf diese Weise entworfen sind, werden "geteilt" (anstatt "dediziert" oder "isoliert"). Ein Mieter ist eine Gruppe von Benutzern, die gemeinsamen Zugriff mit bestimmten Privilegien zur Softwareinstanz haben. Mit einer Multi-Tenant-Architektur ist eine Softwareanwendung so konzipiert, dass sie jedem Mieter einen dedizierten Anteil der Instanz bietet - einschließlich seiner Daten, Konfiguration, Benutzerverwaltung, mieterindividueller Funktionalität und nicht-funktioneller Eigenschaften. -- Wikipedia
Wir haben Definitionen aus architektonischer Sicht bereitgestellt, die es einfach machen, zwischen Multi-Tenant- und Single-Tenant-Designs zu unterscheiden. Dies lehnt sich jedoch stärker an die technische Definition an. Wenn wir diese Definitionen in unserer realen Entwicklungsumgebung verwenden, wenn wir Mietmodelle entwerfen, geht diese Denkweise davon aus, dass eine Multi-Tenant-App eine rein geteilte, Multi-Tenant-Infrastruktur haben muss.
Allerdings variieren Geschäft und Produkt stark und haben viele fallbasierte Anforderungen, sodass es keine "Einheitsgröße passt für alle"-Lösung gibt.
Stellen wir uns ein Szenario vor, in dem ein Mieter Ressourcen aus einer geteilten Infrastruktur nutzt, aber aufgrund spezifischer Geschäftsanforderungen ein oder zwei Teile des Systems exklusiv für sie dediziert werden müssen. Diese dedizierten Teile könnten die Datenbank, Instanzen oder eine Kombination anderer Komponenten sein, während die allgemeine Infrastruktur geteilt wird. Hier kommt die gemischte Mietarchitektur ins Spiel.
In der praktischen SaaS-Produktentwicklung ist es üblich, auf ein Szenario zu stoßen, bei dem ein Produkt hauptsächlich mit einem generischen Multi-Tenancy-Modell entworfen wird. Bestimmte Aspekte der Architektur oder Ressourcen können jedoch mehr in Richtung eines "Single-Tenancy"-Ansatzes gehen.
AWS nutzte folgendes Beispiel, um dieses Konzept zu verdeutlichen: Multi-Tenancy ist ein breites Konzept, und es ist fallweise, die richtige Strategie zu kombinieren und auszuwählen, um das zu definieren, was man erreichen möchte, zwischen geteilten Ressourcen und Datenisolation.
Mit anderen Worten, manchmal nennen Leute dieses Modell immer noch "Multi-Tenancy", sodass in der breiteren Definition von Multi-Tenancy nicht impliziert wird, dass jedes Komponente in einer Lösung geteilt ist. Vielmehr impliziert es, dass zumindest einige Komponenten einer Lösung über mehrere Mieter hinweg wiederverwendet werden.
Ein breites Verständnis dieses Begriffs kann dir besser helfen, die Bedürfnisse deiner Kunden und deren Herkunft nachzuvollziehen.
Anstatt sich auf ein einziges Architekturmodell zu fixieren, reflektiert Multi-Tenancy die Praktikabilität der Architektur eines SaaS-Produkts in der realen Welt. Wenn wir von einer Multi-Tenant-App sprechen, bedeutet dies nicht unbedingt, dass die App einem einzigen Architekturmodell folgt; sie kann verschiedene Mietstrategien nutzen, was darauf hindeutet, dass zumindest einige ihrer Komponenten geteilt sind.
Hier kommt die Frage: Wie schlage ich die Mietstrategie für mein Produkt vor? Hier sind einige wichtige Fragen zu berücksichtigen:
Denke daran, dass es keine starre Trennung in deinem Produkt gibt, bei der du entweder ein rein multi-mieterfähiges oder ein rein single-mieterfähiges Modell wählen musst. Deine Entscheidung sollte darauf basieren, wie du die Architekturkomponenten deines Produkts aufteilst und welche speziellen Isolationsstufen deine Kunden oder dein Geschäft benötigen. Du kannst dann entsprechend verschiedene Ansätze anwenden.
Wir sprachen über die "neue" Definition einer Multi-Tenant-App, aber wie sieht es mit Mieterisolation, Identitäten und der Bestimmung, ob deine Identitäten isoliert sein sollten, aus? Was bedeutet es, dass Identitäten "isoliert" sind?
Die Verwirrung entsteht oft, wenn man mit Situationen konfrontiert ist, in denen ein realer Benutzer zwei verschiedene Identitäten hat. Ist es angemessen, diese Situation als - "Identitäten isoliert" zu bezeichnen?
Wir werden diese Fragen in unserer kommenden Artikelserie behandeln. Bleib dran!