Dieser Artikel behandelt das Konzeptions-Thema für eine Software-as-a-Service Lösung anhand eines konkreten Beispiels. Er zeigt, welche Überlegungen hierbei zu bedenken sind und wie sie im betrachteten Fall gelöst wurden.

Einleitung: Was ist SaaS?

Was ist Software-as-a-Service (kurz SaaS) eigentlich?

Der Begriff gehört zu der Gruppe XXX-as-a-Service wobei XXX üblicherweise für einen dieser 3 Begriffe steht: Infrastructure, Platform oder Software – man liest zuweilen noch beliebige andere Begriffe. Im Grunde genommen bedeutet es aber nichts anderes, als die Verwendung des jeweiligen XXX ohne sich mit Installation, Betrieb und Wartung herumschlagen zu müssen. Also sozusagen „Plug and Play“.

Die 3 genannten Begriffe sind üblicherweise aufbauend zu sehen. Das bedeutet, die unterste Stufe ist die Infrastruktur, z.B. das Hosting eines Servers durch einen Provider. Darüber kommt die Plattform, z.B. Datenbanken oder Middlewares. Ganz oben in dieser Reihung steht dann eine fertig zu verwendende Software. Das sind dann typische Cloud-Applikationen, die jeder von uns kennt. Je weiter man hier nach oben steigt umso näher kommt man dem Anwender.

Aus gegebenem Anlass – dem Start unseres neuen SaaS Dienstes „design2budget“ – möchte ich hier einige Grundkonzepte beschreiben, die beim Design so einer Lösung zu beachten sind.

Basisverständnis

Um die nachfolgend beschriebenen Überlegungen und die getroffenen Entscheidungen zu verstehen, möchte ich einen kurzen Einblick geben, was design2budget ist.

design2budget ist eine Cloud-Applikation mit der eine Firma ihre Kunden, Angebote und Aufträge verwalten bzw. in weiterer Folge natürlich auch Verrechnungs- und Mahnwesen automatisiert abbilden kann. Die Grundidee ist – Sie kennen es sicher auch aus eigener Erfahrung – wenn Sie ein bestimmtes Vorhaben planen, holen Sie sich Angebote ein. Oft dauert es mehrere Wochen, bis Sie das Angebot erhalten und dann sitzen Sie besser auf einem Stuhl, denn neben der Themenverfehlung entspricht der Preis nicht dem was Sie im Kopf hatten. Unsere Lösung schafft hier Abhilfe, denn wir setzen auf den Einsatz von modernen Endgeräten, wie z.B. Tablets, mit denen Ihnen der Vertriebsmitarbeiter bereits vor Ort einen Preis nennen kann und das Angebot entsprechend Ihren Wünsche gestalten kann.

Wichtig für die folgenden Konzeptbeschreibungen ist jedoch, dass es sich bei den Kunden um Firmen handelt, die durchaus auch mehrere Benutzer (Vertriebsmitarbeiter, Techniker, Backoffice Mitarbeiter, …) haben. Daher wird das Wort „Mandant“ als Synonym für die Firma eingesetzt und die Benutzer sind User Accounts die einem Mandanten zugeordnet sind.

Datenhaltung und Datentrennung

Da die in design2budget abgelegten Daten sensibler Natur sind, war für uns eine Mandantentrennung eine fixe Voraussetzung. Jeder Mandant erhält in unserer Lösung tatsächlich eine eigene Datenbank. Um diese strikte Trennung noch zu verschärfen, werden hierbei pro Mandant zufallsgenerierte Zugangsdaten erstellt und verschlüsselt hinterlegt. So hat ein Angreifer keine Chancen, bei Kompromittierung eines Mandanten auf die Daten eines anderen Mandanten zuzugreifen.

Skalierung

Eine Cloud-Applikation ist vom Prinzip her so ausgelegt, dass möglichst viele Anwender diese Software verwenden können. Um diesen Anspruch gerecht zu werden, sind bereits in der Konzeptionsphase entsprechende Skalierungsmaßnahmen zu planen. Die bei diesen Konzepten oft getroffene Entscheidung „dann geben wir der Maschine darunter einfach mehr RAM oder CPU“ hilft hierbei leider nur begrenzt weiter. Selbst mit Virtualisierungstechnologie ist damit sehr schnell Schluss.

Mit design2budget haben wir uns für eine 2-stufige Skalierungsvariante auf Applikationsebene entschieden. In der Stufe 1 wird einem Mandant ein primärer (von mehreren vorhandenen) Applikationsserver zugeteilt. Erreicht der Mandant eine bestimmte Größe (Anzahl an Benutzern) tritt Stufe 2 in Kraft. Die Applikation wird auf mehrere gleich berechtigte Applikationsserver aufgeteilt und mit einem vorgelagerten Load-Balancer wird die Belastung gleichmäßig verteilt.

Deployment

Um die beschriebene Datentrennungs- und Skalierungsmaßnahmen umzusetzen benötigt es natürlich einer Steuerung. Hierzu gibt es ein Management Service, welches mit einer zentralen Instanz – dem Management-System – die anfallenden Tasks koordiniert und durchführt. Dazu gehören:

