Leider gibt es für diesen Begriff keinen guten deutschsprachigen Pendant. „Wikipedia“ definiert ihn als „Multimietereigenschaft, Mehrfachmiete“. Manchmal wird dies als „gemeinsame Nutzung“ bezeichnet. Diese Begriffe können etwas verwirrend sein, da das Thema im Wesentlichen nicht mit Miete oder Eigentum zu tun hat. Es geht vielmehr um die Softwarearchitektur und die Organisation ihrer Nutzung, wobei Letzteres nicht weniger wichtig ist.
Wir haben begonnen, unser Verständnis von Multitenancy zu entwickeln, während wir anfingen, einen Ansatz für das Cloud-Service-Modell von „1C:Enterprise“ zu entwerfen. Das ist einige Jahre her, und seitdem erweitern wir kontinuierlich unser Wissen. Wir entdecken ständig neue Aspekte zu diesem Thema (Vorteile, Nachteile, Herausforderungen, Besonderheiten usw.).
Manchmal verstehen Entwickler unter Multitenancy ein recht einfaches Konzept: „Um die Daten mehrerer Organisationen in einer einzigen Datenbank zu speichern, muss man in allen Tabellen eine Spalte mit der Organisations-ID hinzufügen und einen Filter darauf setzen.“ Natürlich haben auch wir unsere Erkundungen zu diesem Thema von diesem Punkt aus begonnen. Aber recht schnell haben wir erkannt, dass dies nur ein kleiner Teilaspekt ist (auch wenn er nicht einfach ist). Tatsächlich ist es „ein ganzes Land“.
Die Hauptidee von Multitenancy lässt sich etwa so beschreiben. Eine gewöhnliche Anwendung ist wie ein Einfamilienhaus, das für eine Familie gebaut ist, die dessen Infrastruktur (Wände, Dach, Wasser- und Heizungsversorgung usw.) nutzt. Eine Multitenancy-Anwendung hingegen ist wie ein Mehrfamilienhaus. Darin nutzt jede Familie die gleiche Infrastruktur, doch die Infrastruktur ist für das gesamte Gebäude konzipiert.
Ist der Ansatz der Multitenancy gut oder schlecht? Dafür gibt es sehr unterschiedliche Meinungen. Es scheint, dass es kein „gut oder schlecht“ im Allgemeinen gibt. Man muss die Vor- und Nachteile im Kontext der spezifischen zu bewältigenden Aufgaben vergleichen. Aber das ist ein eigenes Thema ...
Im einfachsten Sinne zielt Multitenancy darauf ab, die Kosten für die Wartung von Anwendungen zu senken, indem die Infrastrukturkosten ‚gemeinsam genutzt‘ werden. Dies ist ein ähnlicher Ansatz wie die Senkung der Kosten für eine Anwendung durch den Einsatz einer Standardlösung (möglicherweise mit Anpassungen und Erweiterungen), anstatt sie ‚maßgeschneidert‘ zu entwickeln. In einem Fall wird die Entwicklung geteilt, im anderen die Betriebsführung.
Es sei erneut betont, dass es hier keine direkte Verbindung zur Verkaufsweise gibt. Die Architektur der Multitenancy kann durchaus auch in einer Unternehmens- oder behördlichen IT-Infrastruktur eingesetzt werden, um eine Vielzahl von gleichartigen Niederlassungen oder Unternehmen innerhalb eines Konzerns zu automatisieren.
Man kann sagen, dass Multitenancy nicht nur eine Frage der Datenspeicherorganisation ist. Es handelt sich um ein Modell für die gesamte Funktionsweise der Anwendung (einschließlich wesentlicher Aspekte ihrer Architektur, des Bereitstellungsmodells und der Wartungsorganisation).
Das Interessanteste an dem Multitenancy-Modell ist, dass die Funktionalität der Anwendung "zweigeteilt" wird. Ein Teil funktioniert mit spezifischen Datenbereichen (Wohnungen) und ignoriert die Bewohner anderer Wohnungen. Der andere Teil betrachtet das gesamte Gebäude und arbeitet gleichzeitig für alle Bewohner. Dabei kann der letzte Teil nicht abstrahieren, dass es sich letztlich um separate Wohnungen handelt und dass ein gewisses Maß an Granularität und Sicherheit gewährleistet werden muss.
In „1C:Enterprise“ wird das Multitenancy-Modell durch verschiedene Technologien realisiert. Dazu gehören Mechanismen der „1C:Enterprise“-Plattform, Mechanismen „» und «“, Mechanismen (Bibliotheken standardmäßiger Subsysteme).
Jedes dieser Elemente trägt zur Schaffung der gesamten Infrastruktur eines Mehrfamilienhauses bei. Warum wird dies in mehreren Technologien und nicht in einer einzigen, wie beispielsweise einer Plattform, umgesetzt? Vor allem, weil wir der Meinung sind, dass ein Teil der Mechanismen durchaus bei bestimmten Bereitstellungsvarianten sinnvoll modifiziert werden kann. Aber allgemein ist das eine komplexe Fragestellung, und wir stehen ständig vor der Wahl, auf welcher Ebene wir einen bestimmten Aspekt der Multitenanz umsetzen können.
Es ist offensichtlich, dass die grundlegenden Mechanismen in der Plattform implementiert werden mussten. Zum Beispiel die tatsächliche Trennung der Daten. Damit beginnt in der Regel das Gespräch über Multitenanz. In der Tat hat das Modell der Multitenanz jedoch einen erheblichen Teil der Mechanismen der Plattform durchlaufen und erforderte deren Überarbeitung, in einigen Fällen sogar eine Neubewertung.
Auf der Plattform-Ebene haben wir grundlegende Mechanismen implementiert, die das Erstellen von Anwendungen im Multitenancy-Modell ermöglichen. Damit diese Anwendungen jedoch erfolgreich in diesem Modell "leben und arbeiten" können, benötigt man ein System zur Verwaltung ihres "Lebenszyklus". Dafür sind die Technologien 1cFresh und eine einheitliche Schicht der Geschäftslogik auf Ebene der BSP verantwortlich. So wie in einem Mehrfamilienhaus die Infrastruktur den Bewohnern alles Notwendige bereitstellt, sorgen die Technologien 1cFresh dafür, dass die Anwendungen, die im Multitenancy-Modell betrieben werden, gut versorgt sind. Damit diese Anwendungen ohne umfangreiche Anpassungen mit dieser Infrastruktur interagieren können, werden die entsprechenden "Schnittstellen" in Form von BSP-Subsystemen integriert.
Aus Sicht der Plattformmechanismen ist leicht erkennbar, dass wir mit zunehmender Erfahrung und der Entwicklung des Cloud-Use-Cases von '1C:Enterprise' die Anzahl der Mechanismen erweitern, die in diese Architektur eingebunden sind. Ein Beispiel sei genannt. In einem Multitenancy-Modell ändern sich die Rollen der Beteiligten an der Anwendungsbetreuung erheblich. Die Verantwortung derjenigen, die für den Betrieb der Anwendungen zuständig sind, nimmt erheblich zu. Sie benötigen leistungsfähigere Werkzeuge zur Kontrolle der Anwendungen. Denn die Anwendungsbenutzer (Mieter) vertrauen primär dem Anbieter, mit dem sie zusammenarbeiten. Dafür haben wir in Version 8.3 einen neuen . Dieser Mechanismus ermöglicht es den Administratoren des Anbieters, den Freiraum der Anwendungsentwickler auf das erforderliche Sicherheitsniveau einzuschränken – im Wesentlichen die Arbeit der Anwendung für jeden Mieter innerhalb bestimmter 'Sandbox'-Rahmen zu isolieren.
Die Architektur zur Verwaltung von Anwendungen im Multitenancy-Modus (wie sie in den Technologien 1cFresh und BSP umgesetzt wird) ist von erheblichem Interesse. Im Vergleich zu herkömmlichen Bereitstellungsmodellen steigen hier die Anforderungen an die Automatisierung der Verwaltungsprozesse erheblich. Solcher Prozesse gibt es Dutzende: die Erstellung neuer Datenbereiche ("Wohnungen"), die Aktualisierung von Anwendungen, die Aktualisierung von Norminformationen, Datensicherung usw. Und selbstverständlich erhöhen sich auch die Anforderungen an die Zuverlässigkeit und Verfügbarkeit. Um eine zuverlässige Interaktion der Anwendungen mit den Komponenten des Verwaltungssystems zu gewährleisten, haben wir eine asynchrone Aufrufsystemtechnologie mit garantierter Zustellung implementiert.
Ein sehr feiner Aspekt ist die Art und Weise, wie Daten und Prozesse gemeinschaftlich genutzt werden. Auf den ersten Blick mag dies einfach erscheinen (sofern es jemand so empfindet). Die größte Herausforderung besteht darin, ein Gleichgewicht zwischen der Zentralisierung von Daten und Prozessen und der Dezentralisierung zu finden. Einerseits ermöglicht die Zentralisierung eine Reduzierung der Kosten (Speicherplatz, CPU-Ressourcen, Administrationsaufwand…). Andererseits schränkt sie die Freiheit der "Mieter" ein. Dies ist genau einer der Punkte des "Aufsplitterns" der Anwendung, bei dem der Entwickler gleichzeitig an die Anwendung im engen Sinne (die eine "Wohnung" bedient) und im weiteren Sinne (die gleichzeitig alle "Mieter" bedient) denken muss.
Ein Beispiel für ein solches "Dilemma" ist die Bereitstellung von normativen Informationen. Es ist verlockend, diese für alle "Bewohner" des Hauses allgemeingültig zu gestalten. So kann man sie in einem einzigen Exemplar speichern und gleichzeitig für alle aktualisieren. Doch manchmal benötigt ein Bewohner spezifische Anpassungen. Merkwürdigerweise kommt das in der Praxis vor, selbst bei Informationen, die von Regulierungsbehörden (öffentlichen Institutionen) festgelegt sind. Das Ergebnis ist eine komplizierte Frage: Soll man diese Informationen gemeinschaftlich nutzen oder nicht? Es ist natürlich verlockend, allgemeine Informationen für alle und spezielle für Interessierte zu erstellen. Doch das führt bereits zu einer bedeutend schwierigeren Umsetzung. Aber daran arbeiten wir…
Ein weiteres Beispiel ist die Planung der Umsetzung regelmäßiger Prozesse (z. B. nach Zeitplan ausgeführt, durch das Managementsystem initiiert usw.). Einerseits können sie für jeden Datenbereich separat implementiert werden. Das ist einfacher und bequemer. Andererseits verursacht eine so feine Granularität eine hohe Systembelastung. Um die Last zu reduzieren, sollten allgemein nutzbare Prozesse implementiert werden. Diese erfordern jedoch eine sorgfältigere Ausarbeitung.
Natürlich stellt sich eine sehr wesentliche Frage. Wie können Anwendungsentwickler den Betrieb im Multitenancy-Modus gewährleisten? Was müssen sie dafür tun? Natürlich streben wir an, dass die technologischen und infrastrukturellen Herausforderungen größtenteils von der bereitgestellten Technologie übernommen werden, sodass der Anwendungsentwickler sich ausschließlich auf die Geschäftslogik konzentrieren kann. Doch wie bei anderen wichtigen architektonischen Fragen ist es nötig, dass Anwendungsentwickler einige Kenntnisse über das Arbeiten im Multitenancy-Modell haben und gewisse Anstrengungen in der Anwendungsentwicklung erforderlich sind. Warum? Weil es Aspekte gibt, die die Technologie nicht automatisch garantieren kann, ohne die Semantik der Daten zu berücksichtigen. Zum Beispiel die Definition der Grenzen der Datenkommunikation. Aber wir bemühen uns, dass diese Herausforderungen überschaubar bleiben. Beispiele für die Umsetzung solcher Anwendungen existieren bereits.
Ein wichtiger Aspekt bei der Umsetzung von Multitenancy in «1C:Enterprise» ist, dass wir ein hybrides Modell schaffen, in dem eine Anwendung sowohl im Multitenancy-Modus als auch im regulären Modus arbeiten kann. Dies ist eine recht komplexe Herausforderung und bedarf einer gesonderten Diskussion.
Quelle: habr.com
