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.
- Checkliste Cloud-SLAs
Um zu beurteilen, ob ein Cloud-Provider kundenfreundliche SLAs anbietet, lassen sich folgende Kriterien anlegen und überprüfen: - Punkt 1:
Kurze und klare Gestaltung von Inhalt, Struktur und Formulierung. - Punkt 2:
Version in der Landessprache des Kunden. - Punkt 3:
Klare Definitionen von Fach- und Produktbegriffen zu Beginn. - Punkt 4:
Detaillierte Ankündigung und Planung der Wartungsfenster (Beispiel: "Viermal im Jahr an vorangemeldeten Wochenenden"). - Punkt 5:
Leistungsbeschreibung in Tabellenform (Übersicht!). - Punkt 6:
Klar definierte Bereitstellungszeiträume für neue Ressourcen (Beispiele: Bereitstellung virtueller Server bei Managed Cloud in maximal vier Stunden; Bereitstellung kompletter Umgebungen oder dedizierter Server in fünf bis zehn Tagen). - Punkt 7:
Bereitstellung von klar abgegrenzten Konfigurationsoptionen für Ressourcen (Beispiel: Konfiguration von Servern nach Gigahertz, Gigabyte). - Punkt 8:
Einfach unterscheidbare Service-Levels (Beispiel: Silber, Gold, Platin); Abgrenzungskriterien können sein: Verfügbarkeit, Bereitstellungszeiten, fest reservierte Kapazitäten ja/nein, Support-Level (Telefon, E-Mail). - Punkt 9:
Bei IaaS-Angeboten unbedingt auf Netzwerk-Konfigurationsmöglichkeiten und Bandbreite achten (Volumen? Im Preis inkludiert ja/nein?). - Punkt 10:
Kundenfreundlicher Reporting- beziehungsweise Gutschriftenprozess (am besten aktive Gutschriften auf Kundenkonto; kein bürokratischer, schriftlicher Prozess; möglichst einfache Beweis- und Nachweispflicht für Kunden). - Punkt 11:
Reaktionszeiten und Serviceverfügbarkeit klar beschreiben (zentrale Hotline; Reaktionszeiten auf Incidents in Stunden). - Punkt 12:
Nennung der Rechenzentrumsstandorte mit Adresse und sonstigen Informationen wie Zertifizierungen und Tier. - Punkt 13:
Definition der Verfügbarkeiten: Unterschiede hinsichtlich Verfügbarkeit Server/VM und Verfügbarkeit Admin-Konsole definieren. - Punkt 14:
Erläuterung zu Möglichkeiten der SLA-Überwachung beziehungsweise des Incident-Reportings für den Anwender (Beispiel: Link auf Monitoring-Dashboard).
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.