Mietmodelle für eine Multi-Tenant-App

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.

Verschiedene Mietmodelle aus technischer Sicht verstehen#

Single-Tenant-Architektur#

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.

Merkmale#

• Isolation: Jeder Kunde oder Mieter agiert in einer isolierten Umgebung mit dedizierten Ressourcen, Datenbanken und Konfigurationen.
• Anpassung: Single-Tenant-Architekturen ermöglichen oft eine größere Anpassung und Flexibilität, um spezifische Kundenanforderungen zu erfüllen.
• Sicherheit: Erhöhte Sicherheit und Datenschutz, da Kundendaten nicht mit denen anderer Mieter vermischt sind.
• Skalierbarkeit: Die Skalierung von Ressourcen und Kapazität kann einfacher sein, da die Instanz jedes Mieters unabhängig angepasst werden kann.
• Wartung: Unabhängige Wartung und Updates, da Änderungen an der Umgebung eines Mieters die anderen nicht betreffen.
• Kosten: In der Regel höhere Infrastruktur- und Betriebskosten aufgrund der Notwendigkeit, separate Instanzen für jeden Mieter zu pflegen.

Beispiele#

• Dediziertes Hosting: Traditionelle Webhosting-Anbieter bieten Single-Tenant-Architekturen an, bei denen jeder Kunde seine eigenen Ressourcen, Datenbanken oder Konfigurationen erhält.
• On-Premises-Software: Einige Unternehmenssoftwareanwendungen wie Customer Relationship Management (CRM) oder Human Resource Management Systems (HRMS) bieten Single-Tenant-Bereitstellungsoptionen für Organisationen mit strengen Datensicherheits- und Anpassungsanforderungen.
• SaaS mit Premiumstufen: In einigen Software as a Service (SaaS)-Angeboten bieten Premium- oder Enterprise-Stufen Single-Tenant-Optionen für Kunden, die eine erhöhte Sicherheit, Compliance oder Anpassung erfordern.

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.

Multi-Tenant-Architektur#

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

Merkmale#

• Geteilte Ressourcen: Mehrere Mieter teilen sich dieselbe Infrastruktur, einschließlich Server, Datenbanken und Netzwerkressourcen, um die Ressourcennutzung zu optimieren.
• Isolation: Daten und Konfigurationen der Mieter sind logisch getrennt, um Datenschutz und Sicherheit zu gewährleisten.
• Skaleneffekte: Multi-Tenancy kann kosteneffektiv sein, da der Overhead auf mehrere Benutzer verteilt wird, wodurch Betriebs- und Infrastrukturkosten gesenkt werden.
• Skalierbarkeit: Die Architektur kann horizontal oder vertikal skaliert werden, um wachsende Anzahl von Mietern und Benutzern zu unterstützen.
• Wartung: Aktualisierungen und Wartung sind vereinfacht, da Änderungen einheitlich für alle Mieter angewendet werden, was die Verwaltung erleichtert.
• Anpassung: Während einige Anpassungen möglich sind, sind sie im Vergleich zu Single-Tenant-Architekturen typischerweise eingeschränkter, um die Konsistenz im Gesamtsystem aufrechtzuerhalten.

Beispiele#

• Cloud-basierte SaaS: Die meisten Software as a Service (SaaS)-Anwendungen, wie Google Workspace und Salesforce, verwenden Multi-Tenancy, um mehreren Organisationen oder Benutzern auf einer gemeinsamen Plattform zu dienen.
• Shared Hosting: Beim Webhosting hosten Shared-Hosting-Dienste mehrere Websites auf demselben Server, die jeweils einem anderen Kunden oder einer anderen Organisation gehören.
• Öffentliche Cloud-Dienste: Öffentliche Cloud-Anbieter wie AWS und Azure verwenden Multi-Tenancy, um verschiedenen Kunden mit isolierten virtualisierten Ressourcen innerhalb gemeinsamer Rechenzentren zu dienen.
• Unternehmensweite Infrastrukturlösungen: Wie zum Beispiel ein gemeinsam genutzter Kubernetes-Cluster, der von mehreren Geschäftseinheiten innerhalb einer Organisation verwendet wird.

Multi-Tenant-Apps in der realen Welt neu definieren#

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.

Wichtige Überlegungen zur Bestimmung deiner Mietmodellstrategie#

Hier kommt die Frage: Wie schlage ich die Mietstrategie für mein Produkt vor? Hier sind einige wichtige Fragen zu berücksichtigen:

• Was sind deine Geschäftsziele?
• Kann eine Single-Tenant-Lösung dein zukünftiges Wachstum unterstützen?
• Wie groß ist dein Betriebsteam und wie viel deiner Infrastrukturanleitung kann automatisiert werden? Legst du Wert auf Agilität und Kosteneffizienz?
• Sind deine Kunden mit verschiedenen Multi-Tenancy-Optionen zufrieden?
• Wie wirkt sich jede Option auf die Compliance aus, sowohl deine als auch die deiner Kunden?
• Wirst du erwartet, Dienstgütevereinbarungen (SLAs) einzuhalten oder bestimmte Service-Level-Objektive (SLOs) anzustreben?
• Hast du Sicherheit, Kosten, Leistung, Zuverlässigkeit und Reaktionsfähigkeit auf individuelle Mieterbedürfnisse insgesamt berücksichtigt?

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.

Nächstes#

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!