Teilen sich mehrere Mandanten bzw. Tenants eine einzelne Instanz einer Anwendung (mit der zugehörigen Hardware und Datenbank) spricht man von Multi-Tenant bzw. Multi-Tenancy (Mehrmandantenfähigkeit).
Die Daten der einzelnen Tenants sind dabei voneinander isoliert und für die anderen Tenants nicht sichtbar. Nur die zugehörigen Nutzer haben Zugriff. Jeder Nutzer hat üblicherweise seine eigenen Zugriffsrechte, Daten und Konfigurationsdetails und kann so zum Beispiel das Aussehen der Benutzeroberfläche anpassen.
Damit stellt Multi-Tenancy die nächste Evolutions-Stufe für Cloud-Diensten dar. Früher wurde jeweils eine eigene Applikation, auf einer jeweils eigenen Hardware, betrieben. Aufwendungen für Installation, Betrieb und Wartung haben dabei nahezu linear mit den Instanzen skaliert. Daraus resultierende Probleme waren jedoch:
- Die bspw. Aufwände für Updates waren genau die Grundkosten multipliziert mit der Anzahl der Instanzen. Umso mehr Instanzen man in Betrieb hatte, um so teuerer wurde dies alles. Bei Multi-Tenancy ist dies üblicherweise nur durch die Anzahl der “Cluster” bestimmt; was häufig nur ein Bruchteil der Instanz-Anzahl ist.
- Vereinfacht gesagt hat jede Instanz bei den klassischen Ansätzen seinen eigenen physikalischen Server. Ist dieser aber nur 1h pro Tag zu 90% ausgelastet und die restliche Zeit des Tages jeweils maximal zu 5%, ist die Hardware damit sehr ineffektiv eingesetzt. Ist die Hardware dagegen überlastet, ist es auch meist schwer horizontal zu Skalieren, weil dies bedeutet neue Hardware zeitnah dazu zu stellen. Puffer-Kapazitäten vorzuhalten ist dagegen auch sehr teuer, da diese mit der Anzahl der Instanzen skalieren müssen. Bei Multi-Tenancy wird üblicherweise 10% der Gesamtkapazität als Puffer vorgehalten. Dazu kann auch noch ein Mittel der Auslastung als Grundkapazität erstellt werden. Unterm Strich skalieren diese Installationen damit deutlich effektiver und kommen dem Kunden dadurch durch deutlich günstigere Kosten (teilweise bis zu 5% im Vergleich zu den dedizierte Hardware-Varianten) und kann auch zumeist viel zuverlässiger mit schwankenden Last-Szenarien umgehen.
Es gibt drei Varianten von Multi-Tenancy Architekturen mit unterschiedlicher Komplexität.
Variante 1: Alle Tenants haben ein gemeinsames Datenbankschema
Hat relativ geringe Kosten aufgrund der Nutzung gemeinsamer Ressourcen und ist die einfachste Form der drei Varianten. Hierbei wird eine einzige Anwendungs- und Datenbankinstanz verwendet, um mehrere gleichzeitige Mandanten zu hosten und Daten zu speichern, was eine einfache Skalierung erlaubt.
Variante 2: Eine Anwendung, mehrere Datenbanken
Diese Variante verwendet eine einzige Anwendungsinstanz mit individuellen Datenbanken für jeden Mandanten weshalb diese Architektur schwieriger zu skalieren ist. Wird oft verwendet, wenn das Datenbankschema zwar einheitlich ist, die Anforderungen an die Daten aber individuell definiert werden müssen. Zum Beispiel internationale Daten die je nach geografischer Region unterschiedliche Anforderungen haben.
Variante 3: Separate Datenbanken
In Bezug auf Verwaltung und Wartung die komplexiste Variante. Jeder Nutzer erhält eine eigene Datenbank was maximale Flexibilität und Isolation der Daten zwischen den einzelenen Nutzern bedeutet.