Wo die Grenze verläuft, wenn ein Teil der IT in die Cloud geht

In den meisten mittelständischen Unternehmen ist die Frage längst entschieden, bevor sie gestellt wird: Ein Teil der IT läuft in der Cloud, ein anderer im eigenen Haus. Hybrid ist damit kein Zwischenzustand auf dem Weg irgendwohin, sondern der Dauerzustand. Offen bleibt allein, wo die Grenze zwischen beiden Welten verläuft und ob sie an dieser Stelle bewusst gezogen wurde.

Es geht hier nicht um die Reihenfolge eines Umzugs und nicht um die Wahl eines Betriebsmodells, sondern um den Schnitt selbst: Welche Systeme bleiben vor Ort, welche gehen weg, und was passiert an der Nahtstelle? Diese Frage entscheidet später über Antwortzeiten, über den Aufwand im Betrieb und darüber, ob eine einzelne gestörte Leitung mehrere Abteilungen anhält.

Der Schnitt folgt den Datenflüssen, nicht dem Organigramm

Anwendungen sind keine Inseln. Die Warenwirtschaft schreibt in ein Dokumentenarchiv, holt Stammdaten aus einer Datenbank, übergibt Lieferscheine an die Versandsoftware und erzeugt Belege, die in der Buchhaltung landen. Jede dieser Verbindungen wird zu einer Netzabhängigkeit, sobald sie über die Grenze zwischen Haus und Cloud läuft.

Daraus folgt eine schlichte Regel: Geschnitten wird dort, wo wenige, große und verzögerungstolerante Datenübergaben stattfinden – nicht dort, wo viele kleine Abfragen in Echtzeit laufen. Eine Schnittstelle, die nachts eine Datei übergibt, verträgt die Trennung problemlos. Eine Anwendung, die pro Bildschirmmaske hunderte Datenbankabfragen absetzt, verträgt sie nicht.

Praktisch beginnt die Planung deshalb mit einer Liste der Schnittstellen je System, nicht mit einer Liste der Server. Der BSI-Grundschutz verlangt für die Cloud-Nutzung genau das: Verantwortungsbereiche und Schnittstellen zwischen Anbieter und eigener Institution zu identifizieren und zu dokumentieren, bevor ein Dienst eingebunden wird. Wer diese Liste erstellt, sieht meist schon, welche Gruppen von Systemen sich nur gemeinsam bewegen lassen.

Vier Kriterien für jede Anwendung

Die vier Kriterien lassen sich für jedes System in einer Zeile beantworten. Wichtig ist, dass sie gemeinsam betrachtet werden: Ein System mit unkritischen Daten kann an der Latenz scheitern, ein latenzunempfindliches System an der Lizenzbedingung. Wer nur nach Schutzbedarf sortiert, erhält eine Landkarte, die im Betrieb nicht funktioniert.

Eine typische Situation im Mittelstand macht das anschaulich. Ein Fertigungsbetrieb betreibt eine Warenwirtschaft mit angebundener Dokumentenablage, eine Konstruktionsabteilung mit großen Zeichnungsdateien, eine Zeiterfassung mit Terminals in der Halle und ein Postfachsystem. Nach den vier Kriterien landet das Postfachsystem beim Anbieter, Warenwirtschaft und Dokumentenablage bleiben als Paket zusammen, die Konstruktionsdaten bleiben dort, wo die Arbeitsplätze stehen, und die Zeiterfassung bleibt vor Ort, weil sie an Geräte im Gebäude gebunden ist. Vier Systeme, drei unterschiedliche Antworten – und keine davon folgt aus einer allgemeinen Cloud-Strategie.

Latenz: eine Rechnung mit angenommenen Werten

Wie stark Latenz wirkt, zeigt eine Überschlagsrechnung. Angenommen, eine Fachanwendung setzt beim Öffnen einer Bildschirmmaske 300 einzelne Datenbankabfragen ab, und angenommen, eine Anfrage über die Standortgrenze braucht 15 Millisekunden für Hin- und Rückweg. Dann summiert sich allein die Wartezeit auf etwa 4,5 Sekunden je Maske. Im selben Gebäude, mit angenommenen 0,5 Millisekunden, wären es 0,15 Sekunden.

Die Zahlen sind Annahmen und kein Messergebnis. Sie zeigen aber, worauf es ankommt: Nicht die Leitungsbreite entscheidet, sondern die Zahl der Einzelzugriffe multipliziert mit der Laufzeit. Eine schnellere Leitung verkürzt die Laufzeit kaum, weil sie physikalisch begrenzt ist. Deshalb gilt: Anwendung und Datenbank bleiben zusammen, auf welcher Seite der Grenze auch immer.

Wo das nicht möglich ist, hilft die Verlagerung der Darstellung statt der Daten. Läuft die Anwendung samt Datenbank beim Anbieter und wird nur das Bild an den Arbeitsplatz übertragen, fällt die kleinteilige Kommunikation im Rechenzentrum an. Umgekehrt gehören große Dateien dorthin, wo sie bearbeitet werden – Konstruktions- und Videodaten über die Standortgrenze zu ziehen, kostet Zeit unabhängig von der Latenz.

Lizenzen entscheiden manchmal schneller als die Technik

Viele Hersteller unterscheiden in ihren Bedingungen, ob Software auf eigener Hardware, bei einem Dienstleister oder bei einem großen Plattformanbieter läuft. Daran hängen drei Fragen: Darf eine vorhandene Lizenz mitgenommen werden? Ändert sich die Berechnungsgrundlage, etwa von Geräten auf Nutzer oder von Prozessorkernen auf virtuelle Kerne? Und unterstützt der Hersteller den Betrieb in der gewählten Umgebung im Supportfall überhaupt?

Diese Antworten gehören schriftlich in die Planung, und zwar vom Hersteller oder Vertragspartner, nicht aus zweiter Hand. Eine Fachanwendung, für die der Hersteller ausschließlich den Betrieb in seiner eigenen Umgebung unterstützt, ist keine Architekturentscheidung mehr, sondern eine Vorgabe. Umgekehrt scheitern Vorhaben daran, dass eine Datenbanklizenz nach dem Umzug auf eine Plattform mit deutlich mehr Kernen plötzlich anders zu zählen ist.

Sechs Fehlschnitte, die regelmäßig vorkommen

Allen sechs Fällen ist gemeinsam, dass sie im Projekt nicht auffallen. Sie zeigen sich erst im Alltag, meist als diffuse Beschwerde über Geschwindigkeit oder als doppelte Arbeit in einer Fachabteilung. Genau deshalb lohnt es sich, die Nahtstelle vor dem Umzug einmal vollständig durchzusprechen – mit den Menschen, die das System täglich benutzen.

Ein siebter Punkt betrifft weniger die Technik als den Betrieb: Eine hybride Landschaft verdoppelt an manchen Stellen die Zuständigkeit. Überwachung, Sicherung, Protokollauswertung und Rechtevergabe existieren dann in zwei Werkzeugen mit zwei Oberflächen. Wer das nicht zusammenführt, spart im Betrieb nichts ein, sondern verteilt denselben Aufwand auf zwei Stellen.

Den Schnitt dokumentieren und befristen

Eine hybride Architektur bleibt nur so lange verständlich, wie die Begründung für den Schnitt nachlesbar ist. Für jedes System genügen fünf Angaben: Wo läuft es, warum dort, welche Schnittstellen überqueren die Grenze, wer verantwortet es fachlich, und wann wird die Entscheidung erneut geprüft. Der letzte Punkt ist der wichtigste, weil sich Lizenzbedingungen, Herstellerfreigaben und Anbindungen ändern.

Der BSI-Grundschutz verlangt für die Cloud-Nutzung eine Strategie, die festlegt, welche Dienste in welchen Bereitstellungsmodellen bezogen werden, und empfiehlt bei erhöhtem Schutzbedarf, die Anforderungen an einen Anbieterwechsel oder eine Rückverlagerung vorab zu definieren und regelmäßig zu prüfen. Übersetzt in den Mittelstand heißt das: Der Schnitt ist eine Entscheidung mit Datum, kein Zustand, der sich aus Einzelfällen ergibt.

Für die Geschäftsführung reichen am Ende drei Fragen an die IT. Welche Anwendungen kommunizieren über die Grenze, und wie oft? Welche Entscheidung wäre in zwei Jahren nur mit erheblichem Aufwand umkehrbar? Und was arbeitet weiter, wenn die Internetanbindung einen halben Tag ausfällt? Wer diese drei Antworten hat, hat eine Architektur – wer sie nicht hat, hat eine Ansammlung von Einzelentscheidungen.

Verwandte Themen: Wer hier weiterdenkt, liest bei Private Cloud, Softwareauswahl und Identitätsverwaltung weiter.