No-Cloud-Strategie

In den 2010er Jahren haben sich zwei gegensätzliche Strategien zu einer einzigen konsolidiert. Bis dahin konkurrierten SQL-Datenbanken auf der einen Seite und no-SQL-Datenbanken, die keinen SQL-basierten Zugriff boten, auf der anderen Seite. Die Wende in diesem Konflikt kam mit der Entwicklung von NoSQL-Datenbanken, die etwas von beidem boten. Während am Anfang no-SQL für kein SQL stand, steht heute NoSQL für Not only SQL - also nicht nur SQL.

Ich glaube, dass wir im Cloud-Bereich vor einer ähnlichen Konsolidierung stehen. Seit den 2010er Jahren ist die Cloud der letzte Schrei im IT-Betrieb und hat extreme Ausmaße angenommen: SAP will, dass Unternehmen den Kern ihrer IT nach St.Leon-Rot auslagern (siehe:  Heise) und die Deutsche Bahn hat ihre gesamten Anwendungen an amerikanische Firmen ausgelagert (siehe:  Handelsblatt und  DB Systel).

Wenn Daten wirklich das neue Gold sind, warum geben Sie ihr Gold dann aus der Hand?

Ich glaube, dass wir hier die Extreme erreicht haben und das Pendel in den nächsten Jahren wieder in die andere Richtung ausschlagen wird - hin zu einer No-Cloud-Strategie - für Not-Only-Cloud.

Das Problem mit der Cloud

Der Einsatz von Clouds hat zweifellos Vorteile. Sie bieten vor allem eine hohe Skalierbarkeit und Flexibilität für Anwendungen. Ein Startup kann schnell ein System, eine Plattform oder eine App auf den Markt bringen, ohne Dutzende von Servern kaufen oder Rechenzentren einrichten zu müssen. Auch Datenmengen können schnell wachsen, ohne dass Lastwagenladungen von Festplatten in eine Firmenzentrale gefahren werden müssen.

Aber was ist, wenn Anwendungen das nicht tun? Nicht jede Anwendung ist Teil eines brandheißen Startups mit monatlichen Wachstumsraten im dreistelligen Prozentbereich. Die meisten Unternehmensanwendungen wachsen in ihrem Daten- und Rechenvolumen sehr moderat und benötigen auch keine große Flexibilität, weil sie etablierte, langlebige Geschäftsprozesse abbilden, die sich in einem Unternehmen selten von heute auf morgen ändern.

Kosten und entgangener Gewinn

Wie verhält es sich mit den Kosten für unspektakuläre Unternehmensanwendungen in der Cloud im Vergleich zu einem lokalen Rechenzentrum? Die Anschaffungskosten für die Hardware sind nach wenigen Jahren abgeschrieben, die Kosten für die Cloud steigen. Anfangs konnten die großen Cloud-Anbieter die Preise für ihre Dienste aufgrund von Skaleneffekten regelmäßig senken. AWS betreibt dazu sogar den  Price Reduction Blog. Nach zahlreichen Preissenkungen bis November 2021 war dort allerdings fast drei Jahre lang Ruhe. Im Jahr 2024 gibt es immerhin wieder 2 Einträge, von denen einer aber nur beschreibt, dass man seine Daten kostenlos mitnehmen kann, wenn man von AWS wegmigriert.

Der Tiefpunkt der Preissenkungen im Cloud-Bereich scheint 2021 erreicht worden zu sein. Seitdem sind eher Preiserhöhungen zu beobachten, z.B:

• SAP hat 2022 eine automatische jährliche Preiserhöhung von 3,3% für Cloud Services eingeführt (siehe:  Handelsblatt).
• Google hat 2022 sein Preismodell “angepasst” - allerdings lässt sich nicht pauschal sagen, wie stark die Preise gestiegen sind. Dies variiert stark je nach Dienst ( Google Cloud Blog)
• Microsoft hat die Preise für Cloud-Produkte 2023 um 11% erhöht ( Microsoft News)
• Anwendern missfällt weiterhin SAPs rigoroser Cloud-Kurs  (Heise / 2024)

