© 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.

Rainer Stropek


Multi-Tenancy als wichtiger WettbewerbsvorteilAbbildung 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.Abb. 1: Kombinierte SystemauslastungWie 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 eines einzelnen Tenants und stellt sie wieder her? Wie garantiert man, dass durch einen Programmfehler nie ein Tenant die Daten des anderen sieht?Wie kann man mehrere Versionen einer Software gleichzeitig in einem Multi-Tenant-System betreiben (Tenant A will Version 1.0 verwenden, Tenant B aber schon auf 2.0 umsteigen)?Entwicklungskosten vs. BetriebskostenMan möchte eine kaufmännische Weblösung für kleine Unternehmen als SaaS anbieten. Die kleinsten Kunden, die man ansprechen möchte, würden pro Monat 25 Euro bezahlen.Will man die eigene Software mit Azure VMs (IaaS) betreiben, kostet schon ein winziger Basic-Server 11 Euro/Monat.Die kleinste Standarddatenbank, die in der Praxis in Sachen Leistung ziemlich beschränkt ist, kostet 13 Euro/Monat.In Summe würde eine Single-Tenant-Lösung, bei der jeder Kunde eine eigene VM und eine eigene DB erhält, 24 Euro verschlingen. Bei 25 Euro Umsatz wäre das Geschäftsmodell kaum tragfähig.Web-AppsDurch das Deployment einer eigenen Web-App pro Tenant lässt sich auch der gleichzeitige Betrieb mehrerer unterschiedlicher Versionen oder Kundenumgebungen (z. B. Test vs. Produktion) problemlos abbilden.Azure SQL DatabaseDocker-ContainerDeployment und WartungFazitEs gibt aber auch eine Kehrseite der Medaille. „High Density Hosting“-Lösungen wie App Services, Elastic Database Pools oder Docker können heute nicht die gleiche Sicherheit bieten, die Tenant-Trennung durch virtuelle Maschinen oder gar physische Server aufweist. Bei Anwendungen m...

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


Multi-Tenancy als wichtiger WettbewerbsvorteilAbbildung 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.Abb. 1: Kombinierte SystemauslastungWie 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 eines einzelnen Tenants und stellt sie wieder her? Wie garantiert man, dass durch einen Programmfehler nie ein Tenant die Daten des anderen sieht?Wie kann man mehrere Versionen einer Software gleichzeitig in einem Multi-Tenant-System betreiben (Tenant A will Version 1.0 verwenden, Tenant B aber schon auf 2.0 umsteigen)?Entwicklungskosten vs. BetriebskostenMan möchte eine kaufmännische Weblösung für kleine Unternehmen als SaaS anbieten. Die kleinsten Kunden, die man ansprechen möchte, würden pro Monat 25 Euro bezahlen.Will man die eigene Software mit Azure VMs (IaaS) betreiben, kostet schon ein winziger Basic-Server 11 Euro/Monat.Die kleinste Standarddatenbank, die in der Praxis in Sachen Leistung ziemlich beschränkt ist, kostet 13 Euro/Monat.In Summe würde eine Single-Tenant-Lösung, bei der jeder Kunde eine eigene VM und eine eigene DB erhält, 24 Euro verschlingen. Bei 25 Euro Umsatz wäre das Geschäftsmodell kaum tragfähig.Web-AppsDurch das Deployment einer eigenen Web-App pro Tenant lässt sich auch der gleichzeitige Betrieb mehrerer unterschiedlicher Versionen oder Kundenumgebungen (z. B. Test vs. Produktion) problemlos abbilden.Azure SQL DatabaseDocker-ContainerDeployment und WartungFazitEs gibt aber auch eine Kehrseite der Medaille. „High Density Hosting“-Lösungen wie App Services, Elastic Database Pools oder Docker können heute nicht die gleiche Sicherheit bieten, die Tenant-Trennung durch virtuelle Maschinen oder gar physische Server aufweist. Bei Anwendungen m...

Neugierig geworden?


   
Loading...

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