Vorab ein paar Annahmen:
- wir gehen nicht von einer IT aus, die nur Standardsoftware hosted sondern auch eigene Lösungen liefern muss
- das Unternehmen erwartet sich von der IT einen Benefit für seine Marktpositionierung oder -differenzierung
Sind die Punkte oben nicht gegeben ist es egal wo man hingeht, dann ist es nix anderes als „Hosting“ und man wählt halt den Provider.
Für alle, die die beiden oberen Punkte wollen, muss es Ziel sein, die Vorteile der jeweiligen Cloud für sich zu nutzen, und die liegen in den Managed Services, mit Ziel NoOps (ich weiß, viele hätten gerne mal DevOps). Cloud-agnostische Entwicklung ist ein Edge-Case, der ansonsten meist nur Techniker interessiert, die nicht verstehen was Public Cloud eigentlich kann (positives Bsp: Zoom ist Cloud-agnostisch weil die nix besonderes von einer Public Cloud brauchen außer Bandbreite -> Kubernetes und die ziehen dorthin wo der Traffic am billigsten ist (im Moment grad zu Oracle Cloud)). Für alle anderen ist es fatal, cloud-agnostisch zu sein, weil man damit nie zu NoOps kommt, nicht mal für Teilbereiche. Wenn Kubernetes die Lösung ist, was war das Problem
Im Ernst, Kubernetes in der Cloud ist pervers und nur für cloud-agnostische Systeme relevant oder während einer Transformation/einem Umzug.
Also: Unternehmenziel muss von der IT unterstützt werden, um Differentiator zu kreieren und/oder Marktvorteile zu erzielen. Damit man hier die beste Lösung schafft muss man alle Aspekte des Unternehmens, die in der Wertgenerierung beteiligt sind, mit einbeziehen. Dazu gehören auch die Prozesse und die Kommunikation zwischen allen Beteiligten. Je nachdem was dann als Zukunfts-Soll rauskommt entscheidet man sich für einen (oder mehrere Cloud-Anbieter). Was sich hier nämlich dann einsparen lässt am Weg in diese Vision, dagegen sind die reinen Cloudkosten Peanuts. Leider ist es aber in vielen Unternehmen so, dass das einzige, was messbar ist, die Infrastrukturkosten sind, und weil man nur das zum Vergleichen hat wird dann anhand dieser Maßzahl der Cloud Provider ausgewählt, in der Annahme, dass man mehr oder weniger „umzieht“ - komplett der falsche Ansatz wenn man in die Cloud geht! Bestes Beispiel: wir unterstützen AWS, Azure, GCP, und haben für einen Kunden eine App, die wir schon mal in AWS gebaut haben, in Azure nachgebaut - Grund dafür war dass der Kunde (der eh auch AWS nutzt) der Meinung ist, Azure ist billiger. Rausgekommen sind:
- doppelter Entwicklungsaufwand (es gab keine Knowhow-Lücken, es war einfach aufwendiger und mehr zu tun um das selbe zu erreichen)
- komplexeres System weil mehrere Services benötigt werden als in AWS um das selbe zu erreichen
- höhere Betriebskosten (eh NoOps, also nur für die Services) weil eben mehrere Services und doppelte Datenablage, etc (AWS: Athena geht auf Rohdaten in S3 die sowieso gespeichert werden; Azure brauch Blob-Storage für das „normale“ speichern plus duplizieren nach Azure Tables)
- instabile Services, die Mehraufwand/kosten zur Folge hatten (davon kann jeder ein Lied singen der in Azure mehr macht als Server zu erzeugen)
Dass die Entwicklungskosten bei weitem mehr ausmachen als die Cloud Ressourcen hat zur Folge, dass das System damit, trotz 30% niedrigerer Einzelpreise der Services, teurer ist UND langsamer im der Umsetzung -> time to market also auch noch schlechter, natürlich auch für alle Änderungen, die anstehen.
Wichtig: Das soll jetzt nicht heißen dass AWS immer besser als Azure ist.
Damit das aber wer sieht in einem Unternehmen muss man eben mehr messen und bewerten als nur Infrastrukturkosten, weil Public Cloud, richtig gemacht, sich auf die gesamte Wertschöpfungskette auswirken kann und soll (siehe Anfang).
Für einen reinen Infrastrukturumzug ohne grundlegende Architekturänderung, um die Benefits zu nutzen, zahlt sich Public Cloud meist gar nicht aus bzw. ist meist teurer (es gibt genügend Datacenter, die Server billiger zur Verfügung stellen als AWS oder Azure).
Bitte nicht alles auf die Waagschale legen, der Platz reicht hier nicht aus um das Thema vollständig abzuhandeln, es soll anhand von Beispielen zeigen was alles schief gehen kann bzw. falsch bewertet wird. Es gibt keine „richtige“ oder „falsche“ Cloud, die eine ist für das besser, für andere Zwecke die andere.