Kolumne: Stropek as a Service

Warum Design to Cost bei SaaS und Cloud wichtiger denn je ist
Keine Kommentare

Immer wieder werde ich gefragt, wie sich Softwarearchitekturen bei SaaS in der Cloud von klassischer Software für den Betrieb bei Endkunden unterscheidet. Ein Aspekt ist die Wichtigkeit des Design-to-Cost-Ansatzes. Damit ist gemeint, dass die Betriebskosten einer SaaS-Lösung von Anfang an als wichtige, nicht funktionale Anforderung berücksichtigt werden.

Dieses Konzept ist nichts vollkommen Neues. Ikea hat es sich schon vor langer Zeit auf die Fahnen geschrieben: „At IKEA we design the price tag first and then develop the product to suit that price.“ Warum spielt Design to Cost jetzt plötzlich auch im Softwarebereich eine so große Rolle?

In der guten, alten Zeit …

Versetzen wir uns in die Lage eines Softwareanbieters, der früher Software zur Installation auf Kundenseite erstellt hat. Welche Motivation hatte er, den Betriebskosten große Bedeutung zuzumessen? Diese Kosten taten ihm nicht direkt weh. Sie waren zu einem großen Teil für ihn nicht sichtbar. Natürlich spielten die Betriebskosten im Vertriebsprozess eine gewisse Rolle, da manche Kunden danach fragten. Meine Erfahrung aus der Praxis ist aber, dass die Funktionen der Software eine viel größere Rolle spielten. Man bezeichnet das auch als Design-to-Value-Ansatz, weil der funktionale Wert der Software für den Kunden maximiert wird, statt Betriebskosten zu optimieren.

Die Kosten verschieben sich

Mit SaaS und Cloud ändert sich das Geschäftsmodell grundlegend. Mit Bezahlung des Abonnements ist die Sache für den Endkunden erledigt. Die Rechnung über die Betriebskosten landet jetzt beim Softwarehersteller, der als SaaS-Anbieter auftritt. Der Softwarehersteller verspürt in dieser Konstellation aus mehreren Gründen starken Druck, mehr auf die Betriebskosten zu achten. Erstens wird die höhere Marge bei niedrigeren Betriebskosten offensichtlich. Statt schwer messbaren Nachteilen im Vertriebsprozess merkt man teure Architekturen und ineffiziente Programmierung in der Cloud sofort und wird jeden Monat daran erinnert.

Noch wichtiger ist meiner Erfahrung nach aber, dass durch SaaS die Gesamtkosten (Total Cost of Ownership, kurz TCO) für den Endkunden wesentlich transparenter werden. Das Verhältnis aus gebotener Funktionalität und Gesamtkosten kann leichter verglichen werden, und dadurch steigt der Wettbewerbsdruck.

Der Einfluss von Cloud-Computing

Cloud-Computing trägt stark zur Bewusstmachung der gesamten Betriebskosten einer Softwarelösung bei. Ohne Cloud ist die Kostenkalkulation schwierig. Man hat es mit einem Mix aus den folgenden Punkten und noch vielem mehr zu tun:

  • Abschreibungen für Hard- und Software
  • Anteiligen Personalkosten für die Systemadministration
  • Operativen Kosten (z. B. Internetanbindung, Strom)
  • Wartungskosten (z. B. Klimaanlage, Wartungsverträge für Hardware und Software)
  • Versicherungen

Die Cloud ändert das. Man hat die Kostenkalkulation jeden Monat schwarz auf weiß in Form der Rechnung des Cloud-Anbieters vor sich. Das gilt insbesondere bei Verwendung von PaaS und Serverless Computing. Bei solchen Cloud-Angeboten entfallen so gut wie alle Administrationskosten auf SaaS-Anbieterseite. Nur noch produktbezogene DevOps-Aufgaben werden durch die Entwicklungsteams erbracht. Installation, Updates, Backups, Skalierung etc. sind in den variablen Cloud-Kosten, die der Cloud-Anbieter verrechnet, eingepreist.

Ich habe laufend mit SaaS-Projekten zu tun, in denen Kunden um Hilfe rufen, weil die monatlichen Kosten in der Cloud im Echtbetrieb aus dem Ruder laufen. Es wird schnell auf die Cloud-Anbieter geschimpft, und man sehnt sich zurück nach der „guten alten Zeit“, in der alles besser und billiger war. Tatsächlich waren in fast allen dieser Fälle, mit denen ich zu tun hatte, die Ursachen für die Kostenprobleme in der Softwarearchitektur zu suchen. Die Architekturen waren technisch nicht schlecht, oft ganz im Gegenteil. Sie waren durchdacht, hoch skalierbar, legten großen Wert auf Datenschutz und Datensicherheit etc. Sie hatten nur ein Problem: Beim Entwurf hat man außer Acht gelassen, welche Betriebskosten sie verursachen.

Beispiele

Machen wir es an einigen konkreten Praxisbeispielen fest:

  • Es ist wünschenswert, dass jede Web-App durch eine Web Application Firewall wie z. B. Azure Application Gateway geschützt wird. Sie basiert auf dem OWASP Core Rule Set und schützt so vor vielen Angriffen, selbst wenn die Webanwendung da oder dort Sicherheitsschwächen hat.
  • Jeder DevOps-Profi möchte, dass die eigenen Web-APIs durch ein professionelles API-Management wie z. B. Azure API Management abgesichert sind. Damit lassen sich z. B. Quotas (maximale Anzahl an API-Aufrufen pro Zeiteinheit) pro Kunde automatisiert definieren.
  • Aus Sicherheitsgründen sollten Backend-Microservices nicht über das Internet erreichbar sein; in Azure App Service lässt sich das durch den Isolated Service Plan
  • Microsoft betont, dass Service Fabric eine ideale Plattform für den Betrieb von Microservices ist. Sie erlaubt es, hoch skalierbare Lösungen mit sehr guter Performance zu erstellen. Ein relativ einfacher Basisdienst wie Azure App Service bietet nicht das gleiche Level an Flexibilität.
  • Um den Lock-in-Effekt zu verringern, kann man auf Docker-Container mit eigenem Kubernetes-Cluster setzen. Diese Architektur lässt sich in der Cloud genauso betreiben wie im eigenen Rechenzentrum.
  • Es hat Vorteile, wenn man jedem Tenant eigene Ressourcen in der Cloud gibt (in Azure z. B. SQL Databases, App Service Plans, IoT-Hubs). Man kann man die zur Verfügung stehende Leistung auf diese Weise genau steuern und diese auch garantieren. Bei Zusammenfassung mehrerer Tenants in einer gemeinsamen Infrastruktur (Pooling) konkurrieren die Tenants um die Ressourcen, und Performancegarantien sind, wenn überhaupt, nur mit hohem Aufwand umzusetzen.

Wir könnten diese Liste noch lange fortsetzen. Jeder Punkt ist aus technischer Sicht richtig. Das Problem ist aber, dass diese Entscheidungen großen Einfluss auf die monatlichen Kosten haben. Erstens ändert sich die Rechnung von Microsoft, und zweitens darf man die Personenstunden nicht vergessen, die notwendig sind, um Services bzw. Architekturen wie die oben genannten zu betreuen.

Geiz ist geil?

Also zur Sicherheit Cloud-Architekturen immer auf ein Minimum reduzieren? Auf keinen Fall! Es geht nicht darum, ganz nach dem Motto „Geiz ist geil“ vorzugehen. Speziell bei größeren Projekten wäre das naiv. Natürlich muss man sich auf die Anforderungen vorbereiten, die um die Ecke lauern. Die Frage ist nur, welche das tatsächlich sind. In der Produktplanung tendieren viele Teams dazu, auf Nummer sicher zu gehen und fordern zu viel statt zu wenig. Wenn ich in Projekten Aussagen wie die folgenden von Entscheidungsträgern höre, sind das für mich Warnsignale, dass Design to Value überhandnimmt und Design to Cost vergessen wird:

  • Wir dürfen bei Datenschutz und Datensicherheit keine Kompromisse eingehen.
  • Auch wenn wir am Anfang nur wenige Kunden haben werden, muss das System für einen späteren großen Kundenansturm gerüstet sein.
  • Unsere Kunden müssen die freie Wahl zwischen On-Premise-Installation, Hybridbetrieb und Cloud haben.
  • Um hohe Qualität sicherzustellen, muss ausnahmslos jeder Aspekt der Software mit automatischen Tests geprüft werden.
  • Investitionssicherheit ist uns wichtig. Die Software muss so robust gebaut sein, dass sie die nächsten fünfzehn Jahre hält.

Verantwortung von Softwarearchitekten

Als Softwarearchitekt haben wir unter anderem die Aufgabe, von Anfang an die Kosten als wichtigen Faktor im Auge zu behalten. Wir müssen Anforderungen wie die oben genannten mit einem Preisschild versehen und den Produktplanern klarmachen, dass übertriebene Funktionen das Geschäftsmodell gefährden können. Man muss Kalkulationen einfordern, in denen erwartete Kundenzahlen, Nutzungsszenarien und Preismodelle in Zahlen festgehalten sind. Man muss den Mut haben, auf Basis der Kalkulationen Kompromisse in Sachen Softwarearchitektur vorzuschlagen, die technisch nicht ideal sind, aber aus Kostensicht zur Art und Größe des Projekts passen. Es braucht Mut zur Lücke, und man muss oft schweren Herzens auf gewisse Komponenten oder Softwaredesigns verzichten.

Das klingt leichter als es ist. Als Architekt muss man wahrscheinlich Kritik von Entwicklerseite einstecken wie „so baut man doch heutzutage keine moderne Cloud-Software“. Falls am Ende der kalkulierte Businessplan nicht hält und ganz andere Benutzerzahlen als geplant die Realität sind, heißt es oft, dass die Architektur nicht gut ist, weil sie nicht ordentlich skaliert oder viel zu teuer ist. Stehen Sie zu Ihren Entscheidungen und weisen Sie darauf hin, dass das Geschäftsmodell fehlerhaft war, nicht die Systemarchitektur.

Unbekannte Faktoren gezielt untersuchen

Warum tun sich Teams so schwer, sich auf das Notwendigste zu beschränken? Warum die Tendenz zum Overengineering? Meiner Erfahrung nach ist der Grund häufig, dass die Anforderungen nicht klar sind. Niemand weiß, wie erfolgreich die Software tatsächlich sein wird, und Benutzerzahlen sind daher schwer abzuschätzen. Man will es allen potenziellen Benutzern recht machen und tut sich daher schwer, Funktionen bewusst wegzulassen. Meine wichtigsten Tipps zur Lösung des Problems sind die folgenden:

  • Produktmanagement und Softwarearchitekten müssen als Team zusammenarbeiten.
  • Unsicherheit und Unwissen müssen ausgesprochen statt versteckt werden. Der erste Schritt zur Lösung des Problems ist, sich das Nichtwissen einzugestehen.
  • Wenn möglich, bespricht man Annahmen in Businessplänen mit (potenziellen) Kunden z. B. in Form von Fokusgruppen.
  • Man schrumpft den Funktionsumfang auf das absolute Minimum (Minimum Viable Product, MVP) und geht damit möglichst rasch zu den Kunden ins echte Leben (z. B. Alphaversionen, Veröffentlichung in einem Testmarkt etc.).
  • Technische Unsicherheiten werden in Prototypen untersucht (z. B. zur Abschätzung der Betriebskosten einer Anwendung in einer Serverless-Computing-Umgebung).

Auf diese Weise baut man solide Softwarearchitekturen und kann fundierte, langfristige Entscheidungen treffen, bei denen Fehler nicht oder nur mit hohen Kosten korrigierbar wären.

Lesen Sie 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

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -