Womit es anfängt
Mit einer Bestandsaufnahme. Im Cloud Assessment erfassen wir sämtliche Anwendungen und Services samt ihren Abhängigkeiten und Verknüpfungen. Dieser Servicekatalog ist die Grundlage für alles Weitere, und er ist auch der Teil, den fast niemand vollständig hat.
Die Abhängigkeiten sind dabei das Entscheidende. Eine Anwendung allein zu verschieben ist einfach; sie von der Datenbank zu trennen, die drei andere Systeme mitbenutzen, ist es nicht.
Das Cloud Readiness Assessment
Anschliessend prüfen wir die Anwendungen auf ihre Cloud-Fähigkeit und weisen jeder eines der 6 R zu:
- Rehost – Lift and Shift. Die virtuellen Server ziehen von der eigenen Private Cloud auf die Infrastruktur des Public-Cloud-Anbieters, die Anwendung bleibt wie sie ist.
- Replatform – Die Architektur bleibt im Grundsatz, der Unterbau nicht. Aus einer MySQL-Datenbank on-premises wird zum Beispiel ein verwalteter Datenbankdienst.
- Refactor – Die Anwendung wird in ihren Grundzügen neu entworfen und wo möglich cloud-nativ betrieben.
- Repurchase – Die Anwendung wird vollständig durch eine SaaS-Anwendung abgelöst.
- Retire – Die Anwendung wird abgeschaltet, weil der Service anders erbracht wird oder gar nicht mehr gebraucht wird.
- Retain – Es bleibt alles, wie es ist. Gründe dafür sind Latenzanforderungen, Legacy-Anwendungen oder ein Betriebssystem, das nirgendwo anders läuft.
Ohne diese Zuweisung wird eine Migration zur pauschalen Verschiebung. Das führt zu laufenden Kosten für Anwendungen, die man hätte abschalten können, und zu Anwendungen, die in der Cloud teurer laufen als vorher.
Retire ist dabei die unterschätzte Kategorie. In jeder Bestandsaufnahme finden sich Systeme, die niemand mehr braucht und die trotzdem migriert worden wären.
Was dabei herauskommt
Ein künftiger Mode of Operation je Anwendung, und damit eine Migration, die man planen und budgetieren kann, statt sie zu beginnen und zu sehen, wie weit man kommt.