Unabhängig von den Kosten für Cloud-Lösungen entwickeln Cloud-Anbieter ihre Dienste weiter. Dabei spielt es keine Rolle, ob es sich um einen großen Hyperscaler oder eine kleine SaaS-Lösung handelt. Was die Anbieter allerdings für die Weiterentwicklung brauchen, sind Daten. Ihre Daten!

Wenn Daten wirklich Gold sind, warum sollte man dann andere dafür bezahlen, dass sie die eigenen Erträge steigern?

KI ist der neue, heiße Scheiß - der aber immense Anfangsinvestitionen erfordert. Dieses Geld muss erst einmal verdient werden. Ein funktionierendes Cloud-Geschäft, bei dem man mit den Daten anderer Leute Geld verdient und ihnen auch noch fast ungestraft die Gebühren erhöhen kann, ist dafür eine sprudelnde Geldquelle.

Die Cloud-Kunden von heute bezahlen die KI-Lösungen von morgen. Ob sie davon profitieren oder nicht.

Sicherheit und Verfügbarkeit

Eigentlich werben die Cloud-Anbieter mit einer sehr hohen Sicherheit und Verfügbarkeit ihrer Dienste. Aber auch bei Cloud-Anbietern arbeiten (noch) nur Menschen und auch die größten Cloudanbieter sind nicht vor teils fatalen Ausfällen geschützt. Einige Beispiele:

•  AWS Ausfall 2021
•  AWS Ausfall 2023
•  Azure Ausfall 2023
•  Azure Ausfall 2024
•  Google Cloud Ausfall 2024
•  Versehentliche Löschung von Daten in der Google Cloud (2024)
•  SAP Cloud Plattform Ausfall 2024
•  Microsoft warnt vor rasant steigender Zahl an Cyberangriffen (2024)

Fällt eine solche Cloud aus und kann dadurch beispielsweise ein Online-Händler keine Umsätze mehr erzielen oder die Züge der Deutschen Bahn nicht mehr fahren, ist es nur ein schwacher Trost, dass man das Geld für die bezahlten, aber nicht genutzten Ressourcen zurückerstattet bekommt. Allerdings ist man beim Ausfall von Hyperscalern in der Regel in guter Gesellschaft.

Über die Sicherheit von Cloud-Diensten im Vergleich zu On-Premise-Installationen streiten sich die Gelehrten. Der rechtlichen (Un-)Sicherheit, die durch den Patriot Act und die DSGVO entstanden ist, kann man unter anderem mit kundenverwalteten Schlüsseln zur Verschlüsselung der Daten begegnen. Mit diesem Verfahren kann man weitgehend ausschließen, dass ein unbefugter Zugriff auf die eigenen Daten in der Cloud stattfindet. Rechtlich ist das in Ordnung. Inwieweit es technisch umsetzbar ist, zeigt sich im Einzelfall. Man kann ausschließen, dass jemand anderes meine Daten nutzt. Allerdings kann ich auch mit diesem Verfahren nicht verhindern, dass jemand anderes mich an der Nutzung meiner Daten hindert. Dieser Faktor kann je nach Wichtigkeit und Kritikalität der Daten (z.B. beim Betrieb kritischer Infrastrukturen) eine Rolle spielen. Gerade in einer zunehmend unsicheren Welt und einer immer unberechenbareren Weltpolitik.

Bei einem Hackerangriff ist es zwar ziemlich egal, wo die Daten liegen, aber wenn sie vor Ort sind, kann man im Notfall tatsächlich physisch den Stecker ziehen. Allerdings haben die Administratoren von Cloud-Anbietern in der Regel mehr Erfahrung mit der Abwehr von Angriffen als die von kleineren Unternehmen.

Sicherheit und Verfügbarkeit sind wie immer eine Frage der Abwägung. Es geht darum, was einem Unternehmen seine Daten wert sind. Eine pauschale und eindeutige Aussage pro oder contra Cloud ist seriös nicht möglich.