• Aktivierung eines neuen Mandanten
• Deaktivierung / Löschung eines Mandanten
• Automatische Ressourcen Verteilung
• Update der Applikation
• Reporting (für Verrechnungszwecke)
• Backup- und Notfall-Mechanismen

Beim Betrieb eines Cloud-Services sollte das Konzept also bereits vorsehen, möglichst viele Tätigkeiten zu automatisieren.

Reporting

Was ist mit Reporting gemeint? Natürlich bietet design2budget eine Reporting Engine mit der die Hit-Rate, Conversion-Rate, usw. ausgewertet werden kann. Doch hier in diesem Artikel ist damit das notwendige Reporting für eine Verrechnung aus unserer Sicht gemeint.

Unser Verrechnungs-Modell basiert auf einer monatlichen Basisgebühr, welche 3 Benutzer-Accounts beinhaltet. Optional können weitere Benutzer-Accounts direkt im Programm angelegt werden.

Daher benötigen wir für jeden Mandanten die Anzahl an aktiven Benutzern um diese entsprechend zu verrechnen. Wie bereits erwähnt, haben wir keinen direkten Zugriff auf die Datenbanken, denn die Zugangsdaten wurden zufällig erzeugt und verschlüsselt abgelegt. Daher übernimmt der im vorigen Absatz genannte Management-Service die Aufgabe, diese Daten pro Mandant zu sammeln und an unser zentrales Management-System zu übermitteln.

Wir als Betreiber haben daher nur die Daten zur Verfügung, die wir zur direkten Verrechnungen benötigen. Zu einem sauberen Konzept gehört für uns auch die Überlegung, welche Daten hat wer wann im Zugriff.

Partner-Konzept

Wie bereits angesprochen, handelt es sich um sensible Daten, die durch unsere Lösung generiert und verwaltet werden. In Zeiten in denen viele Unternehmen Ihre Mails und Kalender einem großen Suchmaschinenbetreiber anvertrauen, gibt es weiterhin Unternehmen, die Ihre Daten selbst verwalten – in der sogenannten Private-Cloud.

Unsere Lösung nimmt auf diesen Umstand Rücksicht und das vorher beschriebene Deployment- und Skalierungsmodell erlaubt es, eine Instanz von design2budget in der eigenen Firma oder im eigenen Rechenzentrum zu betreiben.

Der Mandant erhält eine vollständige Umgebung inkl. vorher angesprochenem Management-System. Dieses System dient als Gateway um sich mit unserer zentralen Management-Instanz zu verbinden, um dort die konsolidierten Reporting Daten für unsere Verrechnung abzuliefern und sich Applikations-Updates zu holen.

Durch dieses Konzept ist es uns sogar möglich, das gesamte Cloud-Service – mit allen beschriebenen Mechanismen – schlüsselfertig einem Partner als OEM Produkt zur Verfügung zu stellen. Der Partner kann seine eigene Infrastruktur verwenden um mehrere Applikationsserver aufzusetzen, selbst wiederum mehrere Mandanten anzulegen, diese zentral zu verwalten und die Abrechnung zu übernehmen. Das zentrale Management-System des Partners nimmt die gleiche Gateway-Rolle wie bei der Private-Cloud Variante ein und übermittelt an unsere Management-Instanz die konsolidierten Informationen, wie die Gesamtanzahl an Mandanten und die Gesamtanzahl an Benutzern aller Mandanten zusammen.

Abschlussbemerkung

Wie man aus den hier angeführten Überlegungen sieht, ist es nicht einfach damit getan, eine Webanwendung zu schreiben und diese auf einem Webserver zu installieren.

Will man SaaS professionell betreiben, so sind eine Menge Überlegungen im Hintergrund anzustellen und entsprechend umzusetzen:

• Datenhaltung: wo und wie lege ich die Nutzerdaten ab
• Datensicherheit: wer darf wann auf welche Daten zugreifen, welche Daten brauche ich als Betreiber
• Skalierung: wie gehe ich mit steigender Belastung um
• Automatisierung: was kann ich automatisieren, wie übernehme ich das Deployment, Updates, …
• Verrechnung: welche Daten benötige ich und wie komme ich zu den Daten, die ich zum Verrechnen benötige
• Markterweiterung: wie kann ich meine Lösung wiederverwenden, wie kann ich neue Märkte erschließen (in unserem Fall durch das Partner Modell)

Ausblick

Wir haben uns nicht nur mit den Konzepten und der Technik beschäftigt. Auch gehen wir mit unserem Produkt neue Themen an. In einem kommenden Artikel werde ich den Trend Gamification etwas näher beleuchten.

Über den Autor

Ing. Leo Eibler ist im Bereich Beratung und IT Service Management tätig sowie Geschäftsführer von cubic zebra. Das in diesem Artikel als Beispiel herangezogene Projekt design2budget wurde durch cubic zebra entwickelt und wird als Cloud-Service vertrieben.

Ähnliche Artikel:

• Noch keine vorhanden.