Die Auswahl des richtigen Cloudanbieters ist zweifelsohne eine der wichtigsten Entscheidungen bei einer Cloudmigration. Schließlich müssen die migrierten Anwendungen auch sicher funktionieren. Die wichtigste Garantie dafür ist jedoch ein belastbares Service-Level-Agreement mit dem Provider. Ein solches Papier dokumentiert das gemeinsame Verständnis von Bank und Dienstleister bezüglich Sicherheit und Performance der ausgelagerten Anwendungen. Die Bank behält dadurch die Kontrolle, nicht zuletzt im Sinne der aufsichtlichen Anforderungen. Gerade bei Service-Level-Agreements für Cloudumgebungen gibt es einige für einen reibungslosen IT-Betrieb besonders beachtenswerte Punkte.
Zahlreiche Institute entscheiden sich für eine Multicloud-Umgebung, weil sie sich nicht von einem einzigen Anbieter abhängig machen möchten. Vielmehr wollen sie im Falle eines Falles die Vorteile Cloud-nativer Anwendungen nutzen, etwa den schnellen Wechsel auf eine andere Umgebung. Doch auch für den Betrieb in der neuen Peripherie sind natürlich Service-Level-Agreements nötig. Es ist also ratsam, diese möglichst übergreifend und neutral, gleichzeitig aber spezifisch genug zu formulieren. Neutral bedeutet in diesem Zusammenhang: sowohl bezüglich der referenzierten Technologie als auch der zugrundeliegenden Businessmodelle der Cloudanbieter.
Für die eigenen Service-Level-Agreements sollte eine einheitliche Richtlinie die verwendeten Begrifflichkeiten definieren. Die betrachteten Service-Level-Objectives (SLOs) wie unter anderem Verfügbarkeit oder Antwortzeit sollten bei den Cloudanbietern bekannt und vergleichbar sein. Sofern für ein SLO verschiedene Metriken existieren, ist klarzustellen, welche davon für eine Überprüfung maßgeblich ist.
In der Cloud gibt es unterschiedliche Betriebsmodelle wie Software-as-a-Service, Infrastructure-as-a-Service, Function-as-a-Service und weitere. Jedes davon hat eigene Aspekte, die ein Service-Level-Agreement berücksichtigen muss. Bei der Migration von Altanwendungen in die Cloud passiert es nicht selten, dass sich das Betriebsmodell mit der Zeit ändert. So kann der erste Schritt in die Cloud eine einfache Verschiebung der Anwendung vom eigenen On-Premises-Rechenzentrum auf die entsprechende Plattform beim Cloudanbieter sein, sogenanntes Lift-and-Shift.
Im Zuge der weiteren Cloudifizierung der Anwendung können immer weitere Services der Cloudanbieter eingebunden werden, wie etwa Datenbankdienste. Die Bank kann dadurch zunehmend mehr Flexibilität gewinnen und Einsparungen realisieren. Allerdings muss sich jede dieser Änderungen auch in Anpassungen an den SLAs für die Anwendungen niederschlagen.
Ob ein Service-Level-Agreement eingehalten wird, muss ein umfassendes Monitoring überwachen, inklusive einer entsprechenden Protokollierung. Hier kommt es darauf an, die für den Status der Anwendungen aussagekräftigen Key Performance Indicators (KPIs) zu finden. Für das Service-Level-Objective Verfügbarkeit könnten dies zum Beispiel die Uptime oder der Prozentsatz erfolgreicher Aufrufe sein. Bei Letzteren könnte zusätzlich die maximal zulässige Antwortzeit als Maßstab infrage kommen. In einer hybriden Multicloud-Umgebung besteht ergänzend die Herausforderung, Messdaten von allen Providern zu sammeln und gegebenenfalls mit dem schon bestehenden On-Premises-Monitoring zu verbinden.
Eine detaillierte Kenntnis und das genaue Verständnis des gesamten Umfeldes sind beim Thema Cloudcomputing unerlässlich, um ein aussagekräftiges Monitoring aufzusetzen oder belastbare Service-Level-Agreements auszuhandeln. Für eine erfolgreiche Strategie sind neben tiefem technischem Wissen um die Implementierung und Abhängigkeiten der einzelnen Anwendungen auch bankfachliche Prozesskenntnisse unentbehrlich. Dies gilt primär in einer hybriden Multicloud-Umgebung. Hier helfen Muster-SLAs mit einer Obermenge an SLA-Statements. PPI-Experten arbeiten diese gerne gemeinsam mit Ihnen aus und tragen dafür Sorge, dass diese exakt auf Ihre speziellen Bedürfnisse zugeschnitten sind.