Der technische Fortschritt seit den 2010er Jahren

In den 2010er Jahren waren virtualisierte Rechenzentren (z.B. mit VMWare) Stand der Technik. Die Virtualisierung von Servern und Storage (z.B. durch  SAN) hatte schon damals vielerorts physische Server abgelöst.

Mit der Erfindung von  Docker beschleunigte sich diese Entwicklung massiv. Container gab es im Linuxumfeld schon vorher, aber Docker trat seinen Siegeszug an. Schnell zeigte sich der Bedarf an Managementsoftware für große IT-Landschaften auf Basis von Containern. Google hatte bereits vor Docker für seine eigenen Systeme auf Container gesetzt und dafür seit mehreren Jahren eine selbst entwickelte Software namens Borg im Einsatz. Aus dieser Software entstand 2014 das Open-Source-Projekt Kubernetes, das die einfache Verwaltung großer Docker-Container-Landschaften ermöglicht. Kubernetes ist aus einer modernen IT-Landschaft nicht mehr wegzudenken. Gleichzeitig hat die Cloud-Technologie dank eines Open-Source-Projekts lokalen Rechenzentren die Flexibilität gebracht, die bisher nur Cloud-Providern zur Verfügung stand.

Ähnlich wie Kubernetes haben sich auch andere Technologien entwickelt, die oft als Open-Source-Projekte großer Unternehmen die Architektur und Flexibilität einer Cloud in jedes Unternehmen bringen können.

Mit  Ansible oder  Terraform werden Infrastrukturen per Code erstellt. Das von Amazon erfundene, aber frei nutzbare Protokoll des  Simple Storage Service (S3) kann mit Lösungen wie  MinIO oder  Ceph flexiblen Zugriff auf die Daten im eigenen Rechenzentrum bieten.  KeyCloak verwaltet die lokalen Identitäten und Zugriffe der Mitarbeiterinnen und Mitarbeiter. Und mit  Prometheus und  Grafana behalten Sie den Überblick über Ihre IT-Landschaft. Neben diesen sehr bekannten Projekten gibt es viele weitere Projekte und Systeme, die Cloud-Architekturen und -Technologien fast überall möglich machen. Einen hervorragenden Überblick über diese Produkte und Projekte bietet die  Landkarte der Cloud Native Foundation.

Selbst modernste KI-Modelle wie  Llama stehen als Open Source zur Verfügung und können somit lokal mit den eigenen Daten genutzt werden. Eine moderne Anwendung sollte heute immer Cloud-nativ entwickelt werden, auch wenn der Betrieb in einer Cloud gar nicht geplant ist. Dieser moderne Architekturstil schafft die Flexibilität, Anwendungen und Daten unabhängig von politischen, technologischen oder monetären Zwängen immer dort zu betreiben, wo es am sinnvollsten ist.

Eine Architektur auf Basis dieser standardisierten Technologien vermeidet Vendor-Lock-ins bei Cloud-Anbietern und macht gleichzeitig politische Initiativen wie das  Gaia-X-Projekt überflüssig.

Es gibt heute keinen Grund mehr, seine Daten und Anwendungen aus Gründen der Flexibilität und Skalierbarkeit in eine Cloud zu verlagern, wenn man bereits ein eigenes Rechenzentrum besitzt. Vielmehr zeichnet sich ein umgekehrter Trend ab: Sobald aus einem Start-up ein größeres Unternehmen wird, ist es sinnvoll, Daten und Anwendungen in ein lokales Rechenzentrum zu verlagern, um den größtmöglichen Nutzen daraus zu ziehen.

Ein entscheidender Faktor ist dabei jedoch unerlässlich: Sie brauchen die richtigen Architekten im Unternehmen, die Cloud-Native-Systeme entwerfen und deren lokalen, hybriden oder Cloud-first-Betrieb ermöglichen.

Die No-Cloud-Strategie

