Schritt 1: Anwendungen einsortieren, bevor etwas umzieht
Der Fehler am Anfang ist fast immer derselbe: Es wird die Anwendung verschoben, die technisch am einfachsten aussieht, statt der, bei der es sich lohnt. Eine grobe Einsortierung nach vier Merkmalen reicht für die erste Runde.
Wohin welche Last gehört
| Art der Anwendung | Wo sie hingehört | Warum |
|---|---|---|
| Steuerung von Anlagen, Kassen, Laborgeräte | Rechenzentrum oder Standort | Antwortzeit und Betrieb bei unterbrochener Leitung entscheiden, nicht Rechenleistung |
| Datenbank mit hoher Abfragefrequenz | Bleibt bei der Anwendung | Jede zusätzliche Millisekunde pro Abfrage multipliziert sich mit der Anzahl der Aufrufe |
| Testumgebungen und Lastspitzen | Cloud | Werden nur zeitweise gebraucht und lassen sich außerhalb der Nutzung abschalten |
| Auswertung und Langzeitarchiv | Cloud, wenn die Daten dorthin fließen | Speicher ist günstig, aber der Rückweg der Daten kostet je Gigabyte |
| Standarddienste wie Postfach und Zusammenarbeit | Cloud | Eigenbetrieb bindet Personal ohne fachlichen Vorteil gegenüber dem eingekauften Dienst |
| Alles mit besonderer Rechtsbindung | Einzelfallprüfung | Entscheidend sind Zweck und Rechtsgrundlage, nicht der Speicherort allein |
Miss vor jeder Aufteilung den Datenfluss zwischen den Bestandteilen einer Anwendung. Anwendungsserver und Datenbank tauschen oft ein Vielfaches dessen aus, was am Ende beim Benutzer ankommt, und genau dieser Verkehr entscheidet über Antwortzeit und Rechnung. Wenn du die Zahl nicht hast, hilft eine Woche Messung an der Firewall mehr als jede Schätzung. Anwendungen, die sich nicht sauber trennen lassen, ziehen entweder ganz um oder bleiben ganz da, aber sie werden nicht halbiert.