SLA, RPO und RTO pragmatisch betrachten

Anwendungen für die Public Cloud entwickeln

Werden Anwendungen als "Software as a Service" aus der Cloud bezogen, so akzeptieren Anwender weder Unterbrechungen noch Performance-Probleme. Eine hundertprozentige Verfügbarkeit ist jedoch kaum erreichbar. Die Lösung ist die "Graceful Service Degredation".

Eine Gartner Umfrage aus dem Jahr 2014 zeigt auf, dass 26 Prozent der CIOs in deutschen Unternehmen bedeutende Investitionen in Public Cloud Technologien getätigt haben. Interessant ist hierbei, dass dieser Wert über dem globalen Wert von 25 Prozent liegt. Ein Viertel der Befragten hat dabei angegeben, dass sie in Services investiert haben. Wobei "Software as a Service" mit 73 Prozent das größte Augenmerk aufweist. Unter "Software as a Service" versteht man die zur Verfügungstellung von Softwarepaketen, bei der der Anwender in der Regel keine Installationsschritte durchführen muss. Ein Login für grafische Anwendung bzw. ein Connection String für Daten-, bzw. Applikationsdienste ist alles, was der Anwender benötigt um den Service zu konsumieren.

Derartige Dienstleistungen müssen ausfallsicher und skalierend aufgebaut werden, da der Anwender keine Unterbrechungen wegen Hardwareproblemen, eingeschränkte Performance wegen Kapazitätsproblemen, Serviceunterbrechungen wegen Updates oder ähnliche Probleme bei Benutzung des Service akzeptiert. Im Unterschied zu klassischer Software, die als Installationsmedium vorliegt und auf lokalen Ressourcen installiert wird, kommt bei "Software as a Service" dem Service Level Agreement (SLA) eine tragende Rolle zu.

Aus dem SLA können Recovery Point Objective (RPO) und Recovery Time Objective (RTO) erarbeitet sowie die passenden Building Blocks für die Architektur gewählt werden. Das SLA bestimmt letztendlich auch die Kosten für den Betrieb des Services. Auch wenn eine hundertprozentige Verfügbarkeit des Service angestrebt wird, ist dies mit einem finanziell vertretbaren Aufwand nicht zu erreichen. Da auch die Provider von Public Cloud-Infrastrukturen deren Dienste, auf denen der eigene Service aufbaut, kein SLA mit einer 100 prozentiger Verfügbarkeit anbieten.

Graceful Service Degredation

Vor Auswahl der Architekturkomponenten sollten pragmatische Abwägungen bezüglich der Absicherung des Service im Problemfall getroffen werden. Häufig beginnt die Entwicklungsabteilung motiviert mit der Erstellung einer Architektur, die eine Vielzahl von Unwägbarkeiten berücksichtig und damit die Funktionalität des Service im Problemfall sicherstellt. Hierfür existieren viele Komponenten beziehungsweise Konzepte, die Verwendung finden können. Einige dieser Best Practice-Ansätze finden sich auch im weiteren Verlauf dieses Artikels.

Bevor die Entwicklungsabteilung jedoch in die Erstellung der Gesamtarchitektur abtaucht, sollte pragmatisch die Möglichkeiten einer sogenannten "Graceful Service Degredation" betrachtet werden. Unter "Graceful Service Degredation" versteht sich die Möglichkeit, einen Service trotz Ausfall eines großen Teils seiner Infrastruktur beziehungsweise von Programmkomponenten eine zwar limitierte, aber dennoch ausreichende Funktionalität zur Verfügung zu stellen.

Beispielhaft kann ein E-Commerce System betrachtet werden, bei dem die Lagerhaltungskomponente nicht erreichbar oder ausgefallen ist. Anstelle dem Anwender eine Fehlermeldung bei der Ermittlung des aktuellen Lagerbestandes im Bestellprozess anzuzeigen und damit die Bestellung unmöglich zu machen, wird dem Anwender die Durchführung der Bestellung ohne Einschränkung ermöglicht. Allerdings wird zum Abschluss der Bestellung nicht die gewohnte Bestellbestätigung erzeugt, sondern eine Mitteilung, die sich für die Bestellung bedankt und darauf hinweist, den möglichen Liefertermin schnellstmöglich mitzuteilen. Diese Meldung kann, sobald die Lagerhaltungskomponente wieder erreichbar ist, erzeugt und versandt werden.

Durch solche Verfahren kann die Funktionalität des Gesamtsystems ermöglicht werden, auch wenn elementare Bestandteile aktuell nicht verfügbar sind oder fehlerhaft arbeiten. Die Berücksichtigung eines solchen Verhaltens im Fehlerfall kann, richtig angewendet, die Komplexität und die Kosten eines ausfallsicheren Systems im Praxisbetrieb deutlich reduzieren. Nach den Überlegungen zum möglichen Serviceverhalten können die technische Betrachtung und der Aufbau einer Architektur für einen hochverfügbaren und ausfallsicheren Service beginnen. Nachfolgend finden Sie einige grundlegende Konzepte, die für den Aufbau eines "Software as a Service"-Angebots (SaaS) berücksichtig werden sollten.