Als IT-Architekt, der seit 15 Jahren Cloud-Systeme und -Anwendungen konzipiert, würde ich nie pauschal sagen, dass ein Unternehmen komplett auf die Cloud verzichten sollte. Andererseits würde ich auch nicht empfehlen, ausschließlich auf die Cloud zu setzen. Unter Abwägung der Vor- und Nachteile von Cloud-Plattformen würde ich eine Strategie empfehlen, die sowohl die Art der Anwendung als auch die Größe des Unternehmens berücksichtigt:

In dieser Strategie werden die Anwendungen unterschieden in

• Volatile Anwendungen, die entweder aktuell stark wachsen (in der Anzahl der Nutzer, im Datenvolumen oder im Rechenvolumen) oder deren Last stark schwankt, z.B. weil sie saisonal oder ereignisabhängig sind (Weihnachtsgeschäft, Sonderaktionen etc.).
• Beständige Anwendungen, deren Auslastung und Nutzerzahl zwar leicht schwanken können, aber weitgehend konstant bleiben. Ein typisches Beispiel hierfür sind unternehmensinterne Anwendungen.
• Kritische Anwendungen sind Anwendungen, die aufgrund einer internen oder externen Bewertung als kritisch eingestuft werden. Das kann bei einem Online-Händler das Shopsystem sein, ohne das alle Umsätze wegbrechen. Es kann sich aber auch in größerem Umfang um Anwendungen handeln, die als  kritische Infrastruktur eingestuft werden.

Bei dieser Empfehlung gehe ich davon aus, dass kleine Unternehmen weder die finanziellen noch die personellen Ressourcen haben, um eine Rechenzentrumsinfrastruktur zu betreiben. Daher ist für kleine Unternehmen die Cloud die beste Wahl für alle Arten von Anwendungen. Mittelgroße Unternehmen verfügen bereits über die Mittel, um eigene Server zu betreiben. Entweder in einem eigenen oder gemieteten Rechenzentrum oder durch Server Housing. Mittelständische Unternehmen können daher bei beständigen Anwendungen bereits von den langfristig günstigeren Kosten des lokalen Betriebs von langlebigen Anwendungen profitieren. Kritische Anwendungen würde ich hier allerdings noch in der Cloud belassen, da sie höhere Anforderungen an die IT-Fähigkeiten eines Unternehmens stellen als die beiden anderen Typen. Diese Anforderungen sind jedoch in großen Unternehmen - in Form von Experten und finanziellen Mitteln - gegeben. Kritische Anwendungen in einem großen Unternehmen würde ich grundsätzlich hybrid auslegen. So dass sie auch dann noch funktionieren, wenn Clouds oder das lokale Rechenzentrum ausfallen. Große Unternehmen profitieren zudem ebenso wie mittelständische Unternehmen von langfristig sinkenden Kosten beim lokalen Betrieb von beständigen Anwendungen. Umgekehrt ist auch in Großunternehmen die Cloud für volatile Anwendungen klar zu bevorzugen.

Damit die Betriebsumgebung einer Anwendung nicht zu einem kritischen Thema wird, sollten Anwendungen grundsätzlich Cloud-nativ entworfen und gebaut werden. Auch in lokalen Rechenzentren sollten Cloud-Technologien zum Einsatz kommen. So kann die Betriebsumgebung einer Anwendung rein strategisch betrachtet werden und stellt keine technische Herausforderung dar.

Fazit

Die Cloud ist weder gut noch schlecht. Wie so oft kommt es darauf an, was man damit macht. Da es in bestimmten Szenarien aus wirtschaftlichen, politischen oder strategischen Gründen durchaus sinnvoll sein kann, Anwendungen lokal zu betreiben, halte ich eine cloud-first oder gar cloud-only Strategie für zu radikal. Um die Interessen eines Unternehmens bestmöglich zu berücksichtigen, ist eine No-Cloud-Strategie (für not-only-cloud) eine gute Wahl.

Unabhängig von der Strategie für die Betriebsumgebung einer Anwendung ist es aber grundsätzlich eine gute Idee, die Architektur moderner Anwendungen cloud-nativ aufzubauen und auch im eigenen Rechenzentrum auf Cloud-Technologien zu setzen!