Du redest wie einer der unzähligen Cloud-Vertriebler.
Ich habe in den letzten Jahren immer wieder Cloud-Szenarien durchgerechnet, mit den jeweiligen Anbietern zusammen. Zunächst wird immer alles schöngerechnet. Dann fragt man, wie man dieses macht oder wie jenes umgesetzt würde, plötzlich kommen zögerlich immer weitere Zusatzkosten drauf, weil man dann einen eigenen virtuellen Router brauche o.ä.
Dass die eigene Verbindung ins Internet dann auch höher ausgelastet wird und man eine dickere Leitung braucht, wird auch mit schöner Regelmäßigkeit unter den Tisch fallen gelassen. Gerne nachher damit gerechtfertigt, dass so eine Leitung angeblich ja eh da sei. (Ja, ist sie, aber halt eine kleinere und deswegen viel billigere!)
Hat man seine Anwendungslandschaft dann mithilfe des Anbieters, der da gerne kostengünstig bis kostenlos unterstützt, in die Cloud migriert, müssen jede Menge Probleme umschifft werden, mal größere, mal kleinere. Weil manche Features dort nicht angeboten werden oder weil es Restriktionen gibt, aufgrund des Shared Environments.
Mit dem etwaigen Rückweg wird man nciht nur alleine gelassen, er wird zudem noch erschwert. So kommt man zum Beispiel bei Azure Database nicht an die Datenbank-Backups; man kann nur Exports und Imports machen, was viel aufwändiger und fehleranfälliger ist als ein Backup&Restore.
Meiner Erfahrung nach kann man über den Daumen abschätzen: Man kann gut in der Cloud betreiben, was auch on Premise leicht und günstig zu betreiben ist. Es werden also zuerst die einfachen Anwendungen migriert und später dann gerne daraus abgeleitet, dass die Cloud ja einfacher und billiger ist. Trugschluss.
Jedes halbwegs moderne On-Premise-DC ist heute weitgehend automatisiert. Tools dazu gibt es reichlich. Niemand schiebt mehr CDs irgendwo rein. Wenn ich in der Cloud nach 5 Minuten eine neue VM habe, kann ich das auch OP schaffen.
OP kann ich aber auch Ausnahmen machen, die bekomme ich in der Cloud einfach nicht. Ich KANN ein System ganz besonders konfigurieren, ich KANN auch eine alte Version meines OS oder meiner Anwendung betreiben, wenn ich das für nötig empfinde. Ich KANN sogar bei einem System die OS-Updates weglassen und in Ruhe nach einer Lösung suchen, wenn die darauf laufende Anwendung mit einem CU Probleme hat. Usw.
Dazu kommt, dass ich für jeden relevanten Cloudanbieter (und je nach Unternehmensgröße) ein bis zwei AK brauche, die sich nur mit dessen Angebot befassen und darauf Architekturen und Betriebsabläufe für mein Unternehmen entwickeln.
Und ich kann kaum verlässlich in die Zukunft planen, da der Cloudanbieter seine Preise nach Gusto ändern kann. Selbst langfristige Verträge helfen da nicht, da sie zB bei Microsoft typischerweise eine Laufzeit von 3 Jahren haben. Die Nutzungsbedingungen werden monatlich (!) geändert. Da brauche ich eigentlich schon fast einen Mitarbeiter, der nur dauernd die neuen Terms liest und bewertet.
Cloud hat für manche Belange ihren Charme, aber sie hat auch viel Schattenseiten, die von Vertrieblern und auch von Leuten, die nur einen kleinen Teil der IT kennen und nicht über den Tellerrand gucken wollen, gerne unter den Teppich gekehrt werden.
Schlusswort: Bei meinen Kalkulationen lief es am Ende eigentlich immer darauf hinaus, dass die Cloud erst dann von den Kosten nicht mehr inakzeptabel hoch war, wenn ich die Systeme eben während der Nichtnutzungsstunden herunterfahre oder -skaliere.
Zu diesen Kosten kann ich aber OP locker 24/7 durch laufen lassen und spare mir den ganzen organisatorischen Overhead:
"Wer braucht möglicherweise wann was?" muss für jede Anwendung festgelegt und dann die ganze IT-Landschaft mit ihren Abhängigkeiten entsprechend gründlich dokumentiert werden.
"Wer steuert (die Jobs) fürs runter- und hochfahren?" "Wie wird das runter- und hochfahren überwacht, damit die Services auch im Falle eines Problems sicher zur Online-Zeit zur Verfügung stehen?" "Welcher Prozess bzw welche Einheit würde sich rechtzeitig um eine Störungsbehebung kümmern? Jeden Tag!"
Wir haben mehrere tausend Anwendungen. Eine ganze Reihe davon haben wir in die Cloud gebracht. Nur eine einzige davon fällt mir ad hoc ein, bei der sich das wirklich rentiert hat, und die ist hochgradig saisonal und braucht dann massiv Ressourcen.