In Ergänzung zu meinem Blog “Woran sich IT-Erfolg wirklich messen lässt” schreibe ich heute über ein verwandtes Thema.1 Es handelt von den Versprechungen von Cloud- und Service-Anbietern und wie diese mit Verfügbarkeiten jenseits von 99% locken.
Anexia/Netcup, der Infrastruktur-Anbieter bei dem ich u.a. meinen Mailserver, VPN-Gateway und ein paar andere Hosts betreibe, spricht auf seiner Homepage von 99,6% Verfügbarkeit.2 Das bedeutet einen rechnerischen Ausfall von bis zu 40 Minuten in der Woche oder bis zu 35 Stunden im Jahr.
Microsoft Azure nennt zum Beispiel 99,95% oder 99,99% als Richtwert für Enterprise-Verfügbarkeit.3 Rechnerisch entspräche das maximal nur eine Minute Ausfall in der Woche oder nur bis zu 53 Minuten im ganzen Jahr. Auf den ersten Blick beeindruckend.
Wie so oft steckt die Tücke nicht in der Technik.
Etwas SLA-Akrobatik
Gemessen wird bei den meisten Anbietern anhand vieler einzelner SLAs (Service-Level-Agreements).4 Die Verfügbarkeit einer virtuellen Maschine ist dabei losgelöst von der Verfügbarkeit des Storages, der Authentifizierung oder eines Reverse- oder Load-Balancing Proxies.5
Klingt kompliziert? Ja, ist es auch. Aus vielen Projekten weiß ich, dass diese Detailtrennung zum Stolperstein werden kann. Gleichzeitig findet eine Verschiebung aus der Technik in juristische Feinheiten mit eigenen Spielregeln. Es gibt sogar extra Seminare für den Durchblick.6
Bei diesen Punkten genauer hinsehen
Hier einige Tricks der Branche in der Übersicht. Sie gelten nicht für alle Anbieter und sind nicht als allgemeingültige Aussagen zu verstehen. As always: Kein Anspruch auf Vollständigkeit. Your mileage may vary.
SLAs greifen erst nach Eingang eines Support-Tickets. Die häufig benötigten 10-15 Minuten zuvor zum Entgegennehmen, Gegenprüfen und Ausformulieren eines Tickets fallen unter den Tisch. Kommen externe Dienstleister und weitere Service-Partner hinzu, können Stunden vergehen, bis es zum Ticket kommt.
Kurzfristig angekündigte “geplante” Wartungsarbeiten zählen in vielen SLAs nicht als Ausfallzeiten und sind für Anbieter praktisch ein “Freifahrtschein”. Ob Ausfall oder “geplante” Wartung, aus Kundensicht ist ein System nicht verfügbar.
Kurze Ausfälle von z.B. weniger als 5 Minuten werden bei vielen Anbietern vertraglich ausgenommen. Nur leider ergeben 15 Ausfälle mit je 4 Minuten am Ende des Monats auch eine volle Arbeitsstunde, die unter den Tisch fällt.
Mehrere Ausfälle mit einer gemeinsamen Ursache werden zu einem Event zusammengefasst. Aus drei Ausfällen mit jeweils 10, 20 und 30 Minuten wird bei Behebung ein einziges Event mit lediglich 30 Minuten Gesamtzeit, statt der tatsächlichen 60 Minuten.
Unterschiedliche Messpunkte im Monitoring: Anbieter eines Services messen Verfügbarkeit oft nur intern an einer API, nicht jedoch am eigentlichen Service. Führen beispielsweise hohe Latenzen zur Nichtbenutzbarkeit eines Dienstes, wird dies nicht erfasst.
Komplexe Nachweispflichten und Meldewege. Ein Kunde muss Ausfälle selbst dokumentieren und standardisierte Meldewege einhalten. Für Nicht-Techniker oftmals kaum zu bewältigen. Eine Komplexität und häufige Änderungen im Ablauf sind hier mitunter gewollt.
SLAs werden immer monatlich und nicht jährlich betrachtet. “Schlechte” Monate gehen unauffällig in der Gesamtstatistik unter.
Lokale oder regionale Ausfälle zählen nicht, wenn andere Regionen des Anbieters weiter laufen. Wirtschaftlich ist es trotzdem für den Kunden schmerzhaft, formal liegt aber kein SLA-Bruch vor.
SLAs gelten nur bei Verwendung der “richtigen Architektur” oder Buchung bestimmter Dienste. Microsoft Azure gewährt zum Beispiel die 99,99% Verfügbarkeit nur, wenn Azure auch so benutzt wird, wie Azure es gerne hätte mit Availability Groups, Zonen, mehreren Instanzen und vielem mehr. Das wissen anfangs viele nicht. Und später handeln einige bewusst anders, aus Kostengründen.
Komplexität der Architektur wird zur Pflicht. Das operative Risiko verbleibt dabei immer beim Kunden. Das ermöglicht “dehnbare” Interpretationen bei ineinandergreifenden Abhängigkeiten. So kann der “Schluckauf” eines wichtigen Dienstes noch Stunden später Nachwirkungen und Ausfälle produzieren. Diese “Ripple Effects” tauchen verständlicherweise nicht in den SLAs der Cloud-Anbieter auf.7
Der Elefant im Raum ist eine Kuh
Es ist nicht so, dass Ausfallsicherheit pauschal teurer wäre. Redundanz erhöht aber deutlich den Datenverkehr für Weiterleitungen, Replikation oder verteilte Datensicherungen.
Der vermeintliche Elefant im Raum entpuppt sich bei näherem Hinsehen als eine wohlbehütete Cashcow:8 Es ist der interne Traffic. Hier wird nicht nur die Hand aufgehalten, sie greift schamlos in den Geldbeutel, sobald jemand im “Vendor Lock-In” zappelt.9 Infrastrukturen oder zentrale Anwendungen ändern sich nicht alle paar Jahre. Die Schmerztoleranz ist bekanntlich hier am höchsten.
An diesem Punkt scheitern viele Wirtschaftlichkeitsberechnungen.
Fazit
SLAs sichern selten den Kunden, sie sind primär Absicherung des Anbieters. Der Rest ist pures Marketing. Für faktenbasierte Aussagen über tatsächliche Verfügbarkeit oder reale Kosten taugen sie nur bedingt.
Unternehmen ziehen sich aus Public-Cloud Infrastrukturen zurück. “Repatriation” wird dieser Trend genannt. Besonders große Konzerne holen zunehmend Workloads in ihre eigenen Serverräume und Datacenter, so ein IDC-Report aus 2024.10 Die goldenen Cloud-Native-Zeiten sind vorbei, so eine aktuelle Heise-Analyse.11 Hinzu kommt die aktuelle geopolitische Lage.12
Das bedeutet nicht, dass Cloud-Lösungen pauschal schlecht oder unwirtschaftlich wären. Wie so oft kommt es auf den Einzelfall an.
2019 durfte ich das für ein mittelständisches Bauunternehmen mit fünf Standorten untersuchen. Die Frage damals: Soll das neue DocuWare-Dokumentenmanagementsystem in der Cloud oder im eigenen Serverraum betrieben werden?
Selbst mit konservativen, lediglich am Inflationsausgleich orientierten Annahmen zur Preisentwicklung, zeigte die Analyse ein eindeutiges Bild: Der eigene Betrieb war für den Betrachtungszeitraum von zehn Jahren wirtschaftlicher. Inklusive Aufbau eines zweiten Serverraums mit Klimatisierung, redundanter Hardware und Infrastruktur. Preistreiber damals wie heute war der interne Traffic, den der Cloud-Anbieter für Betrieb, Replikation und Datensicherung veranschlagt hatte.
Haben Sie Projekte oder Ideen für das neue Jahr?
Ich unterstütze Sie gerne.
In diesem Sinne,
Tomas Jakobs