Kolumne: Stropek as a Service

Multi-Tenancy in Azure neu denken: Tipps für Softwarearchitekten
Kommentare

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_as_a_service_azure

Abb. 1: Kombinierte Systemauslastung

Herausforderungen

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

  1. 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.
  2. 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?
  3. Wie protokolliert und überwacht man, welcher Anteil der Systemlast auf welchen Tenant fällt?
  4. 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?
  5. 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)?

Die Liste an Herausforderungen könnte noch lange fortgesetzt werden. Es steht also höherer Entwicklungsaufwand und ein gewisses Sicherheitsrisiko reduzierten Betriebskosten durch bessere Systemauslastung gegenüber. Was tun?

Entwicklungskosten vs. Betriebskosten

In den Anfangszeiten von Azure war die Entwicklung eines Multi-Tenant-Systems eine echte Herausforderung. Die Tenant-Trennung und Ressourcenüberwachung musste auf Anwendungsebene programmiert werden. Da die Mindestkosten pro virtueller Maschine und pro Datenbank vergleichsweise hoch sind, nahmen viele CSVs (auch das Team in meinem Unternehmen) die Komplexität und hohen Entwicklungskosten von Multi-Tenancy in Kauf, damit die Grenzkosten pro Tenant niedrig gehalten werden konnten. Hier eine kurze Beispielkalkulation:

  • Man 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.

Die Lösung: Pooling

Startet man heute als CSV in Azure und entscheidet man sich, auf PaaS statt IaaS zu setzen, sieht die Welt ganz anders aus. Durch einige der neuen Dienste wird Multi-Tenancy fast schon zum Kinderspiel. Der Grund ist, dass Microsoft bei einigen der wichtigsten PaaS-Dienste das Anmieten von Ressourcenpools erlaubt, denen dann flexibel Tenants zugeordnet werden können. Aus Sicht der Anwendung handelt es sich um eine Single-Tenant-Lösung. In Wahrheit übernimmt aber Microsoft die Trennung der Tenants und im Fall der Datenbank sogar die Verhinderung einer Übernutzung durch einzelne Tenants. Lassen Sie uns einige Beispiele näher betrachten.

Web-Apps

App Services ist einer meiner Lieblingsdienste in Azure. Bei der gebotenen Funktionalität fühlt man sich als Webentwickler fast wie im Himmel. In Sachen Multi-Tenancy ist das Schöne, dass bei App Services nicht pro Web-App bezahlt wird. Stattdessen legt man App Service Plans an und bezahlt auch je Plan. Die Web-Apps werden dann jeweils in einen Plan deployt, sind aber von den anderen Web-Apps im Plan getrennt. Es liegt also nahe, pro Tenant eine Web-App zu deployen. Je nach Größe der Kunden kann man dann die Pläne skalieren (Scale-up und Scale-out) beziehungsweise mehr oder weniger Tenants in einen Plan zusammenfassen. Die Kostenstruktur ist dadurch dem Umsatz angepasst.

Durch 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 Database

SQL Database war früher ein Service, der Multi-Tenant-Entwicklern viel Kopfschmerzen bereitet hat. Seit einigen Monaten ist das vorbei. Man kann mittlerweile Elastic Database Pools kaufen und für die (dynamisch anpassbare) Leistung des gesamten Pools bezahlen. Dem Pool werden dann Datenbanken zugeordnet, und diese werden mit Leistungsgrenzen versehen, um eine faire Ressourcenverteilung abzusichern. Jedem Tenant kann dadurch eine eigene Datenbank gewidmet werden, ohne es mit übertrieben hohen Grenzkosten bezahlen zu müssen. Dass eine DB pro Tenant auch in Sachen Backup und Restore eine große Erleichterung ist, muss wohl nicht betont werden.

Docker-Container

Wer mit PaaS-Diensten wie App Services und SQL Database nicht arbeiten will oder kann und sich lieber selbst um seine Infrastruktur kümmert, der findet in Azure mittlerweile gute Docker-Unterstützung. Docker-Container sind ein effizienter Weg, mehrere Tenants getrennt voneinander auf einer VM zu betreiben. Stand heute steht Docker produktiv nur für Linux-Dienste zur Verfügung. 2016 kommt die Docker-Containertechnologie auch in Windows an. Ausprobieren kann man das in Azure heute schon mithilfe der Windows Server 2016 Preview Images.

Deployment und Wartung

Betreibt man pro Tenant eigene Web-Apps und Datenbanken, ist man gezwungen, den Deployment-Prozess zu automatisieren. Durch den Azure Resource Manager (ARM) und die ARM-Templates hat Azure auch in diesem Bereich eine Lösung zu bieten. Als DevOps-Team kann man sowohl das Ausrollen der Basisinfrastruktur (z. B. App Service Plans, Elastic Database Pools) als auch das Deployment eines Tenants (z. B. Web-App, Datenbank) ohne viel PowerShell-Know-how automatisieren. Die Dauer des Deployments aller für einen Tenant notwendigen Ressourcen ist wichtig, da das die Zeit ist, die ein Tenant nach Anmeldung zum jeweiligen SaaS-Service warten muss, bis er loslegen kann. Zum Glück ist die Deployment-Zeit bei Web-Apps und Databases kurz. Azure hat hier wenig zu tun, die Hauptaufgabe wurde beim Anlegen der Ressourcenpools erledigt.

Fazit

Als Softwarearchitekt einer Cloud-Lösung muss man Multi-Tenancy als wichtige Systemeigenschaft im Kopf behalten. Noch bis vor Kurzem hieß das, viel Zeit und Mühe in Design und Entwicklung zu investieren. Neue PaaS-Angebot von Microsoft haben die Karten neu gemischt. Aus Sicht der Anwendung handelt es sich um Single-Tenant-Umgebungen. Microsoft übernimmt durch Ressourcenpooling das Management und die Abgrenzung der Tenants.

Es 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 mit allerhöchsten Sicherheitskriterien muss das bedacht werden. Für die Mehrzahl der Anwendungen, die mir in der Praxis begegnen, sind die Multi-Tenancy-Funktionen von Azure gut anwendbar und eine massive Erleichterung für CSVs.
 

Lesen Sie hier alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -