Die Cloud veränderte unsere Softwarearchitekturen

Die Cloud bringt neue Services

Die Cloud-Anbieter stellen eine große Anzahl von vorgefertigten Services wie Datenbanken, Benutzerverwaltungen, Message Broker und vieles mehr bereit. Damit unterscheidet sich die Betriebsumgebung unserer Software in der Cloud erheblich von der im klassischen Rechenzentrum vorzufindenden Umgebung.

Im On-Premises-Rechenzentrum

Wenn wir im Java-Umfeld Software erstellen, die im Rechenzentrum der Kundschaft (On-Premise) laufen soll, stehen als Umgebung meist ein Applikationsserver oder eine Docker-Umgebung sowie eine relationale Datenbank bereit. Weitere Services wie zum Beispiel

• NoSQL-Datenbanken,
• Queueing Server oder
• Benutzerverwaltung für externe Benutzerinnen und Benutzer

sind selten. Wenn es sich bei der neuen Software nicht gerade um das Kernsystem der Kundschaft handelt, ist es auch nicht möglich, solche Services produktionsreif bereitgestellt zu bekommen. Dafür müssten mindestens folgende Themen angegangen werden:

• Hochverfügbarkeit
• Patch Management
• Authentifizierung
• Verschlüsselung von Daten
• Backup und Restore

Bei neuen Services fehlt aber oft das notwendige Fachwissen. Die Kosten und das mit dem neuen Service einhergehende Risiko für Störungen im Betriebsablauf sind in der Regel zu hoch.

Managed Services bei Cloud-Anbietern

Für Cloud-Anbietende sind Services keine Kosten und Risiken, sondern sie sind ein Produkt, das Geld einbringt. Dementsprechend wird hier anders investiert und Services, die im On-Premise-Rechenzentrum nicht bereitgestellt werden konnten, sind plötzlich verfügbar.

In diesem Blog-Beitrag ziehe ich Amazon Web Services (AWS) für Beispiele heran. Die Google Cloud und Microsoft Azure bieten zwar ähnliche Dienste an, aber persönlich bin ich auf AWS spezialisiert.

In der Cloud können wir einen Service, wie zum Beispiel eine Datenbank, selbst in einer virtuellen Maschine betreiben. Gegenüber dem eigenen Rechenzentrum bietet das aber keinen Vorteil. Wählen wir stattdessen eine von AWS betriebene Datenbank, kümmert sich AWS um die oben genannten Betriebsthemen.

Im Datenbankbereich bietet AWS neben SQL-Datenbanken auch Key-Value-, Dokument- und Graph-Datenbanken, Volltextsuchmaschinen sowie Exotischeres wie zum Beispiel Blockchain-Datenbanken. Insgesamt bietet AWS mehr als 200 Services an.

Die Auswirkungen auf die Architektur

Wenn wir einen neuen Service wie zum Beispiel eine Datenbank einführen möchten und dabei einen Managed Service eines Cloud-Anbietern nutzen, setzen wir auf bereits bestehende Infrastruktur mit bekannten Stärken und Schwächen auf. Das senkt das Risiko für die Einführung des Dienstes deutlich. Bei der Einführung eines selbst betriebenen Services und dessen Integration in die eigene Umgebung gibt es immer Unwägbarkeiten, die zu Zeitverzug und höheren Kosten führen können. Wenn diese Risiken wegfallen, kann man sich besser auf die eigentliche Anwendungsentwicklung konzentrieren und es wagen, innovativere Software zu entwickeln. Mit der Möglichkeit, neue Services abseits von SQL-Datenbanken und Applikationsservern zu nutzen, können wir Services auswählen und integrieren, die besser zu unserer Software passen. Früher habe ich zum Beispiel mangels Alternativen oft

• Benutzerverwaltungen implementiert,
• die Graphen von Organisationsstrukturen in einer relationalen Datenbank verwaltet,
• Bilder und Dokumente in einer relationalen Datenbank gespeichert und
• asynchrone Events in einer Datenbank simuliert.

Mit den passenden Services ist das alles nicht mehr notwendig. Die Software wird dadurch einfacher, enthält weniger Fehler und ist schneller fertig.

Kostenmodell

Die verbrauchsabhängigen Kosten in der Cloud machen einen anderen Umgang mit den Betriebskosten notwendig.

Im On-Premise-Rechenzentrum

Bei einem klassischen Softwareprojekt spielen die Betriebskosten nur beim Projektstart eine Rolle. Dann werden die erforderliche Hardware und die benötigten Lizenzen abgefragt. Ist die Software erst mal in Betrieb, spielen die Betriebskosten kaum noch eine Rolle. Werden Änderungen beauftragt, um Lizenzkosten zu reduzieren – beispielsweise, um ein teures Datenbanksystem durch ein günstigeres zu ersetzen –, hat das kaum Auswirkungen. Da die Infrastruktur vorhanden ist und vorab bezahlt wurde, führt nachträglich effizientere Software nicht zu Einsparungen. Die Betriebskosten werden nicht in einzelne Softwarekomponenten aufgeschlüsselt und aus Sicht der Softwareentwicklung werden Betriebskosten als bereits vorhandene Kosten angesehen.

In der Cloud

In der Cloud finden sich unterschiedliche verbrauchsabhängige Kostenmodelle. Effizientere Software kann zu unmittelbaren Einsparungen führen, indem sie weniger kostenpflichtige Aufrufe zur Folge hat, weniger Speicher nutzt oder weniger beziehungsweise kleinere virtuelle Maschinen benötigt.

Über Tagging können die Betriebskosten einzelnen Softwarekomponenten zugeordnet werden. Das ermöglicht es manchmal sogar, die Kosten einer einzelnen Transaktion oder die Kosten pro User zu berechnen.

Auswirkungen auf die Architektur

Die Cloud-Kostenmodelle ermöglichen neue Blickwinkel bei Architekturentscheidungen. Man kann die Auswirkungen einer Architekturänderung auf die Betriebskosten kalkulieren und mit den Kosten für die Änderung in Beziehung setzen. Eine lohnende Kostenreduktion kann dann der alleinige Grund für die Änderung einer Software sein. Voraussetzung für eine Kalkulation sind hinreichend viele Daten aus dem bisherigen Betrieb der Software.

Bei der Technologieauswahl können plötzlich die Betriebskosten eine entscheidende Rolle spielen. Bei Cloud-Anwendungen sollte beispielsweise geprüft werden, ob eine SQL-Datenbank wirklich notwendig ist oder ob auch eine günstigere Key-Value-Datenbank ausreicht.

Serverless Functions

Serverless Functions sind eine echte Cloud-Innovation, für die es keine Entsprechung in On-Premise-Rechenzentren gibt. Bei AWS heißen die Serverless Functions „Lambda Functions“ und erlauben es, Code-Artefakte – zum Beispiel JavaScript, Python-Skripte oder Java Jar-Dateien – in der Cloud ohne eigenen Server auszuführen. Die Abrechnung erfolgt dabei über die Anzahl der Aufrufe, den Zeitverbrauch und den Speicherverbrauch. Bei Pausen zwischen Lambda-Funktionsaufrufen kommt es vor, dass die Laufzeitumgebung abgebaut und beim nächsten Aufruf neu aufgebaut wird. Für eine gute Performance ist deshalb eine rasant startende Laufzeitumgebung wichtig.

Auswirkungen auf die Architektur

Das Kostenmodell und das Startverhalten von Lambda-Funktionen sprechen gegen das Verwenden von Frameworks mit hohem Speicher- und Start-Overhead wie zum Beispiel Spring Boot oder Java-EE. Der Overhead schlägt sich direkt auf die Betriebskosten nieder. Langsam startende Frameworks führen zu hohen Latenzen beim Erstaufruf. Im Java-Bereich führte dies zum Aufkommen von schlankeren und effizienteren Frameworks wie Quarkus sowie zu schneller startenden Umgebungen wie der GraalVM.

Das Startverhalten macht es ungünstig, Ressourcen mit hohem Initialisierungsaufwand wie zum Beispiel SQL-Datenbankverbindungen zu verwenden. Eine Persistenzschicht auf Basis von SQL-Datenbanken ist daher ungünstig für Lambda Functions.

Mittlerweile sehen wir immer öfter, dass komplette Anwendungen auf Basis von Lambda Functions entwickelt werden. Für Anwendungen mit geringer Last bietet das einen Kostenvorteil.

Fazit

In der Cloud können wir durch die Auswahl passender Managed Services mit geringerem Risiko maßgeschneiderte und innovative Applikationen bauen. Die Kostenmodelle der Cloud führen zu einem zusätzlichen Faktor bei Architekturentscheidungen. Und mit Serverless Functions kommen neue, schlankere Architekturansätze auf.