© best_vector/Shutterstock.com
Windows Developer
Multi-Tenancy-Evolution: Cloud Service Vendors können Multi-Tenancy in Azure neu denken

Kolumne: Stropek as a Service


Es gibt einen Faktor in der Softwarearchitektur, der klassische ISVs (Independent Software Vendors) von CSVs (Cloud Service Vendors) unterscheidet: Multi-Tenancy. Schreibt ein ISV Software, die zum Verkauf an und Betrieb beim Endkunden gedacht ist, ergibt sich die Trennung der Kunden ganz von alleine. Schließlich hat jeder sein eigenes Rechenzentrum und schottet sich durch Firewalls vom Rest des Internets und damit von anderen Firmen ab. Ganz anders in der Cloud. CSVs streben danach, viele Kunden durch eine gemeinsame IT-Infrastruktur zu bedienen. Man verwendet in diesem Zusammenhang den Begriff „Tenant“ (engl. „Mieter“), da das Bild eines Mietshauses mit vielen Parteien, deren Wohnungen strikt voneinander getrennt sind, eine gute Analogie ist.

Multi-Tenancy als wichtiger Wettbewerbsvorteil

Warum tun sich CSVs die Komplexität von Multi-Tenancy an? Man könnte doch einfach jedem Kunden eine eigene virtuelle Infrastruktur einrichten und dadurch die Tenant-Trennung sicherstellen. Die Betriebskosten sind die Antwort. Es stimmt zwar, dass in der Cloud die Kosten variabel sind. Sieht man sich die Preismodelle der Cloud-Anbieter aber genau an, merkt man, dass man nicht zahlt, was man tatsächlich nutzt, sondern was man reserviert. Insofern hat die Cloud mehr Ähnlichkeit mit einer Reservierung im Hotel als mit dem Bezahlen für Strom: Das Hotelzimmer kostet Geld, egal ob man schlussendlich darin schläft oder nicht.

Abbildung 1 skizziert das Prinzip. Die oberen drei Linien symbolisieren die Auslastung von drei Servern, auf denen Tenants getrennt voneinander arbeiten. In diesem Fall könnte man ohne Weiteres alle Tenants auf einem System betreiben (unteres Diagramm), dadurch die verfügbaren Ressourcen besser nutzen und die Cloud-Betriebskosten dritteln.

stropek_azure_kolumne_wd_216_1.tif_fmt1.jpgAbb. 1: Kombinierte Systemauslastung

Herausforderungen

Die erfahrenen Leser erkennen sofort die Haken an der Sache. Hier einige Beispiele:

  • Wie trennt man die Tenants, wenn sie auf einem System arbeiten? Man muss jeden Tenant in einer Art Sandbox einsperren, aus der er nicht ausbrechen und auf fremde Tenants zugreifen kann.

  • Wie stellt man sicher, dass ein Tenant, der das System überdurchschnittlich stark belastet – egal ob erlaubt oder unerlaubt – nicht alle anderen Tenants am gleichen System ausbremst?

  • Wie protokolliert und überwacht man, welcher Anteil der Systemlast auf welchen Tenant fällt?

  • Im Fall, dass mehrere Tenants sich einen Datenspeicher teilen (z. B. eine DB für mehrere Tenants): Wie sichert man die Daten...

Windows Developer
Multi-Tenancy-Evolution: Cloud Service Vendors können Multi-Tenancy in Azure neu denken

Kolumne: Stropek as a Service

Es gibt einen Faktor in der Softwarearchitektur, der klassische ISVs (Independent Software Vendors) von CSVs (Cloud Service Vendors) unterscheidet: Multi-Tenancy. Schreibt ein ISV Software, die zum Verkauf an und Betrieb beim Endkunden gedacht ist, ergibt sich die Trennung der Kunden ganz von alleine. Schließlich hat jeder sein eigenes Rechenzentrum und schottet sich durch Firewalls vom Rest des Internets und damit von anderen Firmen ab. Ganz anders in der Cloud. CSVs streben danach, viele Kunden durch eine gemeinsame IT-Infrastruktur zu bedienen. Man verwendet in diesem Zusammenhang den Begriff „Tenant“ (engl. „Mieter“), da das Bild eines Mietshauses mit vielen Parteien, deren Wohnungen strikt voneinander getrennt sind, eine gute Analogie ist.

Rainer Stropek


Es gibt einen Faktor in der Softwarearchitektur, der klassische ISVs (Independent Software Vendors) von CSVs (Cloud Service Vendors) unterscheidet: Multi-Tenancy. Schreibt ein ISV Software, die zum Verkauf an und Betrieb beim Endkunden gedacht ist, ergibt sich die Trennung der Kunden ganz von alleine. Schließlich hat jeder sein eigenes Rechenzentrum und schottet sich durch Firewalls vom Rest des Internets und damit von anderen Firmen ab. Ganz anders in der Cloud. CSVs streben danach, viele Kunden durch eine gemeinsame IT-Infrastruktur zu bedienen. Man verwendet in diesem Zusammenhang den Begriff „Tenant“ (engl. „Mieter“), da das Bild eines Mietshauses mit vielen Parteien, deren Wohnungen strikt voneinander getrennt sind, eine gute Analogie ist.

Multi-Tenancy als wichtiger Wettbewerbsvorteil

Warum tun sich CSVs die Komplexität von Multi-Tenancy an? Man könnte doch einfach jedem Kunden eine eigene virtuelle Infrastruktur einrichten und dadurch die Tenant-Trennung sicherstellen. Die Betriebskosten sind die Antwort. Es stimmt zwar, dass in der Cloud die Kosten variabel sind. Sieht man sich die Preismodelle der Cloud-Anbieter aber genau an, merkt man, dass man nicht zahlt, was man tatsächlich nutzt, sondern was man reserviert. Insofern hat die Cloud mehr Ähnlichkeit mit einer Reservierung im Hotel als mit dem Bezahlen für Strom: Das Hotelzimmer kostet Geld, egal ob man schlussendlich darin schläft oder nicht.

Abbildung 1 skizziert das Prinzip. Die oberen drei Linien symbolisieren die Auslastung von drei Servern, auf denen Tenants getrennt voneinander arbeiten. In diesem Fall könnte man ohne Weiteres alle Tenants auf einem System betreiben (unteres Diagramm), dadurch die verfügbaren Ressourcen besser nutzen und die Cloud-Betriebskosten dritteln.

stropek_azure_kolumne_wd_216_1.tif_fmt1.jpgAbb. 1: Kombinierte Systemauslastung

Herausforderungen

Die erfahrenen Leser erkennen sofort die Haken an der Sache. Hier einige Beispiele:

  • Wie trennt man die Tenants, wenn sie auf einem System arbeiten? Man muss jeden Tenant in einer Art Sandbox einsperren, aus der er nicht ausbrechen und auf fremde Tenants zugreifen kann.

  • Wie stellt man sicher, dass ein Tenant, der das System überdurchschnittlich stark belastet – egal ob erlaubt oder unerlaubt – nicht alle anderen Tenants am gleichen System ausbremst?

  • Wie protokolliert und überwacht man, welcher Anteil der Systemlast auf welchen Tenant fällt?

  • Im Fall, dass mehrere Tenants sich einen Datenspeicher teilen (z. B. eine DB für mehrere Tenants): Wie sichert man die Daten...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